2.239
değişiklik
Değişiklikler
Gezinti kısmına atla
Arama kısmına atla
3.555. satır:
3.555. satır: − + 3.673. satır:
3.673. satır: − · Kalemin tasarımı onarıma izin veriyor mu?+ − + − · Kalemin onarımı belirli bir bakım seviyesi ile sınırlı mı? 3.687. satır:
3.686. satır: − + − + 3.748. satır:
3.747. satır: − + 3.775. satır:
3.774. satır: − + − + 3.792. satır:
3.791. satır: − + − + 3.803. satır:
3.802. satır: − + 3.879. satır:
3.878. satır: − + 4.019. satır:
4.018. satır: + − + − = EK-H YAZILIM DESTEK ANALİZİ (YDA) = − − 4.034. satır:
4.031. satır: − · Teslim edilen yazılım ürünlerindeki hataların giderilmesi (düzeltici bakım);+ − + − · Yazılımın performansının ve özelliklerinin iyileştirilmesi (mükemmelleştirici bakım);+ − + − · Yazılımın değişen çevre koşullarına, donanıma, işletim sistemine ve muhtelif arayüzlere adaptasyonu (uyarlayıcı bakım); − − · Yazılımın daha az karmaşık, daha anlaşılabilir, bakımının daha kolay yapılabildiği şekle çevrilmesi (önleyici bakım). − · Bakım planı ve bakım süreçlerinin oluşturulması;+ − + − · Problem Raporu ve Değişiklik İsteği süreçlerinin oluşturulması (taleplerin alınması, kaydedilmesi, güncellenmesi, izlenmesi, testlerle doğrulanması ve geri beslemenin yapılması);+ − − · Konfigürasyon yönetiminin uygulanması. − · Niteliği (düzeltici, uyarlayıcı vb.);+ − + − · Kapsamı (yazılımdaki değişikliğin büyüklüğü, işlemlerin maliyeti, bakım süresi);+ − − · Kritikliği (performans, emniyet, bilgi güvenliği hususları) değerlendirilir. − + 4.096. satır:
4.086. satır: − + 4.103. satır:
4.093. satır: − · Alanda Yüklenebilir Yazılım (Field-Loadable Software); bir sistem/ürün üzerindeki ekipmanın bir veya birkaç parçasına ekipmanı demonte etmeden yüklenebilen yazılımdır.+ − + − · Atölyede Yüklenebilir Yazılım (Shop-Loadable Software); bir HDB üzerinde yüklenebilecek bir yazılımdır ancak HDB’nin üründen demontajını gerektirir.+ − − · Yerleşik Yazılım/Bellenim; HDB veya ADB’ye yüklenebilecek ancak operasyonel ürün üzerindeki yükleniminin demontajı ve bir komponentin yeniden konumlandırılmasını gerektirebilecek yazılımdır. 4.113. satır:
4.101. satır: − + − + − + − · Operasyonel olaylar; operasyonel bir gereksinim ile ilgili, donanım üzerinden dokümante edilebilen donanım bakımını, kullanıma hazırlığı ve görev sonrası gereksinimleri kapsayan olaylardır.+ − + − · Teknik olaylar; yazılım paketinin, değişen koşullara olan adaptasyonunu gerektirir. Yazılımın üzerinde olduğu donanımın değişmesi, birbiriyle çalışan sistemlerin teknolojisinde değişme örnek olarak verilebilir.+ − + − · Yazılım geliştirme gereksinimleri; yazılım değişiklikleri yazılım paketinin karmaşıklığı ve boyutuna göre değişen aralıklarda yapılır. Yazılım hatalarının düzeltilmesinin yanında, yeni yazılım yayımlanması için son kullanıcı gereksinimleri ve koşullardaki değişikliklere girdi sağlar. Yazılım geliştirme demek, geliştirilecek yeni özellikler veya genişletilecek fonksiyonellik veya mevcut yazılımın kullanım konforu demektir.+ − + − · Yazılım hataları; desteği başlatan ana sebep yazılım hatalarıdır. Bu hatalara verilecek destek ile ilişkili reaksiyonlar hatanın ciddiyetine bağlıdır. Her yazılım hatası yazılım modifikasyonu gerektirmeyecektir. Modifikasyonun gerekli olmadığı durumlarda bile, bir sonraki hatanın tespiti için dokümantasyonun doğru hazırlanmış olması gerekmektedir.+ − − o Minör hata: Genellikle, kullanıcının sistemi kullanım konforu ve ergonomisi ile ilişkili olup sistemin operasyonel kullanımı ile ilgili kritiklik yaratmayan ancak gene de hata olarak ele alınması gereken durumlardır. − − o Orta seviye hata: Sistemin işlevselliğini azaltan hatalardır. Sistemin kullanımı azalan bir performans veya hiçbir kısıtlama dahi olmadan devam edebilir. − − o Major hata: Tüm sistemin tamamen kapatılmasına veya çok kısıtlı koşullar altında çalışmasına neden olan kabul edilemez hatalardır. Sistem performansı ciddi oranda azalır. − +
Lojistik Destek Analizleri ve Kayıtları Rehberi (kaynağı gör)
16.28, 12 Temmuz 2021 tarihindeki hâli
, 16.28, 12 Temmuz 2021→EK-F ONARIM SEVİYESİ ANALİZİ (OSA)
OSA BGA’yı tamamlayıcı niteliktedir. Saha inceleme rapolarının, mühendislik verilerininin ve proje gereksinimlerinin girdi olarak kullanıldığı OSA, tasarımın netlik kazanması ile geliştirme safhasında bakım görev analizine paralel bir şekilde yürütülür. Diğer taraftan ihtiyaç olması halinde (tasarım değişikliği, modifikasyon vb) ilgili safhalarda güncellenebilecek bir analizdir.
OSA BGA’yı tamamlayıcı niteliktedir. Saha inceleme rapolarının, mühendislik verilerininin ve proje gereksinimlerinin girdi olarak kullanıldığı OSA, tasarımın netlik kazanması ile geliştirme safhasında bakım görev analizine paralel bir şekilde yürütülür. Diğer taraftan ihtiyaç olması halinde (tasarım değişikliği, modifikasyon vb) ilgili safhalarda güncellenebilecek bir analizdir.
== 2. ANALİZ SÜRECİ ==
== 2. ANALİZ SÜRECİ ==
Sistemler için onarım seviyeleri genellikle ikiye veya üçe ayrılır:
Sistemler için onarım seviyeleri genellikle ikiye veya üçe ayrılır:
Aşağıda belirtilen soruların cevabı evet ise bu kalemlerin OSA kapsamında analiz edilmesi gerekmektedir;
Aşağıda belirtilen soruların cevabı evet ise bu kalemlerin OSA kapsamında analiz edilmesi gerekmektedir;
* Kalemin tasarımı onarıma izin veriyor mu?
* Kalemin onarımı belirli bir bakım seviyesi ile sınırlı mı?
Sarf malzemelerin (somun, cıvata, conta vb.) analize dahil edilmesine gerek yoktur.
Sarf malzemelerin (somun, cıvata, conta vb.) analize dahil edilmesine gerek yoktur.
Bu örnek kapsamında, elektronik komplenin yenisi ile değiştirilmesi durumunda arızalı elektronik komplenin onarılması ya da elden çıkarılması ve bu faaliyetlerin hangi seviyede yapılacağı ile ilgili karar OSA kapsamında verilecektir. Bu karar verilirken de hem onarım maliyeti (işçilik, eğitim vs.) hem de asıl malzeme maliyeti ile elektronik komplenin güvenilirlik değeri göz önünde bulundurulmalıdır.
Bu örnek kapsamında, elektronik komplenin yenisi ile değiştirilmesi durumunda arızalı elektronik komplenin onarılması ya da elden çıkarılması ve bu faaliyetlerin hangi seviyede yapılacağı ile ilgili karar OSA kapsamında verilecektir. Bu karar verilirken de hem onarım maliyeti (işçilik, eğitim vs.) hem de asıl malzeme maliyeti ile elektronik komplenin güvenilirlik değeri göz önünde bulundurulmalıdır.
== 2.1. OSA VERİLERİ ==
== 2.1. OSA VERİLERİ ==
OSA kapsamında yapılan değerlendirmelerde kullanılan veriler bakım ilişkili verilerdir. Bunların bir kısmı yedek parça, tesis, destek ekipmanı, personel ve yetenek seviyesi, eğitim ihtiyacı gibi maliyet ilişkili verilerdir. Bir kısmı ise, güvenilirlik bilgisi (MTBF gibi), planlı bakım aralıkları, sistem hazır bulunurluğu, stoktaki yedek parçaların hazır bulunurluğu, bakım için gerekli personelin hazır bulunurluğu gibi doğrudan maliyetle ilişkili olmayan verilerdir.
OSA kapsamında yapılan değerlendirmelerde kullanılan veriler bakım ilişkili verilerdir. Bunların bir kısmı yedek parça, tesis, destek ekipmanı, personel ve yetenek seviyesi, eğitim ihtiyacı gibi maliyet ilişkili verilerdir. Bir kısmı ise, güvenilirlik bilgisi (MTBF gibi), planlı bakım aralıkları, sistem hazır bulunurluğu, stoktaki yedek parçaların hazır bulunurluğu, bakım için gerekli personelin hazır bulunurluğu gibi doğrudan maliyetle ilişkili olmayan verilerdir.
Toplam maliyet hesaplamaları yapılırken, gerekli kaynakların sadece başlangıçta gereken veya tekrar eden maliyet olarak değerlendirilmesi gerekmektedir. Örneğin, işçilik süresi ya da alt yapı bakımı tekrar eden bir maliyetken, destek ekipmanı tedariki ya da alt yapı kurulumu için sadece başlangıç maliyeti söz konusudur.
Toplam maliyet hesaplamaları yapılırken, gerekli kaynakların sadece başlangıçta gereken veya tekrar eden maliyet olarak değerlendirilmesi gerekmektedir. Örneğin, işçilik süresi ya da alt yapı bakımı tekrar eden bir maliyetken, destek ekipmanı tedariki ya da alt yapı kurulumu için sadece başlangıç maliyeti söz konusudur.
== 2.2. BAKIM SEVİYELERİNİN BELİRLENMESİ ==
== 2.2. BAKIM SEVİYELERİNİN BELİRLENMESİ ==
Bakım çözüm önerisinin oluşturulması kapsamında, hangi bakım görevinin hangi seviyede yapılacağının belirlenmesi ve bunun için de bakım seviyelerinin tanımlanması gerekmektedir. Bakım seviyeleri, her sisteme özel olarak kullanıcı ile anlaşılarak belirlenmelidir. Daha sonra, tanımlanan bakım görevlerinin altyapı, personel, yetkinlik gibi hususlar düşünüldüğünde hangi seviyede yapılacağına karar verilmelidir.
Bakım çözüm önerisinin oluşturulması kapsamında, hangi bakım görevinin hangi seviyede yapılacağının belirlenmesi ve bunun için de bakım seviyelerinin tanımlanması gerekmektedir. Bakım seviyeleri, her sisteme özel olarak kullanıcı ile anlaşılarak belirlenmelidir. Daha sonra, tanımlanan bakım görevlerinin altyapı, personel, yetkinlik gibi hususlar düşünüldüğünde hangi seviyede yapılacağına karar verilmelidir.
|}
|}
== 2.3. BAKIM ÇÖZÜM ÖNERİSİNİN OLUŞTURULMASI ==
== 2.3. BAKIM ÇÖZÜM ÖNERİSİNİN OLUŞTURULMASI ==
Hem maliyet hem de teknik kriterlerin birlikte değerlendirilmesi kritiktir. BGA kapsamında belirlenen görevler üzerinden değerlendirme hem teknik hem mali olarak yapılır ve onarım kararı ya da envanterden çıkarma kararı verilir. Her bir görev kapsamında bu kararlar verildikten sonra, bu görevlerin hangi seviyelerde yapılacağı belirlenir. Ayrıca, tanımlanan benzer bakım faaliyetlerinin mümkün olduğunca tek bir bakım yeri için tanımlanmış olması da (onarım yapılacak kalemin bir kısmının bir bakım merkezinde bir kısmının başka bir bakım merkezinde yapılmaması gibi) önemlidir. Yapılan tüm analiz çalışması sonunda sistemin bakım çözüm önerisi oluşturulmuş olacaktır.
Hem maliyet hem de teknik kriterlerin birlikte değerlendirilmesi kritiktir. BGA kapsamında belirlenen görevler üzerinden değerlendirme hem teknik hem mali olarak yapılır ve onarım kararı ya da envanterden çıkarma kararı verilir. Her bir görev kapsamında bu kararlar verildikten sonra, bu görevlerin hangi seviyelerde yapılacağı belirlenir. Ayrıca, tanımlanan benzer bakım faaliyetlerinin mümkün olduğunca tek bir bakım yeri için tanımlanmış olması da (onarım yapılacak kalemin bir kısmının bir bakım merkezinde bir kısmının başka bir bakım merkezinde yapılmaması gibi) önemlidir. Yapılan tüm analiz çalışması sonunda sistemin bakım çözüm önerisi oluşturulmuş olacaktır.
|}
|}
= EK-G BAKIM GÖREV ANALİZİ (BGA) =
= EK-G BAKIM GÖREV ANALİZİ (BGA) =
== 1. GENEL ==
== 1. GENEL ==
Bakım faaliyetleri, sistem konfigürasyonunda bulunan ve görev için kritik olan bütün ekipmanlar için gereksinimlere uygun olarak, görev faaliyetlerini kesintiye uğratmayacak, sorunsuz ve kazasız bir şekilde tamamlanmasına yönelik tedbirlerin alınması ve gerektiğinde müdahale edilmesi esasına dayanır. Bu amaca yönelik her türlü kaynak ihtiyacı (iş gücü, malzeme, tesis vb.) önceden hesaplanmalı ve tahsis edilmelidir.
Bakım faaliyetleri, sistem konfigürasyonunda bulunan ve görev için kritik olan bütün ekipmanlar için gereksinimlere uygun olarak, görev faaliyetlerini kesintiye uğratmayacak, sorunsuz ve kazasız bir şekilde tamamlanmasına yönelik tedbirlerin alınması ve gerektiğinde müdahale edilmesi esasına dayanır. Bu amaca yönelik her türlü kaynak ihtiyacı (iş gücü, malzeme, tesis vb.) önceden hesaplanmalı ve tahsis edilmelidir.
BGA, geliştirme safhasında yapılması gereken bir analiz faaliyetidir. Diğer taraftan ihtiyaç olması halinde (tasarım değişikliği, modifikasyon vb) ilgili safhalarda güncellenebilecek bir analizdir.
BGA, geliştirme safhasında yapılması gereken bir analiz faaliyetidir. Diğer taraftan ihtiyaç olması halinde (tasarım değişikliği, modifikasyon vb) ilgili safhalarda güncellenebilecek bir analizdir.
== 2. ANALİZLER ==
== 2. ANALİZLER ==
== 2.1. BAKIM GÖREVLERİNİN BELİRLENMESİ ==
== 2.1. BAKIM GÖREVLERİNİN BELİRLENMESİ ==
Bakım görevleri belirlenirken ürün kırılımının yapılmış ve LDA adayı kalemlerin listelenmiş olması gerekmektedir. LDA adayı olarak seçilen her bir kalem için bakım görevleri belirlenmelidir.
Bakım görevleri belirlenirken ürün kırılımının yapılmış ve LDA adayı kalemlerin listelenmiş olması gerekmektedir. LDA adayı olarak seçilen her bir kalem için bakım görevleri belirlenmelidir.
Özel olay sonrası gerekli olan muayeneler ve/veya GMB sonrasında; genel, kullanıcı talebine bağlı ve/veya hazırlık için yapılacak faaliyetlerden kaynaklı bakım görevleri ortaya çıkabilir. Bu faaliyetlerin de BGA kapsamında değerlendirilmesi gerekmektedir.
Özel olay sonrası gerekli olan muayeneler ve/veya GMB sonrasında; genel, kullanıcı talebine bağlı ve/veya hazırlık için yapılacak faaliyetlerden kaynaklı bakım görevleri ortaya çıkabilir. Bu faaliyetlerin de BGA kapsamında değerlendirilmesi gerekmektedir.
== 2.2. BAKIM GÖREV YAPILARININ OLUŞTURULMASI ==
== 2.2. BAKIM GÖREV YAPILARININ OLUŞTURULMASI ==
Görev yapıları oluşturulurken görevler analiz faaliyetinde kolaylık sağlaması açısından iki sınıfa ayrılır.
Görev yapıları oluşturulurken görevler analiz faaliyetinde kolaylık sağlaması açısından iki sınıfa ayrılır.
Bazı tasarımsal sebeplerden kaynaklı sistem hataları öngörülemeyebilir. Hasar ya da özel olayların meydana gelmesi ile ilgili benzer sistemler ve/veya benzer projeler kapsamında edinilmiş herhangi bir tecrübe varsa, bu tecrübe öngörülemeyen olayların ne kadar sıklıkla meydana gelebileceği ve ilgili bakım faaliyetlerinin sıklığı konusunda fikir verebilir. Bu nedenle, bakım faaliyetleri ile ilgili planlama yapılırken uygulanabilir olduğu ölçüde öngörülemeyen bu tarz olayların da dikkate alınması önemlidir.
Bazı tasarımsal sebeplerden kaynaklı sistem hataları öngörülemeyebilir. Hasar ya da özel olayların meydana gelmesi ile ilgili benzer sistemler ve/veya benzer projeler kapsamında edinilmiş herhangi bir tecrübe varsa, bu tecrübe öngörülemeyen olayların ne kadar sıklıkla meydana gelebileceği ve ilgili bakım faaliyetlerinin sıklığı konusunda fikir verebilir. Bu nedenle, bakım faaliyetleri ile ilgili planlama yapılırken uygulanabilir olduğu ölçüde öngörülemeyen bu tarz olayların da dikkate alınması önemlidir.
== 2.3. GÖREV KAYNAKLARININ BELİRLENMESİ ==
== 2.3. GÖREV KAYNAKLARININ BELİRLENMESİ ==
Bir görevin yerine getirilmesi için gerekli olan kaynakların (özel bir ekipman kullanımı için personel eğitimi de dahil) görevin içinde tanımlanması gerekmektedir. Görevin yerine getirilmesi kapsamında gerekli olan yedek parçalar, destek ekipmanı, personel, alt yapı gibi kaynakların belirlenmesi ve ilgili görevlere atanması gerekmektedir. Görev kaynaklarına ilişkin örnekler ve açıklamaları Tablo 20’de verilmiştir.
Bir görevin yerine getirilmesi için gerekli olan kaynakların (özel bir ekipman kullanımı için personel eğitimi de dahil) görevin içinde tanımlanması gerekmektedir. Görevin yerine getirilmesi kapsamında gerekli olan yedek parçalar, destek ekipmanı, personel, alt yapı gibi kaynakların belirlenmesi ve ilgili görevlere atanması gerekmektedir. Görev kaynaklarına ilişkin örnekler ve açıklamaları Tablo 20’de verilmiştir.
Örnek BGA Formu:
Örnek BGA Formu:
= EK-H YAZILIM DESTEK ANALİZİ (YDA) =
== 1. GENEL ==
== 1. GENEL ==
Sistemin desteklenebilirliğini sağlayabilmek için LDA süreci kapsamında yazılımlar için de YDA süreci yürütülür. YDA, maliyet etkin bir yazılım destek konseptinin kurulması için donanıma benzer şekilde yazılım açısından da sistemi desteklemeyi amaçlar. Yazılım Destek Konsepti (YDK) belirlenirken, bir ürün içerisindeki yazılımın kullanımının devamlılığını sağlamak için gerekli tüm aktivitelerin dikkate alınması gerekir. YDA’da, yeterli bir YDK geliştirmek için ekipman, araç, personel, dokümantasyon, altyapı, gerekli yetkinlik ve eğitim gibi hususlar analiz edilir.
Sistemin desteklenebilirliğini sağlayabilmek için LDA süreci kapsamında yazılımlar için de YDA süreci yürütülür. YDA, maliyet etkin bir yazılım destek konseptinin kurulması için donanıma benzer şekilde yazılım açısından da sistemi desteklemeyi amaçlar. Yazılım Destek Konsepti (YDK) belirlenirken, bir ürün içerisindeki yazılımın kullanımının devamlılığını sağlamak için gerekli tüm aktivitelerin dikkate alınması gerekir. YDA’da, yeterli bir YDK geliştirmek için ekipman, araç, personel, dokümantasyon, altyapı, gerekli yetkinlik ve eğitim gibi hususlar analiz edilir.
Yazılım bakım ve idamesi dört şekilde ele alınabilir:
Yazılım bakım ve idamesi dört şekilde ele alınabilir:
* Teslim edilen yazılım ürünlerindeki hataların giderilmesi (düzeltici bakım);
* Yazılımın performansının ve özelliklerinin iyileştirilmesi (mükemmelleştirici bakım);
* Yazılımın değişen çevre koşullarına, donanıma, işletim sistemine ve muhtelif arayüzlere adaptasyonu (uyarlayıcı bakım);
* Yazılımın daha az karmaşık, daha anlaşılabilir, bakımının daha kolay yapılabildiği şekle çevrilmesi (önleyici bakım).
Yazılım bakım ve idame süreci kapsamında en az aşağıdaki faaliyetlerin gerçekleştirilmesi tavsiye edilir:
Yazılım bakım ve idame süreci kapsamında en az aşağıdaki faaliyetlerin gerçekleştirilmesi tavsiye edilir:
* Bakım planı ve bakım süreçlerinin oluşturulması;
* Problem Raporu ve Değişiklik İsteği süreçlerinin oluşturulması (taleplerin alınması, kaydedilmesi, güncellenmesi, izlenmesi, testlerle doğrulanması ve geri beslemenin yapılması);
* Konfigürasyon yönetiminin uygulanması.
Yazılım değişikliklerinin sisteme entegre edilmesi aşamasından önce bazı analizler yapılır. Yapılacak bakımın:
Yazılım değişikliklerinin sisteme entegre edilmesi aşamasından önce bazı analizler yapılır. Yapılacak bakımın:
* Niteliği (düzeltici, uyarlayıcı vb.);
* Kapsamı (yazılımdaki değişikliğin büyüklüğü, işlemlerin maliyeti, bakım süresi);
* Kritikliği (performans, emniyet, bilgi güvenliği hususları) değerlendirilir.
== 2. FARKLI PROJE SAFHALARINDA YDA ==
== 2. FARKLI PROJE SAFHALARINDA YDA ==
YDA’nın yazılım içeren bir ürün için tüm ömür devri boyunca uygulanması gerekmektedir. Yapılacak faaliyetler, proje safhaları dikkate alınarak gerçekleştirilmelidir. Örneğin, geliştirme safhasında, YDA’nın uygulaması önemlidir çünkü yazılımın gelecekteki yükleme, servis ve modifikasyonları için desteklenebilirlik gereksinimleri açısından yazılım mimarisi ve tasarımı etkilenebilir.
YDA’nın yazılım içeren bir ürün için tüm ömür devri boyunca uygulanması gerekmektedir. Yapılacak faaliyetler, proje safhaları dikkate alınarak gerçekleştirilmelidir. Örneğin, geliştirme safhasında, YDA’nın uygulaması önemlidir çünkü yazılımın gelecekteki yükleme, servis ve modifikasyonları için desteklenebilirlik gereksinimleri açısından yazılım mimarisi ve tasarımı etkilenebilir.
Erken fazlarda, YDA temel yazılım destek gereksinimlerinin belirlenmesine yardımcı olur. Envanterden çıkarma safhasında, donanımlar için olduğu gibi yazılımlar için de envanterden çıkarma prosedürlerinin tanımlanması gerekmektedir. Eğer yazılım verisi yeni geliştirilecek sistemler veya ilerleyen operasyonlarda kullanılacaksa, verilerin yer değiştirilmesi hususu kapsamında uygulanması gereken prosedürlerin de göz önünde bulundurulması ve tanımlanması gerekmektedir.
Erken fazlarda, YDA temel yazılım destek gereksinimlerinin belirlenmesine yardımcı olur. Envanterden çıkarma safhasında, donanımlar için olduğu gibi yazılımlar için de envanterden çıkarma prosedürlerinin tanımlanması gerekmektedir. Eğer yazılım verisi yeni geliştirilecek sistemler veya ilerleyen operasyonlarda kullanılacaksa, verilerin yer değiştirilmesi hususu kapsamında uygulanması gereken prosedürlerin de göz önünde bulundurulması ve tanımlanması gerekmektedir.
== 3. YAZILIM KIRILIM KONSEPTİ ==
== 3. YAZILIM KIRILIM KONSEPTİ ==
Yazılımlar için de donanımlara benzer olarak fiziksel veya işlevsel konsept değerlendirilerek bir kırılım gerçekleştirilebilir. Yazılımın yüklendiği üst donanımlarından birisinin elemanı olması, yazılımın kendisini çalıştıran donanımın bir elemanı olması veya yazılımın fiziksel olarak üzerinde bulunduğu donanımın bir elemanı olması örnek olarak verilebilir.
Yazılımlar için de donanımlara benzer olarak fiziksel veya işlevsel konsept değerlendirilerek bir kırılım gerçekleştirilebilir. Yazılımın yüklendiği üst donanımlarından birisinin elemanı olması, yazılımın kendisini çalıştıran donanımın bir elemanı olması veya yazılımın fiziksel olarak üzerinde bulunduğu donanımın bir elemanı olması örnek olarak verilebilir.
LDA ürün kırılımında bir yazılım kalemini yönetmenin en kolay yolu yazılımı kategorilerine göre HDB, ADB veya parça/komponent olarak tanımlamaktır. Fiziksel yazılım kategorileri 3 başlık altında incelenebilir;
LDA ürün kırılımında bir yazılım kalemini yönetmenin en kolay yolu yazılımı kategorilerine göre HDB, ADB veya parça/komponent olarak tanımlamaktır. Fiziksel yazılım kategorileri 3 başlık altında incelenebilir;
* Alanda Yüklenebilir Yazılım (Field-Loadable Software); bir sistem/ürün üzerindeki ekipmanın bir veya birkaç parçasına ekipmanı demonte etmeden yüklenebilen yazılımdır.
* Atölyede Yüklenebilir Yazılım (Shop-Loadable Software); bir HDB üzerinde yüklenebilecek bir yazılımdır ancak HDB’nin üründen demontajını gerektirir.
* Yerleşik Yazılım/Bellenim; HDB veya ADB’ye yüklenebilecek ancak operasyonel ürün üzerindeki yükleniminin demontajı ve bir komponentin yeniden konumlandırılmasını gerektirebilecek yazılımdır.
İşlevsel kırılım, yazılımın nasıl modifiye ve entegre edileceği ile yeniden tasarım olduğunda farklı yazılım elemanlarının arasındaki dikkate alınması gereken ilişkiyi gösterir. İşlevsel kırılımda yer alan yazılım kalemleri yazılımın diğer yazılımlarla entegrasyon ihtiyacından ötürü işlevsel/tasarım açılarını tanımlarlar. Böyle bir kırılım, yazılım modifikasyon desteği için kritiktir. Bu yüzden de işlevsel kırılımın yazılım tasarımını olabildiğinde takip etmesi önemlidir.
İşlevsel kırılım, yazılımın nasıl modifiye ve entegre edileceği ile yeniden tasarım olduğunda farklı yazılım elemanlarının arasındaki dikkate alınması gereken ilişkiyi gösterir. İşlevsel kırılımda yer alan yazılım kalemleri yazılımın diğer yazılımlarla entegrasyon ihtiyacından ötürü işlevsel/tasarım açılarını tanımlarlar. Böyle bir kırılım, yazılım modifikasyon desteği için kritiktir. Bu yüzden de işlevsel kırılımın yazılım tasarımını olabildiğinde takip etmesi önemlidir.
Yazılım modifikasyonuna yönelik olarak işlevsel yazılım kırılımı yazılım tasarım gereksinimlerini takip eder. Klasik yazılım konfigürasyon kalem seviyesi yaklaşımına ek olarak daha üst seviyede (altsistem ve sistem seviyesi) yazılımın sisteme entegrasyonunun da değerlendirilmesi gerekmektedir.
Yazılım modifikasyonuna yönelik olarak işlevsel yazılım kırılımı yazılım tasarım gereksinimlerini takip eder. Klasik yazılım konfigürasyon kalem seviyesi yaklaşımına ek olarak daha üst seviyede (altsistem ve sistem seviyesi) yazılımın sisteme entegrasyonunun da değerlendirilmesi gerekmektedir.
== 4. YAZILIM DESTEK ANALİZİ ==
== 4. YAZILIM DESTEK ANALİZİ ==
Ürün kullanım safhasına girmeden gerekli destek altyapısının sağlandığından emin olmak önemlidir. YDA’nın amacı, yazılım desteklenebilirlik gereksinimlerini erken safhalarda belirlemek ve sistem operasyonu ve sonraki değişikliklerin desteklenebilirliği için yazılım tasarımını etkilemektir.
Ürün kullanım safhasına girmeden gerekli destek altyapısının sağlandığından emin olmak önemlidir. YDA’nın amacı, yazılım desteklenebilirlik gereksinimlerini erken safhalarda belirlemek ve sistem operasyonu ve sonraki değişikliklerin desteklenebilirliği için yazılım tasarımını etkilemektir.
== 4.1. YDA ADAY KALEM SEÇİMİ ==
== 4.1. YDA ADAY KALEM SEÇİMİ ==
Donanım aday kalem seçimiyle benzer yaklaşım izlenecektir.
Donanım aday kalem seçimiyle benzer yaklaşım izlenecektir.
== 4.2. YAZILIM BAKIMI ==
== 4.2. YAZILIM BAKIMI ==
Bakım faaliyeti gerektirecek tüm olaylar, yazılım desteğinin başlangıcı olarak değerlendirilebilir. Bu olaylar, operasyonel, teknik, yazılım geliştirme gereksinimleri ve yazılım hataları olarak gruplanabilir.
Bakım faaliyeti gerektirecek tüm olaylar, yazılım desteğinin başlangıcı olarak değerlendirilebilir. Bu olaylar, operasyonel, teknik, yazılım geliştirme gereksinimleri ve yazılım hataları olarak gruplanabilir.
* Operasyonel olaylar; operasyonel bir gereksinim ile ilgili, donanım üzerinden dokümante edilebilen donanım bakımını, kullanıma hazırlığı ve görev sonrası gereksinimleri kapsayan olaylardır.
* Teknik olaylar; yazılım paketinin, değişen koşullara olan adaptasyonunu gerektirir. Yazılımın üzerinde olduğu donanımın değişmesi, birbiriyle çalışan sistemlerin teknolojisinde değişme örnek olarak verilebilir.
* Yazılım geliştirme gereksinimleri; yazılım değişiklikleri yazılım paketinin karmaşıklığı ve boyutuna göre değişen aralıklarda yapılır. Yazılım hatalarının düzeltilmesinin yanında, yeni yazılım yayımlanması için son kullanıcı gereksinimleri ve koşullardaki değişikliklere girdi sağlar. Yazılım geliştirme demek, geliştirilecek yeni özellikler veya genişletilecek fonksiyonellik veya mevcut yazılımın kullanım konforu demektir.
* Yazılım hataları; desteği başlatan ana sebep yazılım hatalarıdır. Bu hatalara verilecek destek ile ilişkili reaksiyonlar hatanın ciddiyetine bağlıdır. Her yazılım hatası yazılım modifikasyonu gerektirmeyecektir. Modifikasyonun gerekli olmadığı durumlarda bile, bir sonraki hatanın tespiti için dokümantasyonun doğru hazırlanmış olması gerekmektedir.
** Minör hata: Genellikle, kullanıcının sistemi kullanım konforu ve ergonomisi ile ilişkili olup sistemin operasyonel kullanımı ile ilgili kritiklik yaratmayan ancak gene de hata olarak ele alınması gereken durumlardır.
** Orta seviye hata: Sistemin işlevselliğini azaltan hatalardır. Sistemin kullanımı azalan bir performans veya hiçbir kısıtlama dahi olmadan devam edebilir.
** Major hata: Tüm sistemin tamamen kapatılmasına veya çok kısıtlı koşullar altında çalışmasına neden olan kabul edilemez hatalardır. Sistem performansı ciddi oranda azalır.
Yazılım hataları donanım hataları gibi belirli onarım değişim prosedürleriyle ele alınamaz. Bu yüzden bir yazılım hatasında alınması gerekli olan aksiyon hemen bilinemeyeceğinden alınamayabilir. Örneğin bir yazılım hatasında sistemi kapatıp açmak hatayı düzeltebilirken, diğer bir hatada sistemi kapattıktan sonra sistemin daha fazla zarar görmemesi için tekrar açılmaması gerekebilecektir. Ya da bir donanımdaki bozulma sebebiyle de yazılım çalışmayabilir. Bu durumda yazılım kaynak kodunda gerçek bir doğal hata bulunmamakta olup bu durum dış hasar olarak ele alınır.
Yazılım hataları donanım hataları gibi belirli onarım değişim prosedürleriyle ele alınamaz. Bu yüzden bir yazılım hatasında alınması gerekli olan aksiyon hemen bilinemeyeceğinden alınamayabilir. Örneğin bir yazılım hatasında sistemi kapatıp açmak hatayı düzeltebilirken, diğer bir hatada sistemi kapattıktan sonra sistemin daha fazla zarar görmemesi için tekrar açılmaması gerekebilecektir. Ya da bir donanımdaki bozulma sebebiyle de yazılım çalışmayabilir. Bu durumda yazılım kaynak kodunda gerçek bir doğal hata bulunmamakta olup bu durum dış hasar olarak ele alınır.
== 4.3. YDA KAPSAMINDA HTEKA/HTEA ==
== 4.3. YDA KAPSAMINDA HTEKA/HTEA ==
HTEKA/HTEA tüm sistemde gerçekleştirilen bir analiz methodu olduğu için yazılım kalemleri ile de doğrudan ilişkilidir. Tanımlanmış olan her bir hata modu için işlevsellik bir yazılıma mı dayalı ya da komple bir yazılım tarafından mı sağlanıyor kararı verilmelidir. Yazılımın geliştirme safhasında, yazılım mimarisinde ilgili hata modu bilgilerinin sistemde spesifik bir hataya sebep olmasını engelleyecek ya da en azından azaltacak şekilde dikkate alınması gerekmektedir. Ayrıca, tasarım, yazılım hatalarının tespit edilebildiği, kayıt altına alınabildiği ve sistemin güvenli modda çalışmaya devam edeceği şekilde olmalıdır.
HTEKA/HTEA tüm sistemde gerçekleştirilen bir analiz methodu olduğu için yazılım kalemleri ile de doğrudan ilişkilidir. Tanımlanmış olan her bir hata modu için işlevsellik bir yazılıma mı dayalı ya da komple bir yazılım tarafından mı sağlanıyor kararı verilmelidir. Yazılımın geliştirme safhasında, yazılım mimarisinde ilgili hata modu bilgilerinin sistemde spesifik bir hataya sebep olmasını engelleyecek ya da en azından azaltacak şekilde dikkate alınması gerekmektedir. Ayrıca, tasarım, yazılım hatalarının tespit edilebildiği, kayıt altına alınabildiği ve sistemin güvenli modda çalışmaya devam edeceği şekilde olmalıdır.