Lojistik Destek Analizleri ve Kayıtları Rehberi sayfasının kaynağını görüntüle


'''[https://tssodypwiki.ssb.gov.tr/images/9/95/TSSODYP_06_180822_web.pdf pdf formatı için tıklayınız.]'''


TSSÖDYP, Savunma Sanayii Başkanlığı çatısı altında faaliyet göstermektedir.

© Fikri mülkiyet hakları T.C. Cumhurbaşkanlığı Savunma Sanayii Başkanlığına aittir. Kaynak gösterilmek kaydıyla alıntı yapılabilir. Üzerinde değişiklik yapmamak kaydıyla olduğu gibi çoğaltılabilir, dağıtılabilir. Para ile satılmaz.

[[Dosya:Başkan resmi y.logo.jpg|sol|küçükresim|430x430px]]





























Savunma  Sanayii Başkanlığı çatısı altında, ilgili tüm paydaşların katılımıyla  faaliyet göstermek üzere Türk Savunma Sanayii Ömür Devri Yönetimi Platformu  (TSSÖDYP) kurulmuştur.

TSSÖDYP;  savunma ve güvenlik sistemlerine ilişkin ihtiyacın belirlenmesi, sistemlerin  tedariki, kullanımı, desteklenmesi ve envanterden çıkarması safhalarını bir  bütün halinde ele alan Sistem Ömür Devri Yönetimi ilke ve uygulamalarının  ülkemizde yaygınlaştırılmasını ve savunma programlarının/ projelerinin  yürütülmesinde savunma ve güvenlik ekosistemini oluşturan tüm paydaşlarca  anlayış birliğine ulaşılmasını amaçlamaktadır.

Savunma sistemlerinin ömür devri yönetiminde millî bünyemize  uygun, ülkemize özgü çözümler üretmek ve bunları dokümante etmek gibi önemli  bir misyonu olan TSSÖDYP; Başkanlığımız, Milli Savunma Bakanlığı ve ilgili  birimleri, Genelkurmay Başkanlığı, K.K.K.lığı, Dz.K.K.lığı, Hv.K.K.lığı,  J.Gn.K.lığı, S.G.K.lığı, EGM, TÜBİTAK, SASAD ve savunma sanayii firmaları  temsilcilerinin katılımı ile çalışmalarına devam etmektedir.

Sistem ömür devri yönetimi yaklaşımı ile; savunma ve güvenlik  sistemlerine ilişkin ihtiyacın belirlenmesi aşamasından envanterden çıkarma  safhasının sonuna kadar görev alan tüm kamu kurum ve kuruluşları ile özel  sektör firmalarının sistemlerin istenilen performans seviyesinde mümkün olan  en az maliyetle tedariki, kullanımı ve lojistik desteğinin sağlanabilmesi  için görev, yetki ve sorumlulukları çerçevesinde ömür devrinin tamamında  birlikte çalışmaları öngörülmektedir.

Bu itibarla, savunma ve güvenlik sistemlerine ilişkin ihtiyacın  belirlenmesinin, tedarikinin, kullanımının, lojistik desteğinin ve  envanterden çıkarılmasının en baştan uzun soluklu bir program olarak  kurgulanmasının ve ilgili birimler aracılığı ile sistem ömür devri yönetimi  faaliyetlerinin yürütülmesinin faydalı olacağı değerlendirilmektedir.

TSSÖDYP tarafından son iki buçuk yıl içinde gerçekleştirilen  çalışmalar ile savunma ve güvenlik sistemlerinin ömür devri yönetimine  ilişkin planlama ve uygulamaya esas olacak yaklaşımları ortaya koyan 13 adet  rehber, iki adet bilgi kitapçığı ve bir adet terminoloji dokümanı  hazırlanmıştır.  Uygulamalardan  alınacak geri bildirimler ile söz konusu dokümanların güncellenmesi,  geliştirilmesi ve önümüzdeki dönemde uygulamaya esas düzenlemelerin alt  yapısını oluşturması hedeflenmektedir.

TSSÖDYP çalışmalarına katkı veren ve dokümanların  hazırlanmasında görev alan tüm paydaşlarımıza teşekkürlerimi sunuyorum.


Prof.Dr. İsmail DEMİR

T.C. Cumhurbaşkanlığı

Savunma Sanayii Başkanı



<big>'''ÖZET'''</big>

Tehdit algısında ve savunma konseptinde zamanla meydana gelen değişiklikler, savunma sistemlerinin ömür devri maliyetlerindeki artışlar, savunma bütçelerindeki kısıtlamalar, teknolojideki hızlı gelişmeler, uluslararası rekabet ve günümüz sistemlerinin karmaşıklığı gibi faktörler, kamu ve özel sektörün savunma sistemlerinin tedarikine ve lojistik desteğine yönelik faaliyetlerinin planlanmasında ve icrasında yeni yaklaşımlar ve buna bağlı yeni stratejiler geliştirilmesini zaruri hale getirmiştir.

Bu nedenle, tedarik edilen sistemlerin kullanım döneminde hedeflenen muharebe ve/veya operasyon performansının sürdürülebilirliğinin ve maliyet etkinliğinin sağlanması amacıyla sistemlerin ömür devrinde rol ve sorumluluğu bulunan tüm paydaşların katılımı ile Sistem Ömür Devri Yönetimi yaklaşımı geliştirilmiştir.

Sistem Ömür Devri Yönetiminin temel amacı; mevcut durumdaki değişimlere uyum sağlamaktan ziyade gelecekte ortaya çıkabilecek değişimleri öngörmek, belirlenen hedefler doğrultusunda gerekli önlemleri alarak değişimleri yönlendirmek ve kontrol altında tutmaktır. Harekât ihtiyaçlarının zamanında ve verimli şekilde karşılanması ve sahip olunan kaynakların maliyet etkin kullanımı esastır. Başka bir deyişle, sistem ömür devri yönetimi geleceği bugünden tasarlamak ve planlamaktır.

Bu doküman; Savunma Sanayii Başkanlığı (SSB), Milli Savunma Bakanlığının ilgili birimleri, Türk Silahlı Kuvvetleri (TSK), diğer ihtiyaç makamları ve savunma sanayi firmalarında sistem ömür devri yönetiminin bir kültür olarak yaygınlaştırılmasına ve uygulanmasına yönelik rehber oluşturmak amacıyla savunma sistemlerinin ömür devrinde rol ve sorumluluğu bulunan ilgili paydaşların katılımıyla hazırlanmıştır.

Lojistik Destek Analizi (LDA); desteklenebilirlik açısından ürün tasarımını etkilemeyi amaçlayan tasarımın erken aşamalarında başlayıp ömür devri boyunca devam eden güvenilirliği, kullanıma hazır olmayı, idame edilebilirliği, maliyeti ve zaman etkinliğini ön plana çıkaran analizlerden oluşan bir süreçtir.

LDA, sistemin ve bileşenlerinin belirlenmiş kullanıma hazır olma ve desteklenebilirlik /sürdürülebilirlik ihtiyaçlarına ulaşılabilmesi amacıyla ürün tasarımı ile destek sistemini/organizasyonunu entegre eden sistematik ve yinelemeli analizler bütünüdür. LDA sonuçları elektronik veritabanında dokümante edilir. Lojistikle ilgili dokümante edilen bilgiler Entegre Lojistik Destek (ELD) fiziksel kaynaklarının (örn. iş gücü ve personel, yedek parça, eğitim, destek ekipmanları, eğitim ve eğitim desteği teknik yayınlar vb) belirlenmesini, optimize edilmesini ve izlenebilirliğini sağlar.

= 1. GENEL =

== 1.1. GİRİŞ ==
Bu doküman, Türk Savunma Sanayii Ömür Devri Yönetim Platformu (TSSÖDYP) tarafından Entegre Lojistik Destek (ELD) faaliyetlerinin merkezinde yer alan Lojistik Destek Analizleri’nin (LDA) gerçekleştirilmesi ve bu analizler sonrasında oluşturulacak LDA Kayıtları konusunda rehberlik etmek üzere hazırlanmıştır.

== 1.2. AMAÇ ==
Bu rehberin amacı ülkemizde yürütülen program/projelerde savunma ve güvenlik sistemlerinin ömür devri boyunca gerçekleştirilebilecek LDA faaliyetlerine yönelik uygulanması önerilen süreçleri, genel gereksinimleri ve bilgi/veri değişim yöntemlerini tanımlamaktır. Rehber aynı zamanda ihtiyaç makamı, kullanıcı, idame makamı, tedarik makamı, yüklenici, ve diğer paydaşlar arasında LDA faaliyetlerinin gerçekleştirilmesine yönelik arayüzleri ortaya koymayı ve LDA ihtiyaçlarının sözleşmelerde en doğru şekilde tanımlanabileceği, LDA çıktılarının neler olabileceği ve paydaşlar tarafından nasıl kullanılabileceğine dair yol gösterici olmayı hedeflemektedir.

Desteklenebilir ürünler ve en uygun destek çözümlerinin maliyet etkin şekilde geliştirilmesinde önemli bir rolü olan LDA faaliyetlerinin ürün ömür devri safhalarına uygun olacak şekilde yürütülmesi ve proje türü ve büyüklüğüne göre uyarlanması gerekmektedir. Bu çerçevede, kaynakların etkin şekilde kullanılması ve yürütülen faaliyetlerden azami seviyede verim elde edilmesi rehberin birincil amaçları arasında yer almaktadır.

Bu doküman, savunma ve güvenlik sektöründe görev alan tüm paydaşların Lojistik Destek Analizleri ve Kayıtları faaliyetlerinde rehberlik etmek üzere hazırlanmıştır.

== 1.3. KAPSAM ==
Bu rehber:

* Savunma ve güvenlik projelerinde/programlarında yürütülecek lojistik destek analizleri ve yöntemleri hakkında bilgiler, 
* LDA süreçleri ve gereksinimleri,
* Analiz sonuçlarının nasıl değerlendirileceği ve maliyet-etkin bir çözüme nasıl ulaşılabileceğine dair kılavuz bilgiler,
* LDA ve desteklenebilirlik mühendisliği disiplinleri (Örn. güvenilirlik, idame edilebilirlik, test edilebilirlik, sürdürülebilirlik, kullanıma hazır olma) arasındaki ara yüzler,
* LDA ve diğer ELD elemanları (ikmal destek, teknik veri, eğitim ve eğitim desteği vb.) arasındaki ara yüzler,
* LDA sürecinin nasıl uyarlanacağına dair genel ilkeler,

hakkında bilgiler içermektedir.

== 1.4. REHBERİN KULLANIMI ==
Bu doküman savunma ve güvenlik projelerinde/programlarında kullanılabilecek LDA sürecinin ve metodolojisinin ana hatlarıyla tanımlanması amacıyla 5 bölümden oluşmaktadır:

* İlk bölüm; giriş, amaç, kapsam, referanslar gibi genel bilgileri     içermektedir; ayrıca terim ve kısaltmalar da bu bölümün içindedir.
* İkinci bölümde, lojistik destek analizleri ile ilgili genel bir     bilgilendirme yapılmaktadır.
* Üçüncü bölümde; sistem tasarımının ayrılmaz bir parçası     olan desteklenebilirlik     kavramı ve desteklenebilirlik ilişkili tasarım faktörlerinin hangi     aşamalarda değerlendirilmesi gerektiği hususlarına yönelik açıklayıcı     bilgiler yer almaktadır.
* Dördüncü bölümde, herhangi bir projenin başlangıç     aşamasında ihtiyaç makamı ve yüklenicinin LDA gereksinimlerinin belirlenmesine ilişkin nasıl anlaşmaya varacaklarına yönelik izlenecek yol yer almaktadır,
* Beşinci bölümde, yüklenici ve müşteri uygun desteklenebilirlik seviyesine erişmek     için gerçekleştirilmesi gereken faaliyetlerin tanımlandığı LDA süreci açıklanmaktadır,
* Altıncı bölümde, tasarıma etki/tasarım etkileşimi
* Yedincibölümde, kullanım ve destek     safhalarında gerçekleştirilen LDA ve bu analizler sonucunda     reaktif/proaktif aksiyonların alınarak ürün performansının beklenen     düzeyde seyrinin sağlanmasına ilişkin süreç yer almaktadır,
* Sekizinci bölümde, konfigürasyonlarının doğru belirlenmesi, değişikliklerin kontrol     edilmesi ve değişikliklerin uygulanma durumunun kayıt altına alınmasını     sağlayan konfigürasyon     yönetimi disiplininde izlenebilirliğin LDA çerçevesinde yürütülmesi ilişkisi     yer almaktadır,
* Dokuzuncu bölümde, LDA’nın lojistik desteğin     yönetilmesi için düzenli yürütülerek kayıt altına alınması,     değerlendirilmesi faaliyetlerinin esasları ve standartları açıklanmaktadır.     Programlara/projelere     özgü olarak yine ihtiyaç sahipleri ve yükleniciler bu rehberde referans     verilen veya diğer ulusal/uluslararası standart/spesifikasyonların ilave     olarak kullanılması konusunda mutabakat sağlayabilirler. Projenin/ürünün     karmaşıklık seviyesi ilave olarak kullanılabilecek     standart/spesifikasyonları belirlemede de etken olacaktır,
* Onuncu bölümde, fiziksel destek kaynak     gereksinimlerinin belirlenmesi ve destek ürünlerinin oluşturulması     kapsmaında ELD elemanlarına ilişkin çalışmaların yürütlmesine yönelik     bilgiler verilmektedir,
* Onbirinci bölümde, LDA ve kayıtlarına     ilişkin faaliyetlerin uyarlanmasına yönelik olarak tanımlanan bütün     faaliyetlerin/analizlerin her türlü projede ve her safhada gerçekleştirmek     yerine etkin uygulamaların yapılmasını sağlamak amacıyla kullanıcıların     projelere özgü görev/faaliyetleri seçebilmesi için yol gösterecek içerik     yer almaktadır,
* Dokümanın son bölümünde     ise ilgili ekler yer almaktadır.

== 1.5. REHBERİN GÜNCELLENMESİ ==
Rehberin yüklenici, ihtiyaç makamı ve diğer paydaşlar tarafından referans alınarak kullanılması kapsamında güncellenme ihtiyacının olması durumunda aşağıda sunulan izleme tablosu yardımıyla değişikliklerin takibi sağlanacaktır.

'''Tablo 1 Değişiklik İzleme Tablosu'''
{| class="wikitable"
|'''Revizyon No'''
|'''Revizyon Tarihi'''
|'''Değişiklik Yapılan Başlık No'''
|'''Yapılan Değişiklik'''
|-
|01
|Ağustos  2021
|
|İlk Yayın
|-
|
|
|
|
|-
|
|
|
|
|}

== 1.6.   REFERANSLAR ==
{| class="wikitable"
|1.
|MIL-HDBK-502A Product Support Analysis, Mart 2013
|-
|2.
|ASD/AIA S3000L International Procedure Specification   for Logistics Support Analysis (LSA), Temmuz 2014
|-
|3.
|ASD S4000P International Specification for Developing   and Continuously Improving Preventive Maintenance, Ağustos 2018
|-
|4.
|MIL-STD-1388-2B DoD Requirements for a Logistic   Support Analysis Record, Mart 1991
|-
|5.
|SAE ARP5580 Recommended Failure Modes and Effects   Analysis (FMEA) Practices for Non-Automobile Applications
|-
|6.
|TSSÖDYP Doküman Seti
|}
{| class="wikitable"
|+
! colspan="2" |'''TSSÖDYP DOKÜMAN SETİ'''
|-
|'''DOKÜMAN ADI  '''
| '''DOKÜMAN KODU'''
|-
|Sistem Ömür Devri Yönetimi Rehberi (Ana Çerçeve) 
|TSSÖDYP-01
|-
|Sistem Ömür Devri Yönetimi Süreçleri Rehberi   
|TSSÖDYP-02
|-
|Ürün Destek Stratejileri ve Modelleri Rehberi 
|TSSÖDYP-03
|-
|Entegre Lojistik Destek (ELD) Rehberi 
|TSSÖDYP-04
|-
|Entegre Lojistik Destek (ELD) İsterleri Hazırlama Rehberi  
| TSSÖDYP-05
|-
|Lojistik Destek Analizleri ve Kayıtları Rehberi  
|TSSÖDYP-06
|-
|Tedarik Zinciri Yönetimi Rehberi
|TSSÖDYP-07
|-
|Sistem Ömür Devri Yönetiminde Demodelik Yönetimi Rehberi 
|TSSÖDYP-08
|-
|Kullanım ve Destek İhtiyaçları Çerçevesinde Yerlileştirme/

Millîleştirme Rehberi
|TSSÖDYP-09
|-
|Kullanım ve Destek Safhaları Kalite Yönetimi Rehberi 
|TSSÖDYP-10
|-
|Sistem Ömür Devri Yönetiminde Konfigürasyon Yönetimi Rehberi
|TSSÖDYP-11
|-
|Teknik Yayın Hazırlama Rehberi  
|TSSÖDYP-12
|-
|Eğitim ve Eğitim İhtiyaçları Rehberi
|TSSÖDYP-13
|-
|Sistem Ömür Devri Yönetimi Terminolojisi
|TSSÖDYP-14
|-
|Kodlandırma ve Sınıflandırma Bilgi Kitapçığı
|TSSÖDYP-15
|-
|ASD/AIA S-Serisi ELD Spesifikasyonları Seti Tanıtım Kitapçığı
|TSSÖDYP-16
|}

== 1.7. TANIMLAR VE KISALTMALAR ==

=== 1.7.1. TANIMLAR ===
'''Tablo 2 Tanımlar Tablosu'''
{| class="wikitable"
|'''Terim'''
|'''Tanım'''
|'''Diğer Kullanım'''
|-
|Emniyet

Safety
|Ölüm, yaralanma,  mesleki hastalık, ekipman veya mülkte hasar veya kayıp veya çevreye verilen  hasara neden olabilecek koşullardan bağımsız olmak. 
|
|-
|Güvenilirlik

Reliability
|Belirli bir zaman  periyodunda, istenen çevresel ve coğrafi şartlar altında ve belirlenen  kullanım profillerinde sistemin gereken fonksiyonunu hata yapmadan  yapabilme/başarabilme olasılığıdır.
|
|-
|İdame Edilebilirlik

Maintainability
|Belirlenmiş prosedür ve  kaynaklar kullanılarak, tanımlı bakım onarım seviyelerinde belirlenmiş  yeteneğe sahip personel tarafından bakım faaliyeti gerçekleştirildiğinde, odak  sistemin öngörülen performans seviyesinde tutulabilmesi veya öngörülen  performans seviyesinde tekrar çalışır duruma geri getirilebilmesi  kabiliyetinin ölçüsüdür.
|
|-
|Kullanıcı

User
|Harp araç, silah ve  malzemelerini kullanacak ve/veya idamesini sağlayacak birimleri ifade eder.
|İhtiyaç Makamı/İdame Makamı
|-
|Kullanıma Hazır Olma

Availability 
|Sistemlerin istenilen  herhangi bir zamanda, istenilen performans ölçütlerini karşılayacak şekilde faal  durumda olma ihtimalidir.
|
|-
|LDA İş Tanımı Dokümanı

LSA Guidance Conference Document
|LDA İş Tanımlama  Toplantısı’nda değerlendirilen bulguların, analizlerin, yürütülecek  faaliyetlerin ve sonuç kararlarının mutabakat altına alındığı dokümandır.
|LDA Kılavuz Konferansı Belgesi
|-
|LDA İş Tanımı Toplantısı 

LSA Guidance Conference
|Desteklenebilirlik  açısından ürün tasarımını etkilemeyi amaçlayan, tasarımın erken aşamalarında  başlayıp, ömür devri boyunca devam eden; güvenilirliği, kullanıma hazır  olmayı, maliyeti ve zaman etkinliğini ön plana çıkaran bir dizi analiz  sürecinin performansına ilişkin bağlayıcı kararların alınmasını sağlayan,  kullanıcı/tedarik makamı ve yüklenici tarafından yönetim kadrosu ve  uzmanların katılımıyla gerçekleştirilen toplantılardır.
|LDA Kılavuz Konferansı
|-
|Müşteri

Customer
|Süreç çıktılarının teslim  edildiği, yani çıktıların kullanıcısı olan taraflardır. İç müşteriler,  organizasyon içinde yer alan ve sürecin bir sonraki adımı için çıktıları  kullanan fonksiyon ya da fonksiyonlardır. Dış müşteriler ise, organizasyon dışında  yer alan kişi ya da kuruluşlardır.
|Alıcı, İhtiyaç Makamı, Kullanıcı, Tedarik Makamı,  İdame Makamı
|-
|Teklife Çağrı Dokümanı

Request for Proposal 
|Tedarik edilecek ürün  ve hizmet alımları ile yapım işlerinin teknik şartnamesi, ihale konusu işin  tanımı, hangi şartlarda yapılacağı, sözleşme görüşmelerine esas mali, idari,  hukuki hususları ve teklif verme şekli gibi konuları kapsayan  dokümandır. 
|
|-
|Ürün

Product
|Yüklenici  tarafından, sözleşme kapsamında tedarik makamına teslim edilecek ve her bir  sözleşme değişikliği için belirtilen kalemler ve bunlara ilişkin tüm sistem,  donanım, yazılım ve dokümanlardır. Bu kalemler kara, deniz, hava araçları,  platformlar, silah, sistem, yazılım ve bunlara ilişkin tüm destek donanım ve  yazılımlarını içerebilir.
|
|-
|Ürün Kırılımı

Product Breakdown 
|En az değiştirilebilir  kalemlere kadar inen ürünün ürün ağacının lojistik açıdan incelenmiş  fizikselkırılımıdır.
|
|-
|Yönetişim

Governance
|Resmî ve özel kuruluşlarda idari, ekonomik, politik  otoritenin ortak kullanımı, karşılıklı  etkilerin birlikte belirlenerek yönetimi.
|
|-
|Yüklenici

Contractor
|Bir sözleşme ile  hizmet veya ürünü tasarlayan/geliştiren/üreten veya teslim/ifa eden firma,  kurum ve kuruluşlar.
|
|}
=== 1.7.2. KISALTMALAR ===
'''Tablo 3 Kısaltmalar Tablosu'''
{| class="wikitable"
|'''Kısaltma'''
|'''Açık Yazımı'''
|'''Diğer Kullanım'''
|-
|<nowiki>-AIA</nowiki>
|Aerospace Industry Association of America 
|
|-
|<nowiki>-ASD</nowiki>
|Aerospace andDefenceIndustries Association of Europe
|
|-
|AAK

IUA
|Analiz Altındaki Kalem

ItemUnder Analysis
|
|-
|AAS

SUA 
|Analiz AltındakiSistem

SystemUnder Analysis
|
|-
|AKL

CIL
|Aday Kalem Listesi

Candidate Item List 
|
|-
|BİM

MRI
|Bakım İlgili Malzeme

Maintenance  Relevant Item 
|
|-
|BÖM

MSI
|Bakım Önemli Malzeme

Maintenance Significant Item 
|
|-
|DSB

TBD
|Daha Sonra Belirlenecek

To Be Determined 
|
|-
|ELD

ILS
|Entegre Lojistik Destek 

Integrated Logistics Support
|
|-
|GGT

RC
|Gözden Geçirme Toplantısı

Review Conference
|GGK

Gözden Geçirme Konferansı KK

Kılavuz Konferansı
|-
|GMB

RCM
|Güvenilirlik Merkezli Bakım

Reliability Centered Maintenance
|
|-
|HDB

LRU
|Hatta Değiştirilebilir Birim

Line Replaceable Unit
|
|-
|HTEA

FMEA
|Hata Türleri Etkileri Analizi

Failure Modes and Effects Analysis 
|
|-
|HTEKA

FMECA
|Hata Türleri Etkileri ve Kritiklik Analizi

Failure Modes, Effects and Criticality Analysis 
|
|-
|KKK
|Konfigürasyon Kontrol Kurulu 
|
|-
|LDA

LSA
|Lojistik Destek Analizi

Logistic Support Anaylsis
|
|-
|LDAK

LSAR
|Lojistik Destek  Analizi Kayıtları 

Logistic Support  Analysis Records
|
|-
|LDAP

LSAP
|Lojistik Destek Analizi Planı

Logistics Support Analysis Plan 
|
|-
|LDAİTT
|Lojistik Destek Analizi İş Tanımlama Toplantısı
|
|-
|BGA

MTA
|Bakım Görev Analizi

Maintenance Task Analysis
|
|-
|NATO

NATO
|North Atlantic Treaty Organization
|
|-
|NSN

NSN
|NATO Stok Numarası

NATO Stock Number
|
|-
|ODS

MDT
|Ortalama Duruş Süresi

Mean Downtime
|
|-
|OOS

MTTR 
|Ortalama Onarım Süresi

Mean Time to Repair  
|
|-
|OSA

LORA
|Onarım Seviyesi Analizi

Level of Repair Analysis 
|
|-
|ÖDM

LCC
|Ömür Devri Maliyeti

Life Cycle Cost
|
|-
|PEDU

PHST 
|Paketleme Elleçleme Depolama Ulaştırma

Packaging Handling Storage Transportation 
|
|-
|RAHAT

COTS
|Rafta Hazır Ticari Ürün 

Commercially off the Shelf Item
|Raf Ürünü
|-
|TÇD

RFP
|Teklife Çağrı Dosyası

Request for Proposal 
|
|-
|D&TE

S&TE 
|Destek ve Test Ekipmanı

Support and Test Equipment 
|
|}

== 1.8. TABLOLAR VE ŞEKİLLER ==

=== 1.8.1. TABLOLAR ===
Tablo 1 Değişiklik İzleme Tablosu

Tablo 2 Tanımlar Tablosu

Tablo 3 Kısaltmalar Tablosu.

Tablo 4 Örnek Soru Seti

Tablo 5 Kalem Türüne Bağlı Olarak İdame Edilebilirlik Analiz Derinliği 

Tablo 6 OSA’nın Farklı Derinliklerinin Sınıflandırılması 

Tablo 7 Yorumlama sürecinin zaman takvimi ile açıklanması 

Tablo 8 Durum kodu örnekleri 

Tablo 9 LDA Tarafından Belirlenen Farklı Yedek Parça Türleri Listesi 

Tablo 10 Analiz Faaliyetleri Seçim Kriterleri 

Tablo 11 Analiz Faaliyetleri Öneri Matrisi 

Tablo 12 Ömür devri safhalarındaki aktivitelerin özeti 

Tablo 13 Olayların Sebep Tiplerine ilişkin Örnekler

Tablo 14 Olayların meydana gelme olasılıkları 

Tablo 15 Teknoloji Seviyeleri 

Tablo 16 Teknoloji hassasiyetinin değerlendirilmesi 

Tablo 17 Teknoloji-Hassasiyet Değerlendirmesi 

Tablo 18 Onarım Seviyesi Analizi Süreç Adımları 

Tablo 19 Bakım Seviyeleri ve Tanımlı Görevlere İlişkin Örnekler 

Tablo 20 Görev Gereksinimleri Örneği 

Tablo 21 Görev kaynaklarına örnekler

Tablo 22 Montaj Prosedürü için Gerekli Görev Kaynakları Örneği 

Tablo 23 Elektronik Komple için montaj prosedürü-görev kaynakları özeti 

Tablo 24 Farklı Proje Safhalarında Yazılım Destek Analizi 

Tablo 25 Uyumluluk Matrisi 

=== 1.8.2.   ŞEKİLLER ===
Şekil 1 Entegre Lojistik Destek İşlevsel Elemanları (S3000L’den uyarlanmıştır) 

Şekil 2 Tedarik Maliyetlerine Karşı Kullanım ve Destek Maliyetleri 

Şekil 3 ÖDM ve LDA Arasındaki Etkileşim

Şekil 4 Temel LDA Süreci 

Şekil 5 LDA adayı belirlenmesinde kullanılabilecek örnek akış diyagramı (Yapısal Olmayan Malzeme için) (S3000L) 

Şekil 6 LDA adayı belirlenmesinde kullanılabilecek örnek akış diyagramı (Yapısal Malzeme için) 

Şekil 7 Müşteri ile yüklenici arasındaki veri alışverişi süreci (örnek) 

Şekil 8 Kullanıma Hazır Olma Kırılımı 

Şekil 9 Ergonomi/Simülasyon Yazılımlarından Örnek Görüntü

Şekil 10 Kullanım safhası LDA süreci 

Şekil 11 Kullanım ve destek safhası* bakım gözden geçirme akışı 

Şekil 12 Modifikasyon ve değişiklik uygulaması için kullanım safhası LDA – 1

Şekil 13 Kullanım dönemi malzeme yönetimi 

Şekil 14 Lojistik Destek Analizleri ile Teknik Dokümantasyon Arasındaki İlişki 

Şekil 15 Lojistik Destek Analizleri ile Malzeme Desteği Arasındaki İlişki 

Şekil 16 LDA ve Test Ekipmanı Arasındaki İlişki 

Şekil 17 LDA ve Eğitim Arasındaki İlişki 

Şekil 18 Ömür devri safhalarına göre analiz akış süreci 

Şekil 19 GMB – BGA Arayüzü

Şekil 20 Bakım Görevlerinin Belirlenmesi

Şekil 21 Görev Yapılarının Oluşturulması  

= 2. LOJİSTİK DESTEK ANALİZLERİNE GİRİŞ =

== 2.1. LOJİSTİK DESTEK ANALİZLERİ NEDİR? ==
Savunma ve güvenlik sistemlerinin (ürünün) temel görevi, savunma ve güvenlik ihtiyacını belirlenen kullanım konsepti ve görev profilleri çerçevesinde istenilen performans seviyesinde karşılamaktır. Ürünün kendisine tanımlanan fonksiyonları “kesintiye uğramaksızın” yerine getirebilmesi; destek unsurlarının sağlanması ve ilgili prosedürlerin yürütülmesi ile mümkündür.

Bu kapsamda; harekât ihtiyaçlarının zamanında ve verimli şekilde karşılanması ve sahip olunan kaynakların maliyet etkin kullanımı esastır. Lojistik Destek faaliyetleri söz konusu ürünün istenilen performans seviyesinde faaliyet gösterebilmesi için ihtiyaç duyulan kaynakların sağlanması ve idamesi ile ilgili idari ve teknik süreçleri kapsar.

Lojistik Destek Analizi (LDA); lojistik destek faaliyetlerinin maliyet etkin olarak yürütülmesinde yol gösterici en önemli faaliyettir. Tüm lojistik destek faaliyetlerinin teknik disiplin içinde maliyet etkin olarak planlanması, koordine edilmesi ve yönetilmesi için LDA rehberliğinde;

* Ürün ve destek unsurları güvenilirlik, kullanıma hazır olma, idame edilebilirlik,  desteklenebilirlik, test edilebilirlik ve uygun Ömür Devri Maliyeti (ÖDM) ile tasarlanır,
* Kullanım ve Destek Safhaları boyunca ürünün istenilen performans seviyesinde kullanılabilmesi için ihtiyaç duyulan kaynaklar tanımlanır,
* ELD elemanlarına ilişkin esas bilgiler oluşturulur.


Lojistik Destek Analizleri; sistem ömür devri boyunca desteklenebilirlikle ilişkili olası darboğazların öngörülmesi, bahse konu darboğazların giderilmesine yönelik önleyici planların oluşturulması ve oluşturulan planların iyileştirilmesi, geliştirilmesi ve uygulamaya aktarılması amacıyla yinelemeli olarak yürütülür.

== 2.2. TARİHÇESİ VE GELİŞİMİ ==
Lojistik Destek Analizlerinin gelişimi, sayısal bilgi işlem platformları ve kompleks sistemlerin yaygınlaştığı, teknoloji yönetiminin teknoloji savaşlarına dönüştüğü 1970’li yıllardan itibaren yaklaşık 50 yıllık bir dönem içinde gerçekleşmiştir.

ELD uygulamalarının 1965 yılında Amerika’da ortaya çıkması ile birlikte, bir sistemin desteğinin de en az performans karakteristikleri kadar önemli olduğu kabul edilmiştir.

İhtiyaç Makamlarının ELD’nin uygulanmasındaki temel hedefleri; lojistik destek konularının sistemin tasarımına etki etmesini sağlamak, ürünün kullanıma/göreve hazır olma hedeflerine ilişkin ve bu hedeflere ulaşılmasını sağlayan destek gereksinimlerini belirlemek ve geliştirmek, gerekli desteği minimum maliyetle temin etmek ve ürün envantere alındıktan sonra lojistik desteğini sağlamaktır.

1980’lerin başında, LDA’ya yönelik bir süreç geliştirilerek MIL-STD-13881A yayımlanmıştır. Bu süreç en iyi ticari uygulamaları esas alarak geliştirilirken, desteklenebilir bir tasarım elde etme hedefine yönelik bütün faaliyetleri sistem mühendisliği süreçlerine entegre edecek bir metodoloji tanımlamış ve aynı zamanda fiziksel destek çözümünün geliştirilmesine yönelik basit fakat etkin yöntemler sunmuştur. Başlangıçta ABD Silahlı Kuvvetlerinin ana sistem tedarik mevzuatlarında yer verilen LDA prensipleri, halen kullanılmakta olan diğer standartların da yürürlüğe girmesiyle birlikte tedarik ve sistem mühendisliği bilimlerindeki merkez olma rolünü üstlenmiştir.

Etkin uygulamalarının görülmeye başlanması ile birlikte, Birleşik Krallık Savunma Bakanlığı tarafından da LDA süreci “Defence Standard 00-60”a entegre edilerek yayımlanmıştır. Diğer birçok ülkenin de süreci kendi sistemlerine adapte ederek kullanmaya başlamasıyla, desteklenebilirlik gereksinimlerinin sistem tasarımına dahil edilmesi sürecinde LDA evrensel bir araç haline gelmiştir.

Günümüzde ülkelerin, resmi ve özel kurumların genel prensipleri örtüşmekle birlikte uygulamada küçük farklılıklar içeren standart ve rehber dokümanları ile uygulama desteği sağlayan birçok ticari yazılım ve girişim sayesinde yeterli çeşitlilik ve derinlik oluşmuş bulunmaktadır.

== 2.3.   ENTEGRE LOJİSTİK DESTEK SÜRECİ İÇİNDE LOJİSTİK DESTEK ANALİZLERİNİN YERİ VE ÖNEMİ ==
Bir ürünün ömür devri boyunca desteklenebilmesi için kullanılacak teknik bilgi ve destek çözümünü geliştirmeye dair sorumluluk ELD sürecinin kapsamındadır. ELD elemanları aşağıda belirtildiği gibidir:

* Bakım
* İkmal Desteği
* İşgücü ve Personel
* Destek ve Test Ekipmanları
* Tasarıma Etki/Tasarım Etkileşimi
* Teknik Veri ve Dokümantasyon
* Eğitim ve Eğitim Desteği
* Tesisler ve Altyapı
* Paketleme, Elleçleme, Depolama, Ulaştırma (PEDU)
* Bilgisayar Kaynakları
* İdame Mühendisliği
* Ürün Destek Yönetimi

LDA, bir ELD elemanı değildir ancak ELD’nin ayrılmaz ve temel bir parçasıdır ([https://tssodypwiki.ssb.gov.tr/index.php/Entegre_Lojistik_Destek_(ELD)_Rehberi Bkz. TSSÖDYP-04 Entegre Lojistik Destek Rehberi]). 

LDA programı, ELD planlama ve kaynakların belirlenmesi için kullanılacak teknik verilerin temel kaynağını oluşturur. Lojistik Destek Analizleri ile destek elemanı gereksinimleri tanımlanarak tasarıma etki arayüzü sağlanmış olur. Ayrıca, analiz faaliyetleri ile maliyet etkin bakım çözümü, bakım seviyeleri, bakım görevleri, bakım için gerekli destek kaynakları ile yedek parça planlaması gibi hususlar belirlenerek ELD elemanlarına girdi sağlanır. Lojistik destek analizlerinin sonuçları ve destek kaynak verileri, LDA veritabanında kayıt altına alınarak bütün program elemanlarına, tasarım alternatiflerinin desteklenebilirliğini ve hedeflerini değerlendirmede kullanılacak ortak bir veri kaynağına erişimi sağlar.

ELD elemanlarının herbirinin kendi alanlarında kaynak kullanımına ilişkin verileri toplama, analiz etme ve saklama gibi işlemleri ayrı ayrı yürütmeleri, üretilen bilgiler arasında tutarsızlığa veya devamsızlığa sebep olur. LDA süreci ile birlikte tek bir veri tabanının kullanılması her bir ELD elemanının, diğerleri ile aynı bilgiyi kullanması ve bir elemanın ürettiği verilerin diğerlerinin kullanımına da sunulmasını sağlar.
[[Dosya:Şekil1 ELD Elemanları ile LDA Arasındaki İlişki.jpg|alt=|sol|küçükresim|600x600pik|Şekil 1 ELD Elemanları ile LDA Arasındaki İlişki]]











































== 2.4. LDA VE ÖMÜR DEVRİ MALİYETLERİ ==
Sistemin ömür devri boyunca gerçekleşen toplam maliyetlerini tanımlamak için farklı terimler kullanılır. Bunlardan ÖDM sistemin geliştirme, üretim (veya satın alma), kullanım, destek ve elden çıkarılmasına ilişkin bütün doğrudan ve dolaylı maliyetleri kapsar.

Ürünün kullanım ve destek maliyeti genellikle tedarik maliyetinin çok üzerindedir. Bu nedenle belirli bir ürünün tedarik edilmesine ilişkin karar verme süreci sadece ürünün tedarik maliyeti değil, ömür devri boyunca beklenen kullanım ve destek maliyetleri ile envanterden çıkarma maliyetlerinden de etkilenmelidir. Tedarik maliyeti ile kullanım ve destek maliyetlerinin bütünü nisbi büyüklükleri figüratif olarak vurgulanmak üzere Şekil 2’de gösterilmektedir.
[[Dosya:Şekil 2 Tedarik Maliyetlerine Karşı Kullanım ve Destek Maliyetleri .jpg|sol|küçükresim|500x500pik|Şekil 2 Tedarik Maliyetlerine Karşı Kullanım ve Destek Maliyetleri ]]                  
 
 


























ÖDM analizleri, alternatif sistem çözümlerini mukayese etmek için kullanılan teknik bir süreçtir. Bu analizlerin temel amacı, alternatifler arasındaki farkları vurgulamaktır. Bir geliştirme programında ÖDM analizleri, tasarım çözümü daha kesin olarak bilinmeden gerçekleştirilir ve değerlendirilir.

ÖDM analiz faaliyetleri, programın erken safhalarında, LDA faaliyetlerinden önce başlatılır. Dolayısıyla, ÖDM sonuçları, erken dönem LDA faaliyetleri kapsamında hazırlıklar yapılırken mevcut durumdadır. Bu sonuçlar, LDA program planının ve çerçevesinin oluşturulması için bir kriter teşkil edebileceği gibi, LDA aday kalemlerinin seçilmesi ve her bir aday için gerçekleştirilecek analizlerin belirlenmesini de destekler.

ÖDM analizleri tasarıma etki, ürün konfigürasyonunda yer alacak kalemlerin belirlenmesi ve Onarım Seviyesi Analizi (OSA) gibi faaliyetler esnasında karar verme kriteri olarak ve LDA gereksinimlerinin gerçekleştirilmesinin maliyet etkisini tahmin etmek için de kullanılabilir. Dolayısıyla ÖDM analiz sonuçlarının, LDA sürecinde aşağıda yer alan konulara ilişkin bir karar kriteri olarak kullanılması mümkündür:

* LDA aday kalemlerinin belirlenmesi
* Her bir aday kalem için gerçekleştirilecek analizlerin belirlenmesi
* Tasarım üzerinde etki
* Konfigürasyon Birimlerinin/Kalemlerinin Değerlendirilmesi
* Onarım Seviyesi Analizi (OSA)

LDA süreci kapsamında Hata Türleri ve Etkileri Analizi (HTEA), Bakım görev Analizi (BGA) gibi farklı analiz faaliyetleri sonucunda birçok veri üretilir. Süreç boyunca kayıt altına alınan gereksinimler ve üretilen veriler daha sonra ÖDM modelini güncellemek için de girdi oluştururlar. Dolayısıyla, LDA veri tabanı ile ÖDM analizleri arasında tutarlılığı sağlamak son derece önemlidir.  ÖDM ve LDA arasındaki etkileşim Şekil 3’te gösterilmiştir.
[[Dosya:Şekil3 ÖDM ve LDA Arasındaki Etkileşim.jpg|alt=|sol|küçükresim|760x760pik|Şekil 3 ÖDM ve LDA Arasındaki Etkileşim]]







































== 2.5. LDA SÜRECİNİN ÇIKTILARI VE PROJELERDE LDA FAALİYETLERİNİN ETKİSİ ==
Bir tedarik programını etkileyen dört temel faktör; maliyet, takvim, performans ve desteklenebilirliktir. LDA süreci, bir sistem/ekipman ile ilişkili olarak desteklenebilirlik ve maliyet faktörlerine doğrudan girdi sağlayarak tedarik ile ilişkili karar verme sürecine önemli katkıda bulunur.

Programlar arasında farklılık göstermekle birlikte LDA sürecinin çıktısı olarak sistem seviyesinde tedarik kararlarını etkileyen temel hususlar şunlardır:

* Maliyet: Bütün savunma tedarik programları yüksek kalite ve kabiliyete sahip, bütçelenebilir sistemler temin etmeyi hedefler. Bir ürünün bütçeye uygunluğunun değerlendirilebilmesi için destek yatırımları ve kullanım ve destek maliyetlerinin de diğer tedarik maliyet kalemleri ile birlikte dikkate alınması gerekir. Ömür devri maliyet tahminleri, farklı sistem alternatifleri için yatırım maliyetleri ile tekrarlanan maliyetleri karşılaştırır. Kullanılan maliyet analizi yöntemi, sistem seviyesi güvenilirlik, idame edilebilirlik vb. karakteristikleri, kullanım oranları ve operasyon senaryoları varsayımlarına dayanan belli göreve hazır olma seviyelerine ulaşmak için gerekli olan destek kaynaklarını dikkate almalıdır.
* Bütçelenebilirlik: ÖDM’ye dair bütün ana kalemler dikkate alınmalıdır. Bu çalışmalarda temel hedef, kullanıma hazır olma gibi ana kısıtları dikkate alarak maliyetleri en aza indirgemektir. Ürünün tedarik programı sonrasında, kullanım ömrü boyunca sürdürülecek değerlendirmeler ömür devrinin etkin olarak yönetimine önemli katkı sağlar. Bu değerlendirmeler, sadece maliyetlerin zaman içinde değişmesi nedeniyle değil aynı zamanda “bütçeye uygunluk” değerlendirmesinin de değişen ekonomik koşullara bağlı olarak değişime tabi olması nedeniyle gerekli olacaktır. Yıllara sari olarak sistemin kullanım ve desteği için karşılaşılacak mali boyut bütçelenebilir olmalıdır. Dolayısıyla, sistemin ömür devri boyunca sahip olma maliyetini azaltacak fırsatları araştırmak önemlidir.
* İş gücü ve personel kısıtları: Yeni sistem/ekipmanlar ile birlikte ortaya çıkacak iş gücü ve personel beceri ihtiyaçları, performans, ağırlık vb. diğer tasarım parametreleri ile birlikte yeni sistem/ekipman konseptinin ilk ortaya çıkışıyla birlikte erken safhalarda yönetilmelidir.
* Göreve Hazır Olma: Ürün desteği ile ilgili tasarım parametreleri (örn. güvenilirlik, idame edilebilirlik), ürün destek kaynakları (yedek parça, iş gücü vb.) ve ikmal sistemi parametreleri sistemin kullanıma hazır olma hedefleri ile ilişkilendirilmelidir. Bu tür hedefler, sistemden sisteme, barış zamanı ve savaş zamanı durumlarına göre değişkenlik gösterir. Sistemin göreve hazır olması, sistemin kullanım profilleri içinde yer alan görevler için gerekli olan tüm unsurların hazır bulunması demektir ve sistemin/ekipmanın en erken safhalarından itibaren yönetilmesidir.

== 2.6. LDA STANDARTLARI/SPESİFİKASYONLARI ==

* MIL-STD-1388-1A (iptal): LDA konusunda en bilinen ve yaygın olarak kullanılan standart “MIL-STD-1388-1A Logistic Support Analysis” isimli standarttır. Amerikan Savunma Bakanlığı tarafından ilk olarak 1983 tarihinde yayımlanan bu standart, mantıksal ve yinelemeli bir kurgu ile gerçekleştirildiğinde LDA sürecini oluşturan genel gereksinimler ve görev tanımlarından oluşmaktadır. MIL-STD 1388-1A, 1997 yılında iptal edilmiş olup yerini “MIL-HDBK-502 Tedarik Lojistiği” dokümanı almıştır.
* MIL-STD-1388-2B (iptal): 1388-1A’ya göre gerçekleştirilecek analizlere dair veri tanımlarının ilişkisel tablo yapısına dayandırıldığı veri tabanı standardıdır. 1996 yılında iptal edilmiştir.
* MIL-HDBK-502A: Amerikan Savunma Bakanlığı tarafından 1997 tarihinde “Tedarik Lojistiği” ismi ile yayımlanan bu el kitabının “A revizyonu” 2013 yılında “Ürün Destek Analizleri” ismi ile tekrar yayımlanmıştır (Amerika’da önceki yıllarda lojistik destek analizleri olarak adlandırılan analizler günümüzde ürün destek analizleri olarak isimlendirilmektedir). Halen yürürlükte olan bu doküman, sistem ve ekipmanların ömür devri boyunca ürün destek analizlerinin gerçekleştirilmesine yönelik bir çerçeve tanımlamaktadır. Bütün olarak ürün destek analizleri sürecini ve ilişkili faaliyetleri, Savunma Bakanlığı desteklenebilirlik hedeflerini karşılayabilmek için söz konusu faaliyetlerin seçim ve uyarlama yöntemlerini ve LDA teslimatlarına yönelik olarak sözleşmelerde yer alabilecek örnek ifadeleri içermektedir.
* MIL-PRF 49506 (iptal): Lojistik Yönetim Bilgisi isimli bu spesifikasyon tedarik lojistiği yönetim işlevine, yüklenicilerden destek ve destek ilişkili mühendislik ve lojistik bilgilerinin temin edilmesine yönelik olarak 1996 yılında yayımlanmış ancak 2005 yılında iptal edilmiştir.
* UK-DEF-STAN-00-60 Part 1 (iptal): İngiltere Savunma Bakanlığı tarafından 1994 yılında yayımlanan UK-DEF-STAN-00-60 Part 1 “Logistic Support Analysis (LSA) and Logistic Support Analysis Record (LSAR)” ise MIL-STD-1388’in bir varyantı olarak nitelendirilebilir. 2010 yılında iptal edilmiştir. Günümüzde UK-DEF-STAN-00-600 kullanılmaktadır.
* GEIA 0007: “Lojistik Ürün Bilgisi” olarak isimlendirilen bu standartta veri tanımları 1388-2B gibi tablo yapısına dayalı olmakla birlikte, veri değişimi XML teknolojisi üzerine inşa edilmiştir. MIL-STD-1388-2B’nin yerini almıştır.
* S3000L: Hazırlık çalışmalarına Aerospace and Defence Industries Association of Europe (ASD) tarafından 2005 yılında başlanılan S3000L’nin 1.0 versiyonu ASD ve Aerospace Industry Association of America (AIA) arasında Haziran 2010 tarihinde imzalanan mutabakat zaptı ile birlikte yayımlanmış, Temmuz 2014 tarihinde 1.1 versiyonu ile güncellenmiştir. S3000L genel olarak MIL-STD-1388-1A, MIL-HDBK-502, DEF-STAN-00-60 ve ISO 10303-239 PLCS içerisinde tanımlanan aktivite modeline dayandırılmıştır. 
[[Dosya:LDA Doküman Gelişimi.png|alt=LDA Doküman Gelişimi|sol|küçükresim|800x800pik|LDA Doküman Gelişimi]]


































= 3. DESTEKLENEBİLİRLİK VE DESTEKLENEBİLİRLİK İLİŞKİLİ TASARIM FAKTÖRLERİ =

== 3.1. DESTEKLENEBİLİRLİK NEDİR? ==
Desteklenebilirlik, sistem tasarım özelliklerinin ve planlanan lojistik kaynakların sistemden beklenen operasyon ve göreve hazır olma gereklerini sistemin ömür devri boyunca uygun maliyette karşılayabilme derecesidir (yeteneğidir). Desteklenebilirlik sistem tasarımının ayrılmaz bir parçası olup ömür devrinin erken safhalarında değerlendirilmelidir.

Desteklenebilirliğin ömür devrinin erken safhalarında, sistem geliştirme safhasında dikkate alınması sistemi desteklemek için gereken kaynak miktarının azaltılmasında, sistemin gayri-faal kalma süresinin kısalmasında etkilidir. Bu da ÖDM’nin azaltılmasında ve sistemin faal tutulmasında önemli bir rol oynar. Desteklenebilirliğin ömür devrinin erken safhalarında değerlendirilmemesi tedarik ve destek maliyetlerinde artışa, teslimat sürelerinde uzamaya, gayrı faal kalma süresinde artışa ve kalite ile ilişkili problemlere yol açabilir ve bu da ÖDM’de ciddi artışlara neden olabilir.     

== 3.2. DESTEKLENEBİLİRLİK HEDEFLERİ ==
Desteklenebilirlik hedefleri, sistemden beklenen görev ve performans ölçütleri ile yakından ilişkilidir. Temel hedef sistemin kullanıma/göreve hazır olması ve kendisine verilen görevi başarı ile tamamlayabilmesidir.  Göreve hazır olma sistemin teknik özellikleri, destek altyapısı (ekipman, malzeme, iş gücü ve eğitimli personel vb.), destek idari yapısı, organizasyonu ve destek süreçleri ile ilişkilidir ve sistemin operasyonel uygunluğunun bir göstergesidir.

Bir diğer desteklenebilirlik hedefi ise sistemin maliyet etkin bir şekilde desteklenmesidir. Sistemin kendinden beklenen performans ve göreve hazır olma kriterlerini karşılayabilmesi için gerekli olan tasarım özelliklerinin, destek kaynaklarının ve destek altyapısının belirlenmesinde maliyet etkin bir yaklaşım izlenilmesini hedefler.

Desteklenebilirlik, destek sisteminin destek ihtiyaçlarına mümkün olan en kısa sürede yanıt verebilmesini hedefler. Destek sisteminin etkin olmasında destek idari yapısı ve organizasyonu, destek altyapısı (test, destek ve kalibrasyon ekipmanları, destek ve yedek malzemeleri, eğitimli personel ve iş gücü vb.), destek kaynaklarının boyut, ağırlık, paketleme, taşınma vb. özellikleri ve destek süreçleri gibi faktörler önemli rol oynar.

== 3.3. DESTEKLENEBİLİRLİK İLİŞKİLİ ÜRÜN PERFORMANS PARAMETRELERİ ==
Ürün desteklenebilirliği, sistemlerin, alt sistemlerin ve bileşenlerin kullanıma hazır olma ve operasyonel kabiliyetlerinin idamesi için gerekli destek bileşenlerinin oluşturulmasıdır. Bu kapsamda yapılan analizlerin temel amacı desteklenebilirlik parametrelerinin sistem tasarımlarına dahil edilmesinin sağlanmasıdır.

Desteklenebilirlik maliyet, takvim ve performans ile birlikte sistem tedarik kararlarını etkileyen ana faktörlerden biridir. Yüksek kalitede maliyet etkin çözümler üretilerek kullanıcı/tedarik makamı ihtiyaçları karşılanmalıdır. Erken safhalarda iyileştirme noktalarının belirlenebilmesi ve desteklenebilirlik bakış açısıyla tasarımlara etki edilebilmesi için LDA, konsept/geliştirme safhasının en başından itibaren projelerin ayrılmaz bir parçası olmalıdır. Bu anlamda, sistem/ekipman geliştirme süreçlerine etki eden desteklenebilirlik parametreleri; amaçlar, eşik değerler, nitel ve nicel kısıtlar ve sistem/ekipman geliştirme gerekleri olarak sınıflandırılabilir.

Desteklenebilirlik karakteristikleri projeler arasında farklı tanımlanabilmekle birlikte en yaygın olarak kullanılan performans parametreleri şunlardır:

* Arızalar Arası Ortalama Süre,
* Ortalama Onarım Süresi,
* Onarım Çevrim Süresi,
* Kullanıma Hazır Olma,
* ÖDM.

Aşağıdaki belirtilen unsurlarla desteklenebilirlik sürecine girdi olacak şekilde ara yüzler sağlanmalıdır:

* Güvenilirlik,
* İdame edilebilirlik,
* Kullanıma hazır olma,
* Desteklenebilirlik
* Test edilebilirlik,
* İnsan faktörleri mühendisliği,
* Entegre lojistik  destek elemanları,
* Konfigürasyon yönetimi,
* Envanterden çıkarma yönetimi,
* ÖDM.

= 4. LDA GENEL GEREKSİNİMLERİ =

== 4.1. LOJİSTİK DESTEK ANALİZ PROGRAMI ==
Sistem/ekipman tasarım ve geliştirme programlarında bir LDA Programı oluşturulması ve uygulanması faaliyetlerin sistematik ve zamanında gerçekleştirilmesi kapsamında önemlidir. LDA programı, aşağıdaki temel elemanlardan oluşur:

* Tasarımı desteklenebilirliği sağlayacak şekilde etkilemek ve uygun lojistik kaynaklarını tespit edebilmek için gerçekleştirilmesi gereken LDA faaliyetlerini belirleyen bir LDA planı
* LDA gereksinimlerinin zamanlamasını ortaya koyan bir takvim/planlama (LDA takvimi proje faz ihtiyaçlarına dayandırılmalı ve diğer proje gereksinimleri ile birbirini tamamlayıcı ve destekleyici şekilde ortaya konmalıdır)
* LDA faaliyetlerine ilişkin sorumlulukların tanımlanarak ilgili personele atanması
* Tasarım, güvenilirlik, emniyet ve ELD elemanları (disiplinleri) ile gerekli arayüzlerin kurulması ile girdi-çıktıların sağlanması

=== 4.1.1.   LDA STRATEJİSİ ===
Tedarik programının erken safhalarında genel bir LDA stratejisi geliştirilmelidir.

LDA stratejisinin belirlenmesi, bir LDA programı kapsamında gerçekleştirilmesi gereken ilk planlama faaliyeti olup maliyet açısından en etkin programı geliştirmede kritik öneme sahiptir. Bu faaliyet genel olarak LDA faaliyetlerini içeren herhangi bir talep dokümanı oluşturulmadan gerçekleştirilmelidir. LDA gereksinimlerini nihai hale getirmeden önce olası tasarım ve operasyonel yaklaşımların, desteklenebilirlik karakteristiklerinin ve mevcut verilerin analiz edilmesi, LDA programının tasarım üzerinde desteklenebilirlik etkisini azami ölçüde sunan temel alanlara odaklanmasını sağlar.

LDA stratejisi sistem/ekipman için önerilen desteklenebilirlik hedeflerinin kapsamını ve gerçekleştirilmesi istenen niceliksel analizleri, tedarik programı açısından en iyi maliyet faydasını sağlayacak şekilde belirlemelidir.

TÇD oluşturulurken tanımlanacak ön LDA stratejisi yüklenici tarafından yapılması “zorunlu/tavsiye edilen/isteğe bağlı” LDA faaliyetlerinin teklif aşamasında belirlenmesine ışık tutmalıdır. Yüklenicinin etkin bir LDA programı oluşturması ve yürütmesinde kullanılan LDA stratejisi, yüklenici seçim sürecinde etkili olmalıdır.

LDA stratejisi oluşturmanın ilk adımı hem müşteri hem de yüklenici tarafında herhangi bir çalışmaya başlamadan önce LDA’ya ilişkin ne yapılması gerektiğine dair bilinçli bir karar verme sürecinin yürütülmesini sağlamaktır.

LDA gereksinimleri, ürünü oluşturan sistemler, alt sistemler ve bileşenler için niceliksel, niteliksel ve test ile ilişkili LDA gereksinimlerinin sağlanmasını içerecek şekilde kapsamlı bir LDA programı oluşturmak amacıyla analiz edilir. Bu çalışmanın sonunda ortaya çıkan LDA programı LDA gereksinimlerini karşılayan uyarlanmış ve maliyet etkin bir program olmalıdır.

LDA programının yönetimi için LDA stratejisinin oluşturulmasına başlanması ön konsept safhasında ihtiyaç makamı/kullanıcı tarafından gerçekleştirilmesi gereken bir faaliyettir ve bu strateji TÇD yayımlanmadan önce ihtiyaç makamı/kullanıcı ve tedarik makamı tarafından netleştirilmelidir. Yüklenici adayları LDA stratejisine yönelik çalışmalarını konsept safhasında yaparlar.  Yüklenici, geliştirme ve üretim safhalarında LDA stratejisinin geliştirilmesi ve güncellenmesi sorumluluğunu üstlenir. Yüklenicinin bu sorumluluğu kullanım ve destek safhalarında da garanti dönemi ve sonrasına ilişkin düzenlemelere bağlı olarak devam eder. Ancak LDA stratejisi konusundaki genel sorumluluk sistemin ömür devri boyunca müşteri’dedir.

Strateji geliştirilirken verilmesi gereken önemli kararlardan biri hangi LDA görevlerinin/ faaliyetlerinin kim tarafından gerçekleştirileceğidir. İstenen LDA faaliyetlerinin gerçekleştirilmesinin yaklaşık olarak maliyeti, gerekli olduğunda kaynakların/bütçenin sağlanabilmesi amacıyla kamu tarafından hesaplanmalı/öngörülmelidir.

LDA Stratejisi geliştirme faaliyeti tek başına spesifik bir doküman üretilmesine yol açmaz. Bu faaliyetin sonuçları ELD Planı’nda (ELDP) yer alır.

Program ilerledikçe, takvim değişikliği, tasarım değişikliği, bütçe/maliyet değişikliği gibi önemli değişiklikler olduğunda, LDA stratejisi de güncellenmelidir. 

=== 4.1.2.   LDA AKTİVİTELERİ VE TEMEL LDA SÜRECİ ===
LDA süreci ile tasarıma etki faaliyetleri Şekil 4’de gösterilmektedir. Zamansal olarak akış projeye özgü olarak farklılık gösterebilir.
[[Dosya:Şekil6.4.jpg|alt=Şekil 4 Temel LDA Süreci|sol|küçükresim|632x632pik|Şekil 4 Temel LDA Süreci]]
















































Müşteri gereksinimleri ve operasyonel konsept benzer sistemler ve/veya tasarım ve geliştirme faaliyeti yapılmış olan sistem/alt sisteme ait veriler kullanılarak yapılan karşılaştırmalı  analiz sonuçları da tasarım ve geliştirme faaliyetlerinin girdisi olacaktır. Bu bilgiler ile bu bilgilere dayalı olarak yapılan varsayımlar kullanılarak taslak olarak aday kalem listesi hazırlanır. Tasarım ve geliştirme faaliyetleri kapsamında emniyet analizi, güvenilirlik analizi ve HTEKA çalışmaları yapılır ve sonuçlara göre tasarıma girdi sağlanır. Bu çalışmaların çıktıları da insan faktörleri analizi, hata ağacı analizi, yazılım destek analizi, özel olay ve hasar analizi, önleyici bakım analizi, test edilebilirlik analizi için kullanılır. Bu analizler sonunda aday kalem listesi nihai hale gelir. Bu liste üzerinden OSA ve BGA yapılır. Kullanım ve destek dönemi LDA faaliyetleri ihtiyaç olması durumuda (güncellemelerin/modifikasyonların olması durumunda, kullanım verilerine göre vb) gerekli görülen analizler tekrar yapılacak ve ELD elemanları üzerine etkisi tekrar değerlendirilecektir. Bu süreç kapsamında konfigürasyon yönetim faaliyetleri yürütülerek tüm bilgi/verilerin kayıt altına alınması, izlenebilirliğin kurulması sağlanacaktır.

=== 4.1.3. PROGRAM YÖNETİM İLKELERİ, ROLLER VE SORUMLULUKLAR ===
Lojistik destek analizleri kapsamında organizasyonlar içerisinde tanımlanmış ekipler, aşağıda sıralanan faaliyetlerden sorumlu olacaktır:

* Güvenilirlik, idame edilebilirlik, kullanıma hazır olma, desteklenebilirlik, test edilebilirlik, insan mühendisliği ve çevresel uygunluk gibi konularda girdi sağlayarak sistem ve destek sistemi tasarımına desteklenebilirlik karakteristiklerinin katılmasının sağlanması ve ilgili gereksinimlerin tanımlanması,
* Destek sistemini ve gerek duyulduğu takdirde eğitim sistemini geliştirmek ve lojistik destek kaynaklarının (ikmal destek, destek ekipmanı, teknik veri, tesisler, PEDU, iş gücü ve personel, eğitim ve eğitim desteği) planlaması, geliştirilmesi ve sunulması,
* Sistem mühendisliği ve tasarım mühendisliği faaliyetleri ile desteklenebilirlik mühendisliği faaliyetleri arayüzünün kurulması,
* Standardizasyonun, birbirinin yerine kullanılabilirliğin, birlikte çalışabilirliğin ve demodelik yönetiminin sağlanması.

Desteklenebilirlik sorumlusu/lideri ile ELD yöneticisi ve diğer işlevsel yönetim sorumluları arasındaki koordinasyonun ve ara yüzlerin oluşturulması ve sürdürülmesi LDA programının başarısı açısından büyük önem taşır. Ayrıca, etkin bir ELD/LDA program yönetimi açısından hem müşteri hem de yüklenici bünyesinde bir ELD/LDA organizasyonu oluşturulması gereklidir.

=== 4.1.4. LOJİSTİK DESTEK ANALİZİ PLANI (LDAP) ===
LDAP, proje süresince yürütülecek LDA faaliyetlerinin kimler tarafından, nasıl ve hangi esaslara dayanılarak yürütüleceğinin yer aldığı ve özellikle analizlerin icrasında rol alacak kişilerin sık sık başvuracağı bir el kitabı niteliğindedir. Bu plan, bir bakıma proje kapsamında hangi analizlerin yapılacağı ve nasıl yapılacağına dair bir yol haritası çizer. Aynı zamanda, programın farklı safhalarında ilerlemeyi ölçmek için de bir temel sunar.

LDAP, proje fazlarına göre uygun kapsam ve derinlikte aşağıdakilerle sınırlı olmamak kaydıyla gerekli bilgileri içermelidir:

* İlgili proje dokümanlarında tanımlanan sistemin lojistik gereksinimlerinin karşılanması için nasıl bir LDA programı yürütüleceği tanımlanmalıdır,
* LDA organizasyonu tanıtılır. Yöneticiler, analiz ekipleri, tasarım ekipleri, altyükleniciler, arayüzü sağlayacak sorumlular ile müşteri tarafındaki sorumlular belirtilir.
* Sistem ve alt sistemlerin tanımı yapılır, alt sistemlerin arayüz bilgileri belirtilir, görev profilleri tanımlanır.
* Sistemin karşı karşıya kalacağı çevresel koşullar, stres etkenleri (mekanik, termal, elektriksel, kimyasal, elektro-kimyasal, radyasyon) ve yüklemeler/zorlamalar belirlenir.
* Lojistik destek analizlerinin çerçevesini oluşturacak olan temel kural ve varsayımlar tanımlanır.
* Her bir LDA faaliyeti için referans alınacak standartlar, kullanılacak matematiksel modeller ve formüller tanımlanır, bu faaliyetlerin nasıl raporlanacağı belirtilir.
* Lojistik destek analizlerinin uygulama adımları kısaca anlatılarak çalışma ekipleri, tasarım ekipleri, alt yükleniciler ve müşterinin ilgili adımlardaki rolleri tanımlanır.
* LDA için aday kalemlerin seçim kriterleri belirtilir. Aday kalem listesi ve aday kalem listesinde yer alan sistem elemanlarına hangi analizlerin uygulanacağı listelenir (liste, analiz için önerilen ve önerilmeyen bütün bileşenleri ve seçilme/seçilmeme gerekçelerini içermelidir).

* LDA’ya tabi olacak bileşenlerin seçilmesinde kullanılacak kırılım yapısının (yazılım kalemleri dahil) belirlenir.
* Kullanılacak kırılım elemanlarının numaralandırma sistemi tanımlanır.
* Desteklenebilirlik ve desteklenebilirlik ilişkili tasarım gereksinimlerinin tasarımcılara ve ilgili personele hangi yöntemlerle aktarılacağı belirtilir.
* Desteklenebilirlik ve desteklenebilirlik ilişkili tasarım gereksinimlerinin altyüklenicilere kırılma yöntemleri ve uygulanacak kontroller belirtilir.
* LDA verilerinin konfigürasyon yönetim süreci tanımlanır.
* Projenin genel takvimi ile entegre olan LDA uygulama takvimi oluşturularak süreçlerin izlenebilirliği sağlanır.
* Kullanım ve destek safhaları kapsamında planlanan faaliyetler ve bu dönemde toplanması gereken verilerin içeriği tanımlanır.
* LDA faaliyetlerinin ELD ve tasarım süreçleri ile olan arayüzleri tanımlanır.
* Gözden geçirme faaliyetlerinin detayları belirlenir.

LDAP, konsept safhasında taslak olarak hazırlanmalı ve geliştirme safhasının başında detaylandırılarak güncellenmelidir. LDA faaliyetleri yapısı itibari ile yinelemeli ve dinamiktir. LDAP’ın projenin mevcut durumunu ve planlanan değişiklikleri yansıtacak şekilde gerektiğinde güncellenmesi gerekir.

LDA faaliyetlerinin planlanması ve koordinasyonu desteklenebilirlik mühendislerinin sorumluluğundadır. LDA sürecinin, sistem mühendisliği ve tasarım süreçlerinin entegre bir parçası olması sağlanmalıdır. Bu doğrultuda oluşturulacak bir LDAP, ömür devri boyunca gerekli ve/veya ihtiyaç duyulan safhalarda  LDA faaliyetlerinin gerçekleştirilebilmesi için gerekli stratejiyi ve proje gereksinimlerini karşılamak için gerekli olan yönetim, organizasyon ve prosedürleri tanımlar.

LDAP etkin bir LDA programı oluşturmak ve yürütmek için kullanılan temel araçtır.  Planda yer alacak birçok husus müşteri ve yüklenici arasında gerçekleştirilecek LDA İş Tanımlama Toplantısı’nda görüşülerek karara bağlanabilir. TÇD’lere cevaben hazırlanan LDAP, müşteri tarafından yüklenici adaylarının LDA yaklaşımlarını ve faaliyetleri yürütecek organizasyon yapılarını değerlendirmek amacıyla kullanılabilir.

LDAP formatı sözleşme kapsamında müşteri tarafından belirlenebilir. Eğer sözleşmede bir format belirlenmemişse yüklenici söz konusu ürün ve proje gereksinimlerine en uygun formatı kendisi belirleyecektir.

Örnek bir LDAP içeriği EK-I’da sunulmuştur.

=== 4.1.5. PROGRAM VE TASARIM GÖZDEN GEÇİRMELERİNE KATILIM ===
LDA çalışmaları; ön tasarım/kritik tasarım gibi tasarım gözden geçirme toplantıları, teknik bilgi toplantıları, üretime hazırlık gözden geçirme toplantısı gibi proje kapsamında gerçekleştirilen gözden geçirmelerin bir parçası olmalıdır.

Desteklenebilirlikle ilgili bütün hususlar ve mevcut durum bilgisi uygun ve zamanında çözümler elde edilebilmesini sağlamak ve takip edebilmek üzere gözden geçirme toplantıları sonuç dokümanlarında dokümante edilir. Diğer taraftan sistem/ekipman tasarım gözden geçirmelerine ilave olarak LDA’ya özel gözden geçirme toplantıları da ihtiyaç duyulması halinde planlanabilir. Bu toplantılarda tasarım ve program gözden geçirmelerinde adreslenen birtakım konular daha detaylı şekilde incelenebilir ve/veya LDA faaliyetlerinin ilerleme durumları gözden geçirilebilir. Proje gözden geçirme toplantılarına LDA faaliyetlerinin dahil edilmemesi ürünün geliştirmesi ve desteklenmesine ilişkin risklerin  artmasına sebep olacaktır. 

= 5. LOJİSTİK DESTEK ANALİZ SÜRECİ =
Yeni bir ürünün hizmete alınması veya mevcut sistemlerin modernizasyonu ile birlikte bütün lojistik gereksinimler de doğru zamanda sağlanmış olmalıdır. Bu amaçla ürünün tasarımı esnasında lojistik gereksinimlerin dikkate alınmasını sağlayacak bir süreç oluşturulması gereklidir. Söz konusu süreç kapsamında yüklenici ve müşteri uygun desteklenebilirlik seviyesine erişmek için gerçekleştirilmesi gereken faaliyetler üzerinde mutabakat sağlamalıdır. Lojistik hususların erken dönemde ele alınması hem operasyonel hem de ekonomik açıdan büyük önem taşır. Operasyonel konsepte uygun şekilde kullanılamayan ve idame edilemeyen bir ürün kullanıcı açısından kabul edilebilir olmayacaktır.
[[Dosya:TSSODYP06.LDASURECI.jpg|alt=|sol|küçükresim|758x758pik]]











































== 5.1. ÜRÜN KULLANIM VERİSİNİN TANIMLANMASI ==
Yeni bir ürünün desteklenebilirlik özelliklerinin belirlenebilmesi için ürünün planlanan kullanımına yönelik ilişkili bütün verilerin erişilebilir olması ve bu bilgilerin uygun bir şekilde Operasyonel Kullanım Konsepti (veya Operasyonel Konsept) dokümanında yer alması veya ilgili diğer dokümanlarda derlenmiş olarak belirtilmesi gerekir.

Projelerin erken safhalarında bazen ihtiyaç duyulan bilgiler tam olarak mevcut olmayabilir. Ancak kullanım senaryosunun konsept sahfasında tanımlanmış olması önemlidir. Bu durumda ürünün kullanımına ilişkin bilgiler yinelemeli adımlarla derlenmelidir. Kullanım senaryosundaki olası değişiklikler lojistik açıdan kritik önem arzetmekte olup, desteklenebilirlik mühendisleri tarafından dikkate alınarak analiz tekrarının gerekip gerekmediği değerlendirilmelidir.

Ürün kullanım verileri; genel kullanım bilgisi, operasyonel gereksinimler, müşteri gereksinimleri, saha incelemelerinden gelen bilgiler ile kalifikasyon ve sertifikasyon gereksinimleridir.

=== 5.1.1. ÜRÜN GENEL KULLANIM BİLGİSİ ===
Hizmete alınacak ürünün kullanımına yönelik tüm ön şartlar ve ürün tasarımı ile performans verilerinden kaynaklı stratejik hususlar dikkate alınarak genel bir destek stratejisini tanımlanmalı ve ELDP içerisinde dokümante edilmelidir. Söz konusu strateji, daha ileri lojistik destek analizlerin gerçekleştirilmesi ve operasyonel gereksinimlerin ve müşteri gereksinimlerinin oluşturulmasına esas temel kılavuzu oluşturmalıdır.

Operasyonel konsept ve müşteri gereksinimleri oluşturulmadan önce veya eşzamanlı olarak ürünün kullanımına yönelik cevaplanması önerilen bazı örnek sorular aşağıda sıralanmıştır (S3000L). Soruların cevaplanmasının temel amacı, mevcut olan en iyi bilgiyi kullanmak şeklinde belirlenmelidir.

* Ürün nasıl kullanılacaktır?  (Ürünün, kilit özellikleri ve gereksinimleri ile temel teknik veri ihtiyaçlarını da içerecek şekilde kısa bir tanımı)
* Yükleneci Lojistik Desteği istenecek midir? Eğer istenecekse, hangi bakım kedemelerinde? (Bu çok genel bir soru olup, aşağıda sıralanan bazı hususların detaylı incelenemesinin akabinde cevaplanması mümkün olacaktır.)
* Ürün nerede kullanılacak ve idame edilecektir?
* Ürün hangi çevresel koşullarda kullanılacak ve idame edilecektir?  (Örn. sabit, mobil, endüstriyel, tehlikeli, tehlikesiz)
* Ürünün karakteristiklerini etkileyecek (güvenilirlik, idame edilebilirlik, vb) çevresel koşullar nelerdir? Çevresel koşullar, ürünün onarım tarzını etkileyecek mi? 

* Ürün ne kadar süre ile kullanılacaktır? (Örneğin, eğer ürün kısa bir süre için envanterde kalacaksa bu durumda uzun ve maliyetli bir organik destek yapısı oluşturma süreci yerine yüklenici desteği tercih edilebilir.)
* Bakım konsepti nedir? Ürün desteği için kaç bakım kademesi planlamaktadır?
* Her bakım kademesi için tipik özellikler ve/veya faaliyetler neler olabilir?
* Yeni ürünün destek konseptine adapte edilebilecek sürmekte olan bakım kabiliyetleri var mı?
* Öngörülen kullanım mahallinde veya yakınında bulunan başka veya benzer ürünlere yönelik mevcut bakım kabiliyetlerinin yeni ürün için kullanılması mümkün ve etkin olabilecek midir?
* İhtiyaç Makamı/kullanıcı ürünün onarım faaliyetlerine dahil olmalı mı yoksa gerçekleştireceği basit düzeltici bakım ile mi sınırlı olmalıdır? İhtiyaç Makamı’nın sürece dahil olması kendisi tarafından sağlanabilecek yeteneklere bağlıdır. Ayrıca, idame makamlarının imkan ve kabiliyetleri de dikkate alınmalıdır.

* Kullanıcı açısından önleyici ve düzeltici bakım faaliyetleri için bakım süresi ve sıklığı konusunda kabul edilebilir rakamlar nelerdir?
* Önleyici bakımlar için kısıtlamalar söz konusu mudur? (örn. personel ve tesislerin mevcudiyetine ilişkin bazı özel ön şartlar nelerdir)?
* Geliştirilen yazılım ne kadar olgun ve ne kadarı müşteriye özgüdür? (Yazılımların tam olarak olgun bir seviyeye erişmesi uzun süreler alabilir. Lojistik destek yapısı kullanıcı tarafından talep edilecek potansiyel güncellemelerin yazılım bakımını da adreslemelidir).
* Kullanıcı tarafından gerçekleştirilecek herhangi bir yazılım/veri yükleme/kaldırma işlemi var mıdır? Ürünün yazılım/veri yükleme işleminden sonra düzgün şekilde çalıştığı nasıl güvence altına alınacaktır?
* Teknolojideki değişikliklerden kaynaklı olarak üründe beklenen yenileme veya iyileştirme/yükseltme ihtiyaçları nelerdir? (Bu soru, destek yapısının üründeki değişikliklere nasıl ayak uydurabileceği ve destek stratejisinin nasıl uyarlanacağına ilişkindir. Bu konuda öngörülen zorluklar Yüklenici Lojistik Desteği stratejisinin belirlenmesinde etken olabilir).

=== 5.1.2. OPERASYONEL GEREKSİNİMLER ===
Operasyonel gereksinimler hem niceliksel hem de niteliksel olarak tanımlanmalıdır. Donanım, kullanım ve desteklenebilirlik arasında ilişkileri tanımlayan, işletim mahali ve ürün kullanımına yönelik daha önce gerçekleştirilen analizler dikkate alınmalıdır. 

Desteklenebilirlik gereksinimleri doğrudan operasyonel gereksinimlerinden türetilirler. Her bir desteklenebilirlik gereksinimi bir operasyonel gereksinime dayandırılmalı, aralarındaki ilişki açıkça belirlenmeli ve sistem gereksinimleri kapsamında dokümante edilmelidir.

Operasyonel gereksinimler yazılırken anahtar performans göstergeleri de belirlenmelidir. Anahtar bir parametre olarak tanımlanmayan herhangi bir parametre, desteklenebilirlik karakteristiklerinin olumsuz etkilendiği durumlarda değiştirilmek için aday olacaktır. Operasyonel gereksinimler, yüklenicinin programın erken safhalarında “zorunlu olan özellikler” ile “olsa iyi olur” diye düşünülen özellikler arasında  karar vermesini gerektirir. Desteklenebilirlik mühendisleri için bu bilgi, maliyetten bağımsız olarak, neleri desteklemek zorunda oldukları ve neler için ödünleşim yapabileceklerini anlamak açısından kritik öneme sahiptir.

==== <big>5.1.2.1. GENEL KULLANIM SENARYOSU</big> ====

==== Genel kullanım senaryosunda, ürünün kullanımını, ürünün kullanımından doğan çevresel etkileri tanımlayan bütün bilgiler derlenmelidir. Söz konusu bilgilere ilişkin örnekler aşağıda sıralanmıştır: ====
* Bütün kullanım ve/veya görev alanlarının genel tanıtımı,
* Muhtemel operasyonel senaryolar ve her bir senaryo için gereksinimler,
* Ürünün kullanımından kaynaklanan olumsuz çevresel etkiler ve bu etkilerden kaçınabilmek veya onları azaltabilmek için yapılması gerekenler,
* Halen kullanımda olan ürünler için, kullanım dönemi boyunca ortaya çıkan desteklenebilirlik ilişkili problemler,
* Yeni ürünün mevcut ürünlerle etkileşimi ve birlikte kullanılabilirliği,
* Hareket kabiliyeti gereksinimleri,

==== <big>5.1.2.2. PLANLANAN MEVKİLERİN COĞRAFİ KONUMLARI VE ÖZEL KOŞULLARI</big> ====
Ürünün kullanılacağı alanlar ve bu alanlara ilişkin varsa özel koşulları tanımlayan detaylar derlenmelidir. Bu konudaki bilgilere yönelik örnekler aşağıda sıralanmıştır:

* Operasyon alanlarının sayısı ve coğrafi yerleşimi,
* Her bir operasyon mahallinin coğrafi yapısı ve iklim koşulları,
* Her bir operasyon mahallinin tipi,
* Her bir operasyon mahalline özel koşullar (varsa),
* Söz konusu alanın, barış veya savaş durumu bölgesi olup olmadığı (Tehdit durumları, asgari düzeyde müdahale ile sınırlı olan özel acil durum bakım konseptlerinin geliştirilmesini gerektirir),
* Her bir operasyon alanına erişmek için yeterli altyapı mevcut mu?
* Her bir alan için özel bir altyapı gereksinimi var mı?
* Her bir alan için mevcut ve planlanan kabiliyetler neler (Örn. ekipman, altyapı, personel, tesis, ikmal deposu, onarım atölyesi, vb.),
* Farklı alanlar arasında etkileşimler (örneğin, bir alandan diğer bir alana bakım desteği verilmesi).

==== <big>5.1.2.3. KONUŞLANMA VE ÜRÜN DESTEĞİ</big> ====
Ürünün konuşlanmasına ve konuşlanmadan kaynaklanan etkileşimlere dair detaylar derlenmelidir. Ürünün konuşlandırılacağı yer, organik veya yüklenici desteğine ilişkin kararları etkileyecektir. Bu konuda:

* Her bölgede desteklenecek sistem sayısı,
* Her bölgede konuşlandırılacak ürünler ve
* Farklı alanlar arasında kullanımdan kaynaklanan etkileşimler gibi bilgilerin toplanması gerekir.

==== <big>5.1.2.4. KULLANIMA GENEL BAKIŞ</big> ====
Ürünün planlanan kullanım bilgisi lojistik analizlere temel girdi olarak tanımlanmalıdır. Kullanımın sıklığı ve süresi, ürün güvenilirliği ile birlikte ihtiyaç duyulacak destek kaynaklarının kapsamını ve miktarını belirlemekte başlangıç noktasını oluşturur. İlişkili bilgilere örnekler aşağıda sıralanmıştır:

* Her bir lokasyon için temel kullanım/görev bilgileri
* Performans parametreleri ve kısıtlar (Menzil, doğruluk oranı, faydalı yük, hız vb. parametreler ölçülebilir terimlerle tanımlanmalıdır. Genel terimler veya yoruma açık belirsiz ifadelerden kaçınılmalıdır).
* Öngörülen kullanıma hazır olma ve kullanım başarı oranları
* Birim zamanda operasyon
* Kullanım günü, haftası, ayı veya yılına özgü kullanım/görev profili
* Ürünün işletim zamanı içerisinde eğitim amaçlı kullanılma oranı
* Daimi kullanım şartları/Olası bakım aralıkları
* Her bir kullanım etkinliğinin ortalama süresi
* Birim zamanda kullanıma yönelik temel ölçüm bazı

=== 5.1.3. MÜŞTERİ GEREKSİNİMLERİ ===
Ürünün uygun şekilde kullanımının sağlanması için müşteri bütün lojistik ilişkili isterlerini de yükleniciye iletmelidir. Müşteri isterlerinin kapsamı ve içeriğinde yer alabilecek bilgiler aşağıda tanımlanmıştır.

==== <big>5.1.3.1. İKMAL KONSEPTİ</big> ====
İkmal konsepti desteklenebilirlik mühendisleri açısından kritik önem arzetmektedir. Yedek parça ve sarf malzeme tedariğinin nasıl organize edileceğine dair genel karar, bakım senaryoları üzerinde önemli etki gösterebilmektedir. Lojistikçi, depolama alanlarına yönelik planlama ihtiyacı olup olmadığı ve tedarik zinciri yönetiminin dış kaynaktan temini durumunda kim tarafından yönetileceğine karar vermelidir. Özellikle tesis inşaatına dair maliyetler ve teknolojik eskime dikkate alınması gereken önemli hususlardır.

==== <big>5.1.3.2. DESTEK EKİPMANI KONSEPTİ</big> ====
Maliyet açısından etkin olması durumunda özel destek ekipmanları yerine yaygın destek ekipmanları tedarik edilmelidir. Maliyetleri düşürmek için, mevcut destek ekipmanlarının kullanılıp kullanılamayacağı veya yeni sisteme adapte edilip edilemeyeceğinin değerlendirilmesi önemlidir.

==== <big>5.1.3.3. PERSONEL ENTEGRASYONU VE EĞİTİM</big> ====
İşgücü konusu birçok sistemin desteklenebilirliği için önem taşır. Destek personelinin uygun zamanda eğitim alabilmesi için planlama yapılmalıdır.

Eğitim ihtiyaçlarının iki bileşeni vardır: Başlangıç ve süreklilik eğitimleri. Her ikisi de yeterli personel becerisinin sağlanması açısından önemlidir. Personel devir oranlarının yüksek olması, belirli bir beceri setinin idamesini zorlaştıran bir etkendir. Desteğin planlanması aşamasında bu hususlar da dikkate alınmalıdır.

==== <big>5.1.3.4. TESİSLER</big> ====
Tesislere ilişkin uzun saha temin ve tahsis süreleri, tesis ihtiyaçlarının erken dönemde planlanmasını zorunlu kılar. Bakım faaliyetlerinde kullanılacak tesisler bakım sürecindeki  tüm faaliyetleri ve iş akışlarını destekleyecek şekilde planlanmalıdır.

==== <big>5.1.3.5. BİLİŞİM VE HABERLEŞME KAYNAKLARI</big> ====
Bilişim ve haberleşme kaynak ihtiyaçları desteklenebilirlik mühendislerinin erken dönemde hazırlık yapmalarını gerektiren bir başka alandır. Bu konuda dikkate alınması gereken hususlar aşağıda sıralanmıştır:

* Diğer hizmetlerle ara yüzü sağlamak için ne gibi kısıtlar vardır/gereklidir?
* Örneğin X altyapısı operasyonel kullanılabilirlik açısından arzu edilir bir iyileştirme sunarken, başka bir hizmet tarafından kullanılan Y haberleşme ağına erişime engel oluyorsa nasıl bir ödünleşim yapılmalıdır?
* Nasıl bir bilgi teknolojisi altyapısına ihtiyaç duyulmaktadır?

Bilgi teknolojisi kaynaklarının bilgisayar donanımı, ağ bileşenleri, ağ kablolamaları haberleşme protokolleri, yazılım paketleri, veri güvenliği ve standartlar gibi birçok yönü vardır. Bu konu aynı zamanda gelecekte öngörülen kabiliyetlerin de anlaşılmasını gerektirir. “Sahaya verildiği zaman kullanımda olacağı tahmin edilen sistemler”le ara yüzü olacak şekilde bir sistem tasarlamak tasarım ve desteklenebilirlik mühendislerinin diğer ilgili projelerin durumundan haberdar olmalarını gerektirir. Sistemin planlanan gelecekteki haberleşme mimarisi ile nasıl bir ara yüz kuracağı ele alınmalıdır. Lojistikçi, muhtemel bilgi teknolojisi sistem değişikliklerinin etkisini değerlendirmeli ve lojistik yapıda gerekli düzenlemeleri belirlemelidir.

=== 5.1.4. SAHA İNCELEMELERİ ===
Saha incelemeleri, tasarlanacak olan ürünle ilişkili yürütülecek olan LDA faaliyetlerinin planlanmasında çok büyük bir öneme sahiptir. Yürütülen inceleme faaliyetlerinde ihtiyaç makamı/kullanıcı/idame makamı’nın bünyesinde bulunan eğitim ve kurs yerlerinin, bakım fabrikalarının ve bakım birliklerinin imkânları ve kullanıcı ve bakım personelinin bilgi ve tecrübesi tespit edilir. Bu sayede tasarımı yapılacak olan sistemin kullanım ve destek süreçleri geliştirilirken, mevcut tesis imkimkânanları ve personel becerileri göz önünde bulundurulur. Envanterde bulunan benzer sistemler detaylı olarak incelenir, bu sistemler ile ilgili bakım personellerin ve sistemi kullanan operatörlerin yaşadıkları sıkıntılar ve zorluklar tespit edilir. Muharebe/operasyon alanında, bakım fabrikalarında, bakım birliklerinde yedek parça ve sarf malzemesi tedariğinde yaşanan problemler, bakım yöntemlerinin uygulanmasında yaşanan sorunlar, yedek ve sarf malzemelerinin paketlenmesinde, depolanmasında, elleçlenmesinde ve taşınmasında yaşanan sorunlar tespit edilir. Bu kapsamda saha incelemelerinde, proje kapsamına göre LDA faaliyetleri ile ilişkili soru setleri oluşturularak, incelenmekte olan sistemin/sistemlerin geneli ve mümkünse alt sistem ve parça seviyesinde detaylı bilgiler toplanır.

Saha incelemelerinde kullanılabilecek örnek bir soru seti Tablo 4’de verilmiş olup proje veya konuya özgü sorular da bu tabloya eklenebilir.

'''Tablo 4 Örnek Soru Seti'''
{| class="wikitable"
| colspan="2" |'''Örnek Soru Seti'''
|-
|'''Sıra No'''
|'''PEDU'''
|-
|001
|Kaç tip ambar mevcut? Ambarların/Depoların ortam koşulları nedir? (Nem,  sıcaklık, aydınlatma, havalandırma, vb.)
|-
|002
|Kullanılan bir paketleme standardı var mı?
|-
|003
|Paketleme malzemesi olarak ne kullanılıyor?
|-
|004
|Kullanılan paketler tekrar paketlemede kullanılabilir özellikte mi?
|-
|005
|Paket dolgu malzemesi kullanılıyor mu? Ne tip bir dolgu malzemesi  kullanılıyor?
|-
|006
|Tampon malzeme kullanılıyor mu? Kullanılıyorsa kalınlığı nedir?
|-
|007
|Uygun kaldırma noktası mevcut mu? Eğer uygun kaldırma noktası yoksa bu  durum taşıma/kaldırma vb. işlemler sırasında zorluk çıkartıyor mu?
|-
|008
|Kaldırma, depodan araca yükleme, araçtan depoya aktarma, vb. işlemler  sırasında kullanılan ekipman nedir? (vinç, cayraskal, forklift, vb.)
|-
|009
|Etikette yer alan bilgiler nelerdir? Herhangi bir etiketleme standardı  kullanılıyor mu?

(sandık numarası, alt sistem/cihaz/malzeme adı, ambalaj sıra no, netve brüt  ağırlık ve hacimleri, NSN ve/veya Parça no, miktar, son kullanma tarihi, v.b)
|-
|010
|Kutusundan/Paketinden çıkartırken ve kullanıma hazırlarken uygulanan özel  bir işlem var mı? Herhangi bir askeri standart kullanılıyor mu?
|-
|011
|Araçtan sökülen ve farklı bir bakım seviyesine nakli yapılacak sistem  bileşeni paketleniyor mu? Herhangi bir askeri standart kullanılıyor mu?
|-
|012
|Araçtan sökülen ve uzun süre depoda tutulacak olan sistem bileşeni  paketleniyor mu? Herhangi bir askeri standart kullanılıyor mu?
|-
|'''Sıra No'''
|'''BGA'''
|-
|013
|Bakımlar, bakım dokümanı dışında başka hiçbir dokümana ihtiyaç duyulmadan  gerçekleştirilebiliyor mu?
|-
|014
|Bakım sarf ve yedeklerinin tedariğinde zorluk yaşanıyor mu?  Alternatifleri var mı?
|-
|015
|Bakım sarf ve yedeklerinin tedariği gecikiyor mu? Maliyet bilgileri  mevcut mu?
|-
|016
|Depoda/Ambarda muhafaza edilen malzemeye uygulanan bir bakım mevcut mu?
|-
|017
|Bakım sistem çalışır vaziyetteyken yapılabiliyor mu?
|-
|018
|Cihaz sistem üzerinde montajlıyken ilgili parça sökülebiliyor mu?
|-
|019
|Cihaz sistem üzerinde montajlıyken ilgili parçanın bakımı yapılabiliyor  mu?
|-
|020
|Bakımı yapan personelin ihtisası (elektrik, motor, vb.) ne olmalı?
|-
|021
|Ne tip bir temizlik malzemesi ile temizleniyor?
|-
|022
|Temizlik malzemesinin insan sağlığına ne gibi etkileri var?
|-
|023
|Bakım işlemlerinde boyanın temizlenmesine ve tekrar boyanmasına ihtiyaç  var mı?
|-
|024
|Özel tezgâh ihtiyacı var mı?
|-
|025
|Özel alet/avadanlık gerekiyor mu? Gerekiyorsa kaç adet, bunlar neler?
|-
|026
|Kullanılan alet/avadanlıklar metrik birim sisteminde mi?
|-
|027
|Bakım dokümanlarında hangi birim sistemi kullanılıyor? Kullanılan birim  sistemi zorluk yaratıyor mu?
|-
|028
|Periyotları çakışan bakımlar olduğunda yapılacak bakımlarda sökülmesi  gereken parçalar birbirleri ile ardışık veya ilişkili mi?
|-
|029
|Periyotları çakışmayan bakımlar arasında ardışık/ilişkili parçaların  sökülmesi gereken bakımlar var mı?
|-
|030
|Bakımlar karmaşık adımlardan mı oluşuyor?
|-
|031
|Periyodik bakım tanımlı olduğu halde uygulanmazsa araç veya sistem bundan  nasıl etkileniyor?
|-
|032
|Periyodik parça değişimli bakımlarda, periyodu gelmeden  arızalanan/değiştirilmesi gereken parçalar oluyor mu?
|-
|033
|Bakımda kullanılan veya değiştirilen parçalar için özel imha metodu var  mı?
|-
|'''Sıra No'''
|'''HTEKA'''
|-
|034
|Hasarlı parça ıskartaya mı ayrılıyor yoksa laboratuvar incelemesi  yapılmak üzere üreticiye/ilgili bakım kademesine gönderiliyor mu?
|-
|035
|Diyagnostik imkânı var mı?
|-
|036
|Çalışma değerleri herhangi bir ölçüm cihazı ile izlenebiliyor mu?
|-
|037
|Çalışma değerlerinin herhangi bir ölçüm cihazı ile izlenemiyor olması  arıza tespitinde zorluk yaratıyor mu?
|-
|038
|Arızalandığı zaman sistemi durdurmak gerekiyor mu yoksa sistem çalışmaya  devam edebilir mi?
|-
|039
|Arızalandığı zaman sisteme veya diğer alt sistemlere/bileşenlere de zarar  veriyor mu?
|-
|040
|Meydana gelen arızalar/hatalar arasında mevcut bakımlar ile giderilemeyen  oluyor mu?
|-
|041
|Arıza kayıtları var mı? Seri kontrollü olarak tutuluyor mu?
|-
|'''Sıra No'''
|'''OSA'''
|-
|042
|İlgili sistem bileşeninin bakımları hangi kademede yapılıyor? 
|-
|043
|Aynı anda kaç sistemin bakımı yapılabiliyor?
|-
|044
|Eğer limit aşımı olursa bakımı yapılacak araç farklı birliğe mi  yönlendiriliyor, bir üst kademeye mi yönlendiriliyor yoksa sırada mı  bekliyor?
|-
|045
|Bakımı yapılacak araç/sistem ne tip bir taşıtla getiriliyor?
|-
|046
|Ulaştırma maliyetleri nedir? (Taşıt cinsi + km)
|-
|047
|Bakımı yapılacak aracın/sistemin birliğe taşınması ne kadar sürüyor?
|-
|048
|Bir üst kademede bakımı yapılacak aracın/sistemin ilgili kademeye  ulaşması ne kadar sürüyor?
|-
|049
|Bakımı bir üst kademede yapılacak sistem bileşeninin hata/arıza tespiti  hangi kademede yapılıyor?
|-
|050
|Birlik seviyesinde bakımı yapılacak sistem bileşeninin hata/arıza tespiti  hangi kademede yapılıyor?
|-
|051
|Taşıma/ulaştırma için hangi yönetmeliklere tabii tutuluyor?
|}

=== 5.1.5. KALİFİKASYON VE SERTİFİKASYON GEREKSİNİMLERİ ===
Müşteri, bir kalifikasyon süreci yürütmek istediğinde, ürünün kalifikasyonu içerisinde bakım faaliyetlerinin ne şekilde ele alınacağı yüklenici ve müşteri tarafından programın erken safhalarında açıklığa kavuşturulmalıdır. Kalifikasyon gereksinimleri müşteri tarafından belirlenmeli ve operasyonel gereksinimler ile aynı zamanda yükleniciye iletilmelidir.

Benzer şekilde ürünün öngörülen çevresel koşullarda işletimi için bir sertifikasyon süreci gerekiyorsa, sertifikasyonun kapsamında yer alacak bakım faaliyetlerinin belirlenmesi ve dokümante edilmesine özellikle dikkat edilmelidir. Bu faaliyetler yerine getirilmesi zorunlu faaliyetlerdir. Sertifikasyonu etkileyen bakım faaliyetleri birinci derece önceliğe sahip olmalıdır.

Kalifikasyon gereksinimleri müşteri tarafından belirlenirken sertifikasyon gereksinimleri bir sertifikasyon otoritesi tarafından belirlenir. Müşteri ve yüklenici, kalifikasyon ve sertifikasyon süreçleri arasındaki farkların ilgili kişiler tarafından bilinmesini sağlamalıdır.

== 5.2. LDA İLİŞKİLİ ÜRÜN TASARIM VE PERFORMANS VERİLERİNİN BELİRLENMESİ ==
Ürün tasarım ve performans verileri LDA’yı doğrudan veya dolaylı olarak etkilemektedir. Sistemin ömür devri boyunca karşılaşacağı çevresel koşullar, kullanım parametreleri ve performans isterleri LDA için önemli girdilerdir. Örnek olarak bir askeri kara aracının %60 eğime tırmanması ile ilgili teknik bir ister LDA’yı etkilemektedir. Aracın bu denli yüksek bir eğim tırmanma kabiliyeti, araç operatörlerinin bu konuda eğitimli ve bilgili olması ile mümkündür. Aynı zamanda ömür devri boyunca bu gibi bir durumla kaç kez karşılaşacağı bilgisi de aracın bakım planlaması için önem arz etmektedir.

LDA ile ilişkili ürün tasarım ve performans verileri belirlenirken yalnızca sistemin ömür devri boyunca karşılaşacağı çevresel koşullar, kullanım parametreleri ve performans isterlerinden değil, aynı zamanda bu isterleri gerçekleştirecek fiziksel ekipmanlardan ve bu ekipmanların üreticilerinin üretmiş olduğu teknik dokümanlardan da faydalanılır.

Örnek olarak askeri bir kara aracında teknik isterleri sağlaması için seçilmiş bir motorun yağlama ve bakım periyotları LDA için büyük önem arz eder. Diğer bir örnek ise motorun arızalar arası ortalama süresi, yani güvenilirlik karakteristikleridir. Yedek parçaların neler olduğunun belirlenmesi ve ne zaman nerede bulunması gerektiği bilgisi LDA sonuçları ile ortaya konacaktır.

Sistem gereksinim tanımlama aşamasında ve/veya ön tasarım aşamasında yürütülen ürün tasarım ve performans verilerinin belirlenmesi faaliyetleri esnasında dikkate alınabilecek hususlar aşağıdaki başlıklarda detaylı bir şekilde yer almaktadır:

* LDA ile ilgili veri ve bilgilerin seçim kriterleri
* LDA veri seçiminde genel LDA yaklaşımlarının ve ilkelerinin etkisi
* Seçim değerlerinin doğrulanması ile ilgili kabul kuralları
* Öngörülen değerlerin doğrulanması için kriterler ve prosedürler
* İhtiyaç makamı/kullanıcı/tedarik makamı/idame makamının katılımı

=== 5.2.1. LDA İLE İLGİLİ VERİ VE BİLGİLERİN SEÇİM KRİTERLERİ ===
LDA ile ilişkili olarak dikkate alınması gereken veri ve bilgiler, LDA süreci kapsamında doğrulama ve kontrollere tabi olan veri ve bilgilerdir. Seçim kriterleri; LDA uygulanacak ürüne, ilgili sözleşmeye, şartnameye ve belirlenmiş ELD yaklaşımına bağlı olarak ayrıntılı bir şekilde belirlenmelidir. İlgili bilgiler, oluşturulan LDA süreci kapsamında doğrulanacak bir hedef belirlemek üzere LDA veri tabanı içerisinde gereksinim olarak dokümante edilebilirler. Genel bir yaklaşım olarak, aşağıdaki paragraflarda tanımlanan seçim kriterleri göz önünde bulundurulmalıdır:

==== <big>5.2.1.1. Sözleşme Dokümanlarından Türetilen LDA Bilgi ve Verilerinin Seçimi</big> ====
LDA veri tabanında dokümante edilmiş bilgilerle doğrulanabilecek LDA ilişkili ürün tasarım ve performans özellikleri için, sözleşme dokümanlarının dikkatle değerlendirilmesi gerekmektedir. Genellikle ürün gereksinimleri ya da Anahtar Performans Göstergeleri olarak adlandırılan önemli noktalar, potansiyel olarak sözleşme teşvikleriyle ilgili zorunlu hedefler ve/veya eşikler oluşturmak için bu dokümanlarda ele alınmaktadır.

Anahtar Performans Göstergeleri örnekleri:

* Çalışma saati başına belirtilen Maksimum Bakım Saati.

''Bu değer başarılı bakım tasarımı ile ilgili bir referans noktası olarak kullanılabilir.''

* Onarım için belirtilen Maksimum Ortalama Süre ve Onarım için belirtilen Maksimum Ortalama Süre Yüzdesi.

''Bu değerler belirlenen zaman kısıtlamaları içinde onarımla ilişkili olduğu için başarılı bir tasarım göstergesi olarak kullanılabilir.''

* Çalışma saati başına belirtilen Maksimum Hata Sayısı.

''Bu değer ürünün istenen güvenilirliğin ve ters orantılı olarak bakım iş yükünün bir göstergesidir.''

* Minimum Kullanılabilirlik ile ilgili belirlenmiş rakamlar.

''Bu değerler kullanıma hazır olma konusunda başarılı bir tasarım göstergesi olarak kullanılabilir.''

* Test edilebilirlik özellikleri.

''Bu değerler hayati fonksiyonların izlenmesine ve Cihaz İçi Test Ekipmanı (CITE) ve genel test mimarisi gibi yollarla potansiyel arızaların tespit ve lokalizasyonuna yönelik tasarımın kabiliyetini göstermektedir.''

* Minimum Kullanım Ömrü

''Bu değer minimum kullanım ömrü gereksinimini gösterir. Bu değer belirlenen eşiğin altına düşme riskini göstermelidir.''

==== <big>5.2.1.2. Ürün Kullanım Verilerinden Türetilen LDA Bilgi ve Verilerinin Seçimi</big> ====
İlgili bilgiler LDA veri tabanında temel referans olarak dokümante edilir.

Örnekler:

* Ölçüm Tabanı ile Yıllık Kullanım Gereksinimleri, 
* İşletme yeri/tesis sayısı,
* Her tesiste işletilecek sistem sayısı,
* Her tesiste kurulacak bakım seviyeleri,
* Her tesiste mevcut bakım personeli (branş ve beceriye göre kişi sayısı)

==== <big>5.2.1.3. Ürün Şartnamelerinden Gelen LDA Bilgi ve Verilerinin Seçimi</big> ====
Ürünün tasarımını ve performansını etkileyen LDA ile ilgili parametreler doğrulama ve/veya kontrol amaçlı LDA veri tabanında belgelenir.

Örnekler:

* Minimum değer gösteren ilgili ölçüm tabanı ile birlikte MTBF,
* Güvenilirlik artışı,
* Cihaz İçi Test Ekipmanı ile belirlenmiş test özellikleri,
* Ortalama Onarım Süresi,
* Diğer Ürün Belgelerinde Yer Alan Ürün Sertifikasyonu ve Doğrulaması ile ilgili LDA Veri ve Bilgilerinin Seçilmesi.

LDA ile ilgili bilgiler tasarım bölümleri, emniyet veya müşteri dokümanlarından da elde edilebilir.

Örnekler:

* Özel kullanım ve/veya onarım sınırlamaları (Örneğin; sıcaklık aralıkları, anti-statik koruma gereksinimleri, temiz hava onarım koşulları),
* Geçerlilik bilgisi (Örneğin; sürüm uygulanabilirliği),
* Tehlikeli arızaların sınıflandırılması,
* Depolama sınırlamaları ve/veya gereksinimleri,
* Belirli parçaların kritiklik sınıflandırması,
* Zamanlanmış gereksinimler (Örneğin; belirlenen zaman sınırları, büyük bakım (overhaul) gereksinimleri).

=== 5.2.2. LDA VERİ SEÇİMİNDE GENEL LDA YAKLAŞIMLARININ VE İLKELERİNİN ETKİSİ ===
İlgili ürün tasarımı ve performans verilerinin belirlenmesinden önce, LDA programının uyarlanmasının bir parçası olarak genel bir LDA yaklaşımı oluşturulmalıdır. Uyarlama süreçleri projenin karmaşıklığına, iş birimlerine (yükleniciye) ve bilinen risk faktörlerine bağlıdır. Bu kısıtlamalar ve performans gereksinimleri, gerekli analiz çabaları, zaman, program ve tahsis edilen bütçe arasında, proje için en uygun maliyet/fayda ile dengelenir. Sonrasında bu gereksinimler, konular ve kısıtlamalar gözden geçirilir ve tüm paydaşlar arasında bir fikir birliği sağlamak için LDA İş Tanımlama Toplantısı’nda değerlendirilir. Bu bulgular, analizler ve sonuç anlaşmaları LDA İş Tanımı ile belgelendirilir.

Bu uyarlama aktivitesi yinelemeli bir süreçtir ve programın her aşamasında tekrarlanmalıdır. Her bir önceki aşamadan elde edilen sonuçlar ve öğrenilen dersler, aşağıdaki aşamaların her biri için uyarlama analizinin bir parçası olmalıdır.

Genel LDA yaklaşımları ve ilkeleri, LDA süreci ile ilgili olarak ürün tasarımı ve performans verilerinin seçimini etkileyebilir. Bu alanda sürdürülebilirlik için dikkate alınması gereken örnekler aşağıdaki gibidir:

* Üç seviyeli bakım konsepti

Bakım faaliyetleri kullanıcı, birlik ve fabrika/firma seviyesi olarak ayrılmıştır. Kullanıcı seviyesinde operatör/kullanıcı/sürücü/mürettebat tarafından yapılabilecek bakımlar icra edilir. Birlik seviyesinde arızalı Hatta Değiştirilebilir Birimler (HDB), faal HDB'ler ile değiştirilirken; fabrika/firma seviyesinde arızalı HDB'lerin onarımları yapılır. Fabrika/firma seviyesi bakım faaliyetleri üretici firmalar tarafından yapılabileceği gibi organik bakım tesislerinde gerçekleştirilebilir.

* Önceden belirlenmiş iki seviye bakım konsepti

Bakım esasen ''arızalı parçanın değiştirilmesi'' ya da ''arızalı parçanın onarımı'' olmak üzere iki bakım seviyesiyle sınırlıdır. İki seviyeli bakım konseptleri işletme sahasında çıkarılacak ve değiştirilecek ekipmanın (HDB) düşük bir arıza oranı ve yüksek bir test edilebilirlik oranına sahip olduğu takdirde genel maliyet hususları sebebiyle tercih edilir.

Bu konsept ile LDA verileri önceden belirlenmiş Bakım Seviyeleri (BS) ile sınırlandırılır.

* Belirli bir bakım seviyesi üzerinde yoğunlaştırılmış Onarım

Onarım, maliyet etkinliğinden bağımsız olarak maksimum özerklik elde etmek için organik bakım tesisleri ile sınırlıdır.

Bu konsept ile, onarım opsiyonu verileri önceden belirlenmiş BS ile sınırlandırılır.

* BS 1 ve/veya 2'de Sınırlı Onarım

Herhangi bir operasyonel aksama süresini kısaltmak için düzeltici bakım eylemi bir yedek parça değişimi (yerinde olmayan onarım -) ile sınırlandırılabilir.

Bu konsept ile bakım görevi önceden belirlenmiş kriterler ile sınırlandırılır.

* Tek kaynak prensibi

Büyük onarım gerektiğinde, sistem/alt sistem/bileşen tedarikçisi ilgili deneyime, personele ve ekipmana en çok sahip ve en hızlı hazır olan şeklinde tercih edilmelidir.

Bu konseptte onarım verileri tedarikçi bilgileri ile sınırlandırılır.

* Ara destek kavramı

Bakım Konsepti (BK) kararlarından önce deneyim kazanmak ve riskleri azaltmak için ara destek aşaması oluşturulabilir.

Bu konseptte BK verileri ön bilgi ile sınırlandırılır.

* Rafta Hazır Ticari Ürün (RAHAT) kavramı

Piyasada mevcut ekipman kullanıldığında ilgili koşullar kabul edilmelidir.

Bu konsept ile veriler ilgili tedarikçi bilgilerini/koşullarını yansıtmalıdır.

=== 5.2.3. DOĞRULAMA DEĞERLERİNE İLİŞKİN KABUL KURALLARI ===
Doğrulama süreci esnasında belirsizliklerden kaçınmak için açıkça tanımlanmış kabul kuralları oluşturulmalıdır. Bu kurallar, LDA ilişkili ürün tasarım ve performans verilerine dair sonuçların hassas bir şekilde kabul veya reddedilmesine imkân sağlayacaktır.

==== <big>5.2.3.1. Ölçüm Değerleri Kategorisi</big> ====
İlgili ölçüm değerinin önemini ifade eden gereksinim türleri tanımlanmalıdır. Bu türler:

* Zorunlu değerler,
* Hedefler,
* Eşikler (minimum veya maksimum değerler).

==== <big>5.2.3.2. Toleransların Belirlenmesi</big> ====
Tanımlanan her bir ölçüm değeri için ilgili toleranslar ifade edilmelidir.

* Tek bir değer için atanmış,
* Benzer değerlerden oluşan bir grup ile ilgili toleranslar, örneğin; tek bir kalem yerine grubun başarısızlık oranını karşılamak için analiz edilen kalemlerin belirli bir alanı içindeki hata oranlarının telafi edilmesi (Örneğin; ek kısıtlamaların izlenmesi).

==== <big>5.2.3.3. Kabul Kriterlerinin Oluşturulması</big> ====
İlgili gereksinim ile birlikte her bir değer için ölçülebilir kabul kuralları oluşturulmalıdır. Bu kurallar, LDA veri tabanında belgelenen değerlerin kabul edilmesine veya reddine yol açan temel koşulları (Örneğin, yeterli istatistik güven düzeylerine dayalı olarak minimum gerekli değerlerin yerine getirilmesi) tanımlamalıdır.

Ayrıca, oluşturulmuş durum bilgilerinin sonuçları açıkça belirtilmelidir:

* Belgelenen değerin kabul edildiğini gösteren Analiz Altındaki Kalem’in (AAK) durumu,
* AAK'nin belgelenmiş değerin ilgili gerekçeyle reddedildiğini gösteren durumu,
* Belgelenen şeklin şartlı kabul edildiğini belirten AAK'nin durumu (Örneğin; genel olarak kabul edilebilir ancak yeniden çalışma gerektiren).

==== <big>5.2.3.4. Özel Kuralların Oluşturulması</big> ====
Özel kurallar belirlendiğinde, belirsizlikten kaçınmak için ilgili koşullar ve ilgili değerler net olarak tanımlanmalıdır:

* Başarısız olarak belirtilen LDA verilerine ilişkin ceza düzenlemelerinin oluşturulması
* Belirtilen LDA değerini aşması durumunda ödüllerin oluşturulması

=== 5.2.4. ÖNGÖRÜLEN DEĞERLERİN DOĞRULANMASI İÇİN KRİTERLER VE PROSEDÜRLER ===
Son olarak, doğrulamaya tabi olan verilerin ve/veya diğer bilgilerin doğrulanması için kriterler oluşturulmalıdır.

==== <big>5.2.4.1. Ölçülebilir Hedef Değerlerin Belirlenmesi</big> ====
Göz önüne alınan veri unsurları için ilgili öngörülen değer aralığı LDA veri tabanı içerisinde, orijinal toleransları ve varsa ilgili kabul kuralları ile birlikte orijinal hedefi dikkate alarak bir gereklilik olarak kurulmalı ve belgelendirilmelidir.

==== <big>5.2.4.2. Öngörülen Değerlerin Doğrulanması</big> ====
Analiz sürecinden elde edilen LDA veri tabanında belgelenen ilgili veriler ve diğer bilgiler, ilişkili kabul edilebilir değerlerle karşılaştırılmalıdır. Sonuç, gerçekleşen LDA değerlerinin öngörülen değerler ile tutarlı olup olmadığını belirten analiste ve/veya ilgili yönetime rapor edilmelidir.

==== <big>5.2.4.3. Doğrulama Yöntemi</big> ====
Öngörülen değerler ve doğrulama yöntemleri üzerinde anlaşmaya varılmalıdır:

* Analitik kanıt sunarak doğrulama (LDA veri tabanında belgelenmiş),
* Uygun testlere dayanan bir analitik yöntem kullanarak doğrulama (Örneğin; bir test teçhizatında),
* Ürünün prototipinde veya seri versiyonlarında gösterim ile doğrulama,
* Sertifika ve/veya gösterim programları kurallarına göre doğrulama,
* Deneme oturumları ile doğrulama (Örneğin; Kullanıcı/Tedarik Makam personeli tarafından gerçekleştirilen),
* Uzun süreli denemeler sırasında doğrulama (Örneğin; belirli bir “olgunluk aşaması” sırasında).

==== <big>5.2.4.4. Özel Amaçlar için Doğrulama</big> ====
Sertifikalar, nitelikler veya lisanslar elde etmek için özel amaçlar için doğrulama gerektiğinde belirli kurallar oluşturulabilir.

==== <big>5.2.4.5. Durum Kodlarının Güncellenmesi</big> ====
Doğrulama sonuçlarına bağlı olarak ilgili durum bilgisi durum tahsisi için belirlenen kuralları izleyerek doğrulama sonucuna bağlanmalıdır.

=== 5.2.5. KULLANICI/TEDARİK MAKAMI KATILIMI ===
LDA süreci kapsamında doğrulama ve kontrole tabi ürün tasarım ve performans verilerinin seçimi müşteri tarafından LDA GGT sırasında kabul edilmeli ve KKB'de belgelenmelidir. Bu aynı zamanda ilgili kuralların ve öngörülen değerlerin anlaşılması için de geçerlidir.

== 5.3. LDA İŞ TANIMLAMA TOPLANTISI ==
LDA uygulanacak aday kalemlerin seçimi, bahse konu aday listesine uygulanacak yöntemler ile ilgili LDA İş Tanımının yapılması, LDA aktivitelerinin belirlenmesi ve planlaması için tüm paydaşların katılımı ile LDA İş Tanımlama Toplantısı gerçekleştirilir. Bu toplantıda alınan kararlar neticesinde LDA adayları seçim kriterleri nihai hale getirilir ve LDA İş Tanımı ve LDA planı onaylanır. Böylelikle ilgili projede LDA uygulanırken izlenecek yöntemler, ara çıktılar, safha sonlarında yer alan çıktılar tümüyle belirlenmiş olur.

Bu kapsamda yer alan öneriler ile verimli bir LDA iş süreci işletilebilmesi hedeflenmektedir.
[[Dosya:LDA İş Süreci v.jpg|alt=|sol|küçükresim|687x687pik]]
































=== 5.3.1. LDA İŞ TANIMLAMA TOPLANTISI HAZIRLIK FAALIYETLERI ===
Toplantı esnasında en iyi performansı sağlayabilmek için toplantı girdilerinin hazır olması, sonuç ve nihai mutabakata dair net beklentilerin tanımlı olması ve taslak LDA iş tanımı kapsamında hazırlanmış kontrol listelerinin kullanılması ile izlenecek adımların takibi ve üzerinde gerçekleştirilecek çalışmaların yönetilmesi kapsamında faydalıdır.

LDA İş Tanımlama Toplantısı için girdi olabilecek dokümanlar aşağıdaki şekildedir:

* Sözleşme ve Ekleri,
* Genel kullanım hususları,
* Operasyonel gereksinimler,
* Taslak LDA adayları listesi,
* Taslak veri elemanları listesi,
* Taslak LDA İş Tanımı,
* Taslak LDAP.

Diğer taraftan, erken stratejik değerlendirmelere bağlı olarak zorunlu ve önerilen LDA aktivitelerinin belirlenmesi gibi hususların önceden düşünülmüş olması yararlı olacaktır.

Bu kapsamda aşağıdaki hususlar dikkate alınarak çalışmalar yürütülür;

* '''Aday Kalem ve Aday Olmayan Kalem:'''

LDA adayı tüm LDA aktivitelerinin ana yönlendiricisidir. Potansiyel bir LDA adayı, genel olarak onarım yapılabilen veya planlı/plansız bakım görevi bulunan bir sistem, alt sistem, ekipman, modül veya alt modül seviyesindeki bir kalemdir. Analiz edilecek kalemin konfigürasyon listesinde olup olmaması, yukarıdaki kriterlere ek olarak proje özelindeki kriterlere de bağlı olarak değişebilmektedir.

Donanımla ilgili tanımlamaya ek olarak, özel aktiviteler ürün kırılımının uygulanabilir olması durumunda özel bir bölümünde tanımlanabilir. Örneğin, yapısal bileşenlerin onarımı için standart uygulamaların tarifi, ürün kırılımının özel bir bölümünde belirtilebilmektedir. Bu durumda, donanım dışı bazı arıza unsurları da kendilerine özel aktiviteler veya bakım görevleri tanımlandığı için LDA adayı olabilmektedir.

Aday olmayan malzemeler için ayrıntılı bir lojistik analiz gerekli değildir. Bu tip malzemeler fiziksel ürün kırılımda görünmek zorunda değildir. Özel bir lojistik kaynağın gerekmediği, standart görevlere tabi olan malzemeler de potansiyel aday olmayan malzemedir. Aday olmayan malzemeler için tipik örneklere sarf malzemeleri, vidalar, cıvatalar, somunlar, rondelalar verilebilir. Bununla birlikte, bir malzeme LDA adayı seçim sürecinde aday olarak belirlenmemişse bile Aday Kalem Listesinde aday olarak seçilmeme sebepleriyle birlikte dokümante edilmelidir.

* '''Bakım İlgili Malzeme (BİM) ve Bakım Önemli Malzeme (BÖM):'''

LDA adaylarının belirlenmesi sürecinde bakım/onarım gerektiren malzemeler dikkate alınmalıdır. Bakım görevleri, planlı bakım görevleri ve plansız bakım görevleri olmak üzere iki kategoriye ayrılmaktadır. Bu aşamada aşağıda tanımları verilen iki kavram ortaya çıkmaktadır.

Bakım İlgili Malzeme (BİM): Bir arıza veya hasar durumunda onarılan veya değiştirilebilen malzemelerdir. Bu malzemeler potansiyel LDA adayıdır. Fakat bu malzemeler doğrudan Bakım Önemli Malzeme (BÖM) değildir.

Bakım Önemli Malzeme (BÖM): Önleyici bakım analizleri sonucunda planlı bakım görevleri tanımlanan malzemelerdir. Bu bakım görevleri LDA veritabanında dokümante edilmelidir.

* '''Yapısal Malzeme, Yapısal Önemli Malzeme:'''

Ürün Kırılımında yer alan yapısal malzemeler tipik LDA adayıdır. Bu malzemeler ayrıca planlı bakım analizi için de potansiyel adaylardır. Yapısal malzemelere ilişkin tanımlar aşağıda yer almaktadır.

Yapısal Malzeme: Yapısal Malzeme, sistemin üstyapısının bir parçasıdır. Yapısal Önemli Malzeme (Structure Significant Item) olarak LDA adayı olabilmektedir.

Yapısal Önemli Malzeme: Planlı bakım analizi sonucunda belirlenen malzemelerdir.

* '''Donanım Olmayan Malzeme (Non-Hardware Item):'''

Fiziksel Ürün Kırılımlarında sadece ürüne ait donanımlar dokümante edilmektedir. Ancak özel bir donanıma ait olmayan, bir grup malzeme için (kablo, vb.) tanımlanan bakım görevleri olması durumunda bu tip malzemeler Donanım Olmayan Malzeme adı altında Ürün Kırılımlarına eklenebilmektedir. Bu tip malzemeler LDA adayı olabilmektedir.

=== 5.3.2. LDA İŞ TANIMLAMA TOPLANTISI ===
Bu toplantı, ihtiyaç makamı/kullanıcı/idame makamı/tedarik makamı ve yüklenici tarafından yönetim kadrosu ve uzmanların katılımıyla gerçekleştirilir. Bu toplantı ile LDA Aday Kalem Listesi, Veri Eleman Listesi, LDA İş Tanımı ve LDA Planı nihai haline getirilerek karşılıklı mutabakat sağlanarak gözden geçirme toplantıları ile ömür devri boyunca dokümanlara ilişkin gerekli çalışmalar yürütülür.

==== <big>5.3.2.1. LDA Aday Kalem Listesi</big> ====
Yükleniciler tarafından taslak olarak hazırlanan ilk aday listesi; LDA İş Tanımlama Toplantılarında müşteri ve yüklenici tarafından değerlendirilmeli ve ilk sürüm Aday Kalem Listesi (AKL) dokümanı, seçim kriterlerini de içerecek şekilde yayımlanmalıdır. AKL dokümanı ürün ömür devri boyunca yaşayan, üzerinde değişikliklerin yapılabildiği bir dokümandır.

LDA İş Tanımlama Toplantısında ürün için yapılacak analiz çalışmalarının da yer aldığı AKL dokümanı önemli bir adım olarak yer almaktadır.

LDA sürecinin yönetilebilmesi için analizlerin ve dokümantasyonun versiyon kodları ile tanımlanması gerekmektedir. Çalışmaların etkinliğinin arttırılabilmesi ve proje kapsamında raporların rahat alınabilmesi için AKL’nin bir lojistik veri tabanına girilmesi faydalı olacaktır.

AKL’de yapılacak bütün değişiklikler yüklenici ve müşteri ile koordineli olarak yapılmalıdır. Böylece her iki tarafta yer alan LDA / ELD yöneticileri LDA sürecini güncel dokümanlar üzerinden takip edebilecek ve sözleşmesel gereksinimlerin karşılanıp karşılanmadığını kontrol edebilecektir.

==== <big>5.3.2.2. LDA Adaylarının Sınıflandırılması</big> ====
Ürün Kırılımında yer alan her malzeme için her analiz çalışmasının yapılması durumu gerek maliyet gerekse iş gücü açısından değerlendirilmelidir. Bu nedenle LDA Adaylarının sınıflandırılması gerekmektedir. Sınıflandırma yapılırken malzemenin durumu, kullanıcı/tedarik makamı ile görüşmeler ve üretici firmanın değerlendirmeleri önem arz etmektedir. LDA adaylarının sınıflandırılmasına yönelik tanımlar aşağıda yer almaktadır:

Tam Aday: Geniş ölçekli LDA verisinin oluşturulması gereken malzemelerdir.

Kısmi Aday: Kısmi ölçekli LDA verisinin oluşturulması gereken malzemelerdir.

Aday Ailesi: Özel gereksinimlere odaklanarak analiz edilecek malzeme gruplarıdır (standart kablolar, vb.). Bu tip malzemeler için belirli analiz çalışmaları yapılmaktadır.

Standart Prosedür Adayı: Standart onarım prosedürleri olan ve kısmi ölçüde analiz çalışmaları yapılması gereken malzemelerdir.

'''<big>5.3.2.2.1. LDA Adayları Seçim Süreci ve Kriterleri</big>'''

LDA adayı seçimi için, Ürün Kırılımında yer alan her malzemenin LDA’nın amaçları açısından değerlendirilmesi gerekir.  Değerlendirme sonucu, bir malzemenin seçim kurallarına göre bir aday olduğunu gösterir ise ilgili malzeme LDA adayı olarak belirtilebilir. LDA Adaylarının seçimi için aşağıdaki kriterler ve akış diyagramlarından faydalanılmaktadır.

'''<big>5.3.2.2.2. LDA Adaylarının Seçilmesi, Tanımlanması ve Sınıflandırılması</big>'''

LDA süreci oldukça maliyetli bir süreçtir. Bu nedenle, LDA adaylarının ve ilgili analiz faaliyetlerinin seçilmesi esnasında, LDA sürecinden elde edilen faydalar ile LDA çalışmaları için harcanacak çaba arasında iyi bir denge kurmaya özen gösterilmelidir. Analiz süreçlerinin türüne ve analizin derinliğine göre LDA adayları farklılık gösterebilmektedir.

LDA adaylarının seçilmesi için lojistik açıdan irdelenmiş uygun bir ürün kırılımına ihtiyaç bulunmaktadır. Lojistik kırılımın oluşturulması, LDA süreci boyunca gerçekleştirilecek tüm analizler için yapılması gereken ilk ve temel faaliyettir. Bu sayede analiz edilecek malzemeler de irdelenmiş olacaktır.
[[Dosya:TSSODYP06.05.jpg|alt=|sol|küçükresim|694x694pik|Şekil 5 LDA Adayı Belirlenmesinde Kullanılabilecek Örnek Akış Diyagramı (Yapısal Olmayan Malzeme için) (S3000L)]]


































[[Dosya:Şekil 6 LDA Adayı Belirlenmesinde Kullanılabilecek Örnek Akış Diyagramı (Yapısal Malzeme için).jpg|alt=|sol|küçükresim|624x624pik|Şekil 6 LDA Adayı Belirlenmesinde Kullanılabilecek Örnek Akış Diyagramı (Yapısal Malzeme için)]]










































































LDA adaylarının seçilmesi yöntemlerine geçilmeden önce aşağıda verilen tanımların iyi anlaşılması gerekmektedir.

'''Ürün Kırılımları:''' 

LDA Adaylarının seçilebilmesi için  ürün kırılımlarının yeterli derinlikte oluşturulmuş olması gerekmektedir. Bu husus incelenmelidir.

'''Mevcut Analiz Sonuçları:'''

Daha önceden yapılmış olan analiz sonuçları LDA adayları seçiminde kullanılabilmektedir. Mevcut/benzer sistemlere ait deneyimler, güvenilirlik verileri ve Hata Türleri Etkileri ve Kritiklik Analizi (FMECA) verileri bu kapsamında kullanılabilir.

'''Aday Seçim Kriterleri:'''

LDA adayları seçimi yapılırken Kullanıcı/Tedarik Makamı ile Yüklenici arasında mutabakat sağlanmalıdır. LDA İş Tanımlama Toplantılarına taslak LDA Aday Kalem Listesi ile başlanmalıdır. LDA adayları seçilirken göz önünde bulundurulabilecek kriterlere örnekler aşağıda verilmiştir:

* Malzemeye tanımlı planlı/plansız bakım görevi ve tanımlanmış bakım seviyeleri (örneğin, malzemenin hatta değiştirilmesi ve/veya kullanıcı tarafından belirlenniş seviyede bakım talebi) olup olmadığı bilgisi,
* Malzemeye özel lojistik gereksinim (Personel, eğitim, test&destek ekipmanı, vb.) ihtiyacı,
* Malzemeye özel prosedür (yıldırım düşmesi sonrası yapılacak işlemler, vb. ) ihtiyacı,
* Hasar sonrası tehlike yaratma ihtimali olan malzemeler,
* Malzemeye tanımlı arıza tespiti ve/veya fonksiyonel test görevleri olup olmadığı,
* Yeni teknoloji kullanan malzemeler,
* Ömürlü malzemeler,
* Potansiyel maliyet arttırıcı malzemeler,

* Uzun onarım zamanı nedeni ile kullanıma hazır olmayı etkileyen malzemeler,
* Kullanıcı özel isteği olan malzemeler,
* Kullanıcı tarafından yazılım yüklenebilen malzemeler,
* Bir LDA adayı malzemeye ulaşmak için sökülmesi/takılması gereken malzemeler,
* Genel görevlere ait verilerin LDA veritabanında bulunması (LDA veritabanında verilerin olması durumunda, benzer koşullarda kullanılıp kullanılmayacağı, yapılacak modifikasyonların kapsamı vb. hususlar değerlendirilmelidir.),
* Farklı bir LDA programından alınan verinin entegrasyonunu gerektiren malzemeler (Farklı bir üreticiden alınan LDA verisinin doğrudan kullanılması veya değişiklikler yapılarak mevcut proje LDA verilerine uyumlu hale getirilmesi gerekiyor ise),
* Lojistik analizleri detaylı olmayan malzeme grupları (kablo, vb.),
* Analiz edilecek ürünün karmaşıklığı.

Ayrıca aşağıdaki koşulların bulunduğu malzemeler potansiyel LDA adayı olarak seçilebilmektedir:

* Potansiyel kullanıma hazır olmayı etkileyen faktörlere sahip malzemeler,
* Potansiyel maliyeti etkileyen malzemeler,
* Potansiyel Bakım/Onarımı etkileyen malzemeler,
* Sözleşmesel LDA gerekleri olan malzemeler.

Yukarıda yer alan bütün kriterler için ölçülebilir eşik değerlerinin olması gerekmektedir. Örneğin, malzemenin hata/arıza sıklığının bakım açısından önemli olup olmadığını belirten MTBF gibi açık eşik değerleri belirtilmelidir.

'''Aday Sınıflandırması'''

LDA adaylarını sınıflandırılırken bazı seçim kriterlerinin göz önünde bulundurulması gerekmektedir. LDA adayları sınıflandırılmasında kullanılabilecek bazı sorular aşağıda verilmiştir;

Aşağıda verilen sorulardan herhangi birine “Evet” cevabı verilmesi durumunda malzeme potansiyel Tam Aday’dır. Eğer soruların hepsine “Hayır” cevabı veriliyor ise malzeme muhtemelen Tam Aday değildir.

''Tam Aday için Sınıflandırma Kriterleri:''

Malzeme yeni geliştirilmiş veya büyük bir modifikasyona uğramış malzeme mi?

* Malzeme HDB mi?
* Onarılabilir malzeme mi?
* Düşük Güvenilirliği olan malzeme mi?
* Bakım/Onarım görevi olan malzeme mi?
* Malzeme için tanımlı bakım/onarım görevi kompleks mi? (uzun süren, personel ihtiyacı fazla olan vb.)
* Bakım/Onarım için gerekli olan özel test&destek ekipmanı var mı?
* Planlı bakım analizi sonrası ortaya çıkan planlı veya önleyici bakım var mı?

Aşağıda verilen sorulardan herhangi birine “Evet” cevabı verilmesi durumunda malzeme potansiyel Kısmi Aday’dır. Eğer soruların hepsine “Hayır” cevabı veriliyor ise malzeme muhtemelen Kısmi Aday değildir.

''Kısmi Aday için Sınıflandırma Kriterleri:''

* Erişim için başka bir malzemenin sökülmesi gerekiyor mu?
* Erişim için sökme işlemi sık mı gerçekleştiriliyor?
* Malzeme bakım, test prosedürleri göz önünde bulundurularak daha önce Tam Aday olarak tanımlanmış mı?
* Temizleme, depolama gibi genel aktiviteleri tanımlanmış donanım harici malzeme mi?

LDA Aday Aileleri tanımı benzer veya aynı malzemelerin gruplanması için kullanılmaktadır. Örnek olarak kablolar verilebilir. Aynı özelliklerde ve aynı/benzer konnektörleri olan kablolar bir Aday Ailesi altında değerlendirilebilir. Aşağıda ''Aday Ailesi için Sınıflandırma Kriterleri'' kapsamında kullanılacak sorular yer almaktadır;

''Aday Ailesi için Sınıflandırma Kriterleri:''

* Malzeme sisteme birden fazla aynı veya benzer yollar ile monte edildi mi?
* Bakım/onarım görevleri aynı veya benzer olan malzemeleri gruplamak mümkün mü?

==== <big>5.3.2.3. LDA İş Tanımı</big> ====
Raporlama, veri elemanları tanımları, veri değişim prosedürleri ve analizleri gerçekleştirmek için kullanılacak yazılım seçimleri gibi faaliyetler hakkında lojistik destek analiz süreci uygulama kurallarını içeren doküman, LDA İş Tanımlama Toplantısının önemli bir çıktısıdır.

Amaçlanan lojistik destek analiz süreci çerçevesinde, ürün tasarımı seçimi, doğrulama ve kontrol ile ilişkili performans verisi konusunda, LDA İş Tanımlama Toplantısı ihtiyaç makamı/kullanıcı/idame makamı/tedarik makamı ve yüklenicinin katılımı ile icra edilmeli ve gerekli noktalara toplantı kararlarında yer verilmelidir.  

Tasarım ve desteklenebilirlik gereksinimleri için ilgili bütün önerilerin kontrol listeleriyle değerlendirilmesi sağlanmalıdır. Örneğin;

* LDA ile ilgili ürün tasarım ve performans verisinin tanımlanmış olması,
** Sözleşmesel dokümanlardan çıkarılan LDA verisi ve bilgisi (Çalışma saati başına tanımlı maksimum bakım işçiliği saati, tanımlı maksimum ortalama onarım süresi, çalışma süresi başına maksimum arıza sayısı vb.)
** Ürün kullanım verisinden çıkarılan LDA verisi ve bilgisi (Yıllık operasyon gereksinimleri, operasyon lokasyonları ve her lokasyonda görev alacak sistem sayısı, lokasyonlara göre bakım seviyeleri ve bakım personelleri vb.)
** Tasarım ve performans spesifikasyonlarından çıkarılan LDA verisi ve bilgisi (Tanımlı Arızalar Arası Ortalama Süre (MTBF) değerleri, güvenilirlik gelişimi, test edilebilirlik özellikleri vb.)
** Farklı ürün dokümanlarında geçen ilgili LDA verisi ve bilgisi (Özel çalışma ve/veya onarım kısıtları, teslimat planları, arızaların tehlike sınıfları, depolama kısıtları vb.)
** Seçilen LDA verisi ve sertifikasyon ve doğrulama veya diğer lisanslama amaçlı özel gereksinimlere konu olan bilgiler uygun şekilde not edildi mi? (Versiyon uyumluluğu vb.)

* İlgili değerlerin doğrulanması ile ilişkili kabul kuralları tanımlanması,
** Seçilen veri/bilgi için ölçülebilir hedef değerler tanımlandı mı?
** Seçilen verilere karşı ölçüm figürleri kategorize edildi mi?
** Seçilen veri/bilgi için toleranslar tanımlandı mı?
** Uygulanabilir tazmin kuralları belirlendi mi?
** Belirlenen değerler kullanıcı/tedarik makamı için kabul edilebilir midir?
** Durum bilgisiyle ilişkili kabul sonuçları tanımlandı mı?
** Uygulanabilir ceza ve ödül düzenlemeleri oluşturuldu mu?

* Aşağıdaki konuları etkileyen genel LDA stratejileri ve prensipleri kurulması,
** Tercih edilen bakım konseptinin tanımlanması
** Tedarik zinciri yönetimi destek konseptinin tanımlanması
** Onarımların bakım seviyelerine dağılımı
** Bakım seviyesi onarımları için söz konusu olabilecek sınırlamalar
** Tek kaynak prensiplerinin belirlenmesi
** Ara seviye destek konsepti uygulanabilir mi?
** Hazır alım konseptine ilişkin değerlendirme

==== <big>5.3.2.4. LDA Planı</big> ====
Raporlama, veri elemanları tanımları, veri değişim prosedürleri ve analizleri gerçekleştirmek için kullanılacak yazılım seçimleri gibi faaliyetler hakkında lojistik destek analiz süreci uygulama kurallarını içeren bu doküman, LDA İş Tanımlama Toplantısının önemli bir çıktısıdır. LDA İş Tanımlama Toplantılarında tüm paydaşların katılımı ve mutabakatı ile tasarım desteklenebilirliğini sağlayacak şekilde etkileyen ve uygun lojistik kaynaklarını tespit edilebilmesi için gerçekleştirilecek gerekli LDA faaliyetlerini belirleyen LDA planı oluşturulur.

Md.4.1.4 altında LDA Planı kapsamı genişletilerek ele alınmıştır.

=== 5.3.3. LDA İŞ TANIMLAMA TOPLANTISI ÇIKTILARI ===
LDA İş Tanımlama toplantısı sonucunda; taslak olarak toplantıya sunulan dokümanların nihai hale getirilmesi ile LDA sürecinin performansına ilişkin bağlayıcı anlaşmalar ortaya konulur.

LDA İş Tanımlama Toplantısı çıktı dokümanları aşağıda yer almaktadır:

* LDA adayları listesi
* Veri elemanları listesi
* LDA İş Tanımı
* LDAP

== 5.4. LOJİSTİK DESTEK ANALİZ FAALİYETLERİ ==
LDA ömür devrinin erken aşamalarında uygun seviyede gerçekleştirilecek ön analizlerle maliyet ilişkili kararlara destek olur. Gerekli durumlarda LDA, konsept safhasının başlangıcından itibaren tasarımı lojistik hususlara ilişkin olarak etkilemeli ve bu görev ürünün tüm ömür devri boyunca devam ettirilmelidir.

Tasarım girdileri, güvenilirlik, idame edilebilirlik, test edilebilirlik ya da planlı bakım analizi gibi farklı analiz kaynaklarından sağlanabilir. LDA adaylarına yönelik analiz faaliyetleri, analiz için harcanacak çabanın uygun bir seviyede planlanmasını sağlayacak eşik değerler tanımlanmadığı durumlarda yüksek analiz maliyetlerine yol açabilmektedir. Bu nedenle, analizler için harcanacak çaba ile analizler sonucunda elde edilecek ve yeterli seviyede destek gereksiniminlerini (kullanıcının ihtiyaçlarını ve lojistik destek maliyet kısıtlarını karşılayan) belirlemek için zorunlu olan bilgi arasındaki bir dengenin kurulması gerekir. Bu dengeyi kurabilmek ise, bir dizi ön değerlendirme yapmayı gerektirir. Bu amaçla, yapılacak analizlerle ilgili atama kriter ve kuralları yüklenici tarafından düşünülmeli ve proje ihtiyaçlarını sağlamak üzere uyarlanmış genel esaslar olarak müşteriye sunulmalıdır. Bu değerlendirmenin, hem LDA programının kendisi için harcanak çaba hem de Analiz Edilen Kalemin ömür devri boyunca ortaya çıkacak destek maliyetleri üzerinde etkisi vardır. Dolayısıyla, söz konusu faaliyetin projenin erken safhalarında bir başlangıç değerlendirmesi olarak gerçekleştirilmesi önemlidir.

Bir LDA aday kalemi için uygulanabilir analizleri belirlemekteki temel yaklaşım,  analiz için harcanan çabaya kıyasla beklenilen faydanın daha fazla olduğu değerlendirilen analizlerin yapılması şeklinde olmalıdır. Bu değerlendirmeler yapılırken, “öğrenilmiş dersler” vasıtasıyla elde edilen bilgiler hem yüklenici hem de müşteri tarafından dikkate alınmalıdır. Bu şekilde elde edilen bilgiler dikkate alındığında, bazı durumlarda ilave analiz faaliyeti gerçekleştirmeden LDA ilişkili kararların alınması mümkün olabilmektedir.

Uygulanabilir olduğu durumlarda, yeni analiz yöntemlerinin kullanımı da maliyet etkileri ile birlikte değerlendirilmelidir. Örneğin, bir simülasyonun klasik analiz yöntemlerine göre daha kapsayıcı sonuçlar üretmesi mümkündür.

=== 5.4.1. POTANSİYEL ANALİZ FAALİYETLERİ ===
Yapılacak potansiyel analiz faaliyetleri aşağıda verilmiştir, bu analizlerin sonuçları LDA veri tabanı (LDAK) üzerinde dokümante edilmelidir.

1.      Genel LDA İhtiyaçlarının Belirlenmesine Yönelik Analiz

2.      Karşılaştırmalı Analiz

3.      İnsan Faktörü Analizi

4.      Konfigürasyon Değerlendirme

5.      Güvenilirlik Analizi

6.      İdame Edilebilirlik Analizi

7.      Test Edilebilirlik Analizi

8.      Hata Türleri, Etkileri (ve Kritiklik) Analizi (FMEA/FMECA) Değerlendirmesi

9.      Hasar Analizi

10.   Özel Olay Analizi

11.   Planlı Bakım Analizi

12.   Onarım Seviyesi Analizi (OSA)

13.   Bakım Görev Analizi (BGA)

14.   Yazılım Destek Analizi

15.   Lojistik İlişkili Operasyonlar Analizi

16.   Eğitim İhtiyaçları Analizi

LDA faaliyetleri kapsamında, her bir analiz sonuçlarının nasıl dokümante edileceği, teslim edileceği ve değerlendirileceği bilgileri LDAP kapsamında ele alınır.

==== <big>5.4.1.1. Genel LDA İhtiyaçlarının Belirlenmesine Yönelik Analiz</big> ====
LDA faaliyetleri için başlangıç noktası herhangi bir görevin/analizin yapılmasına yönelik tanımlanmış ön koşullardır. Bu doğrultuda, kaynakların etkin kullanımı açısından gerçekleştirilmek istenen analizlerin amaçları/gerekçeleri açıkça tanımlanmalıdır.

Genel LDA ihtiyaçlarının belirlenmesi, daha çok sözleşmesel, müşteri ve kullanıcı isterleri ile ilgilidir. Proje için genel LDA ihtiyaçlarının uygun bir şekilde ele alınması ve müşteri ile mutabakatın sağlanması aşamasında aşağıdaki hususlar dikkate alınmalıdır:

* Oluşturulan ürün kullanım verisi (Operasyonel Gereksinimler, Müşteri Gereksinimleri), hedeflenen destek stratejisi ve ilkeleri ile alternatif destek çözümleri,
* Hangi sözleşmesel bilgilerin LDA sonuçları ile gösterilmesi ve geçerli kılınmasının gerektiği, bu geçerli kılmanın nasıl ve hangi derinlikte yapılacağı,
* Özel ilgi alanlarına ilişkin gerekli raporların (örneğin yönetim raporları, program durum gözden geçirmeleri, performans ölçme raporları, doğrulama raporları, vb.) tanımlanması,
* En iyi yatırım geri dönüşünü garanti edecek ödünleşim analiz sonuçları (Örneğin; müşteri talepleri aynı hedefe farklı yöntemlerle ulaşmanın mümkün olup olmayacağı konusunda  değerlendirilebilir. Bu değerlendirme neticesinde geliştirilecek alternatif çözümlerin önemli oranda daha az çaba ile gerçekleştirilebileceği de tespit edilebilir. Ancak dikkat edilmesi gereken müşteri gereksinimlerinin kabul edilebilir seviyede karşılanmasıdır.).

==== <big>5.4.1.2. Karşılaştırmalı Analiz</big> ====
Etkin bir LDA programının anahtarlarından biri karşılaştırmalı sistemlerden elde edilen verilerin kullanılması ve analiz edilmesidir. Tarihsel veri gözden geçirme olarak adlandırılan bu süreç, kıyaslanabilecek benzer sistemlerden/ekipmanlardan elde edilen tecrübeye dayalı bilgilerin yeni geliştirilen sistemin desteklenebilirliği ve performansını iyileştirmede kullanılmasını içerir .

Karşılaştırmalı analiz sadece özel bir istek olan durumlarda gerçekleştirilmelidir. Analizin ön koşulu bir ekipmanın, bir sistemin ya da bir son ürünün karşılaştırmalı bilgilerinin mevcut ve karar verme açısından (sadece başlangıç LDA faaliyetlerine yönelik olarak) kullanılabilir olmasıdır. Eğer karşılaştırmalı bir sistem tanımlanabilirse, kullanılabilecek karşılaştırma verilerinin elde edilebilmesi için uygun analizler yapılabilir. Analiz sonuçlarının dokümante edilmesi için karşılaştırma faktörlerini ve verilerini ve/veya karşılaştırılabilir LDA adaylarına ilişkin destek çözümlerini ele alan özel özet raporlar hazırlanabilir.

Karşılaştırmalı sistem ve alt sistemlerin belirlenmesi, yeni sistemin/ekipmanın tasarımı, operasyonel ve destek karakteristikleri ile tahmin edilecek parametreye dair bilgi sahibi olmayı gerektirir. Eğer tasarım parametreleri (ör; güvenilirlik, idame edilebilirlik) tahmin edilecekse, tasarım karakteristikleri yeni sisteme/ekipmana benzer olan operasyonel sistemler/ekipmanlar seçilmelidir. Yeni sistem için ana alt sistemler belirlendiğinde, tasarım parametrelerinin tahmini için kullanılacak ana hat karşılaştırma sistemi, birden fazla sistemin alt sistemlerinden oluşan kompozit bir sistem olabilir. Destek parametreleri (ikmal süresi, dönüş süreleri, ulaştırma süreleri, personel kısıtları vb) tahmin edileceği zaman ise, yeni sistemin/ekipmanın destek konseptine benzer mevcut sistemler (destek sistemleri) belirlenmelidir. Seçilen destek sistemi, tasarım karakteristiği açısından benzer olan sistemleri/ekipmanları destekleyen sistemlerden tamamen farklı bir destek sistemi de olabilir.

Gerçekçi bir karşılaştırmalı sistem tespit edilebilirse bu sisteme ilişkin bilgiler aşağıdaki hususların belirlenmesinde yardımcı olur:

a. Yüksek hata oranı potansiyeline sahip alt sistem ve komponentler

b. Gayri Faal Süresine etki eden temel unsurlar

c. Desteklenebilirliği geliştiren tasarım özellikleri

d. Potansiyel desteklenebilirlik problem alanları

e. Potansiyel emniyet veya insan faktörü etkileri içeren tasarım konseptleri

f. Destek kaynaklarına dair gereksinimler

g. Ürün destek gereksinimlerini, kullanım ve destek maliyetlerini ve sistemlerin erişilen göreve hazır olma seviyelerini etkileyen tasarım, operasyon ve destek konseptleri.

Bu faaliyetin ilk sonuçları, operasyonel gereksinimler ve müşteri gereksinimleri dahil desteklenebilirlik faktörlerini geliştirmek için kullanılır. İleriki safahalarda gerçekleştirilen karşılatırmalı analiz sonuçları da bu dokümanlara dahil edilir. Analiz sonuçları aynı zamanda ürün destek modeli belirlenirken girdi olarak kullanılabilir.

==== <big>5.4.1.3. İnsan Faktörü (Ergonomi)  Analizi</big> ====
Bir ürüne ilişkin potansiyel destek çözümlerinin, insan faktörü gereksinimleri dahil, belirlenmiş eşik değerlerinin içerisinde olmasını sağlayabilmek için LDA, idame edilebilirlik ve desteklenebilirlik işlevleri sıkı şekilde koordine edilmelidir. İnsan faktörlerinin özellikle operasyonel ve bakım faaliyetlerinin uygulanabilirliği konusunda belirleyici etkisi vardır.

İnsan faktörü analizleri, diğer desteklenebilirlik mühendisliği fonksiyonları gibi, bakım ekibi ve destek ekipmanı gereksinimlerinin belirlenmesi çalışmalarına kaynak veri sağlar. Bu ilişki, tasarım gözden geçirme sürecinde başlar ve bakım görev analizlerinin geliştirilmesi süreci boyunca devam eder.

İnsan faktörü analizlerinin, Bakım Görev Analizi (BGA)’ne tabi tutulan LDA adayları üzerinde etkisi olabilmektedir. İnsan faktörleri, özel sınırlamalar (örneğin, özel yetenekler gerektiren bakım görevlerinin uygulanabilirliği ile ilgili) için bir gerekçe teşkil edebilir. Bu analizler esnasında hem ergonomik hususların hem de uygun bir insan-makine ara yüzüne yönelik  tanımlanmış kuralların göz önünde bulundurulması gereklidir. LDA faaliyetleri üzerinde belirleyici etkileri olabilecek bazı hususlar aşağıda örneklendirilmiştir:

* Ağır yükleri kaldırma ve taşıma becerisi
* Özel koşullarda uzun bir süre hareket etme becerisi
* Tehlikeli malzemelerin elleçlemesi
* Personel istihdamında yasal sınırlamalar (güvenlik kısıtlamaları, vb)

İnsan faktörü analizi sonuçları, projenin mümkün olan en erken safhalarında dokümante edilmeli ve ilgili tüm dokümanlara girdi yapılmalıdır. İnsan faktörlerinin etkileri, LDA veri tabanı içerisinde farklı alanlarda yer alabilir. Tasarıma yönelik her değişiklik önerisi veya modifikasyon, bakımda da değişikliklere yol açar ve bu da insan faktörü kısıt ve sınırlamalarının gözden geçirilmesini gerektirir. Ömür devrinin sonunda, envanterden çıkarma safhasında, insan faktörleri yine kritik öneme sahip hale gelir. Zira bu safhada, insan sağlığı üzerinde etkisi olan malzemelerin ele alınması ihtiyacı doğabilmektedir.

EK-A, insan faktörü mühendisliği ile lojistik destek analizi süreci arasındaki ilişki ve entegrasyonu tanımlamaktadır.

==== <big>5.4.1.4. Konfigürasyon Değerlendirme</big> ====
Herhangi bir LDA adayı için tasarım konfigürasyonundan önemli ölçülerde sapma olması durumunda, konfigürasyon değerlendirmesi zorunludur. Ürünün geçerli kılınmasına ilişkin potansiyel değişiklikler, mühendislik değişiklikleri, sapmalar veya feragatler incelenmelidir. Konfigürasyon değerlendirmeleri, sapma gösteren bakım konsepti ve/veya lojistik destek gereksinim (personel, malzeme gibi) ihtiyacının genel değerlendirmesi şeklinde yapılmalı ve LDA adayları için analiz ihtiyaçları yeniden değerlendirilmelidir.

==== <big>5.4.1.5. Güvenilirlik Analizlerinin Değerlendirilmesi</big> ====
LDA adaylarının hedeflenen kullanım senaryoları ile ilişkili güvenilirlik tahminlerinin (örneğin MTBF), LDA çalışmaları kapsamında kullanımları değerlendirilmelidir. Güvenilirlik değerlerinin belirlenmesi tasarım ve geliştirme ile ilgili bir görevdir. Ancak bu analizlerin sonuçlarının dokümante edilmesi LDA için son derece önemlidir. Genel olarak, her bir donanım LDA adayı için güvenilirlik analizinin yapılması zorunlu kabul edilir. Buna ek olarak, güvenilirlik tahminlerinin LDA ürün kırılımında yer alan bütün gerekli elemanlara yönelik olarak genişletilmesi ve bu değerlerin bütün diğer ürün kırılımı arasında da tutarlılığının sağlanması önemlidir.

Güvenilirlik değerleri, Hata Türleri ve Etkileri Analizi (HTEA)’nin sonuçları içerisinde bir LDA adayı kalemin farklı hata türlerine ait hata oranları ile doğrudan ilişkilidir. Bu iki alan lojistik veri tabanı üzerinde tutarlı olmalıdır.

==== <big>5.4.1.6. İdame Edilebilirlik Analizi</big> ====
İdame edilebilirlik belirlenmiş prosedür ve kaynaklar kullanılarak, tanımlı bakım onarım seviyelerinde belirlenmiş yeteneğe sahip personel tarafından bakım faaliyeti gerçekleştirildiğinde, odak sistemin öngörülen performans seviyesinde tutulabilmesi veya öngörülen performans seviyesinde tekrar çalışır duruma geri getirilebilmesi kabiliyetinin ölçüsüdür.

Her bir LDA adayı için, teknik açıdan desteklenebilir olup olmadığına karar verebilmek üzere idame edilebilirlik analizinin yapılması önemlidir. Uygulanabilir olduğu durumlarda aşağıdaki konuları ele alan idame edilebilirlik analizleri gerçekleştirilmelidir:

* Müşteri gereksinimlerini yansıtan idame edilebilirlik özelliklerinin değerlendirilmesi,
* Uygulanabilir her LDA adayı kalem için bakım konseptini desteklemek amacıyla farklı seviyelerdeki bakım görevlerinin belirlenmesi,
* Farklı desteklenebilirlik açılarının araştırılması (nihai ürünün modüler tasarıma sahip olması, erişilebilirlik kolaylığı, özel bölgelerde yerleşim konsepti- MTBF değeri en kötü olan parçaların diğer parçaların arkasına gelecek şekilde yerleştirilmemesi- gibi).

Genelde, idame edilebilirlik analizi farklı detay seviyelerinde aşağıda sıralanan uygulamalarla gerçekleştirilebilir:

* Mevcut bilgilerin en düşük seviyede olduğu durumlarda, En İyi Mühendislik Kararlarının kullanılması,
* Ekipman tedarikçileri kaynaklı bilgilerin veri dönüşümü ile veya dönüşüm gerektirmeden değerlendirilmesi,
* AAK için bakım konsepti oluşturulurken; alternatiflerin kıyaslanmasında Onarım Seviyesi Analizi (OSA) ve/veya Önleyici Bakım Analizi, Planlı Bakım Analizi gibi destekleyici analizlerin dikkate alınması,
* Operasyonel profillere göre görevini gerçekleştiren ürünler için, bakım ve desteğe odaklanarak sınırlı bakım kaynakları ya da operasyonel profillerin değişmesi gibi durumların olası sonuçlarını değerlendiren simülasyon araçlarının kullanımı.

Farklı kalem tiplerine göre uygulanacak idame edilebilirlik analizinin seviyesi Tablo 5’de belirtilmiştir.



'''Tablo 5 Kalem Türüne Bağlı Olarak İdame Edilebilirlik Analizi Derinliği'''
{| class="wikitable"
|'''Analiz Edilen Kalemler'''
|'''İdame Edilebilirlik Analiz Derinliği'''
|-
|Halen karşılaştırılabilir  koşullarda kullanılmakta olan kalemler.
|Orta  seviye bilgi ve veri dönüşümü ihtiyacı vardır. Daha detaylı idame  edilebilirlik analizi isteğe bağlı olarak yapılabilir.
|-
|Halen kullanımda  olmakla birlikte, karşılaştırılabilir koşullar altında kullanılmayan kalemler.
|Dikkatli  veri dönüşümü gereklidir, yeni koşullara göre daha detaylı bir idame  edilebilirlik analizi yapılması gerekebilecektir.
|-
|Büyük modifikasyon  olmadan kullanılabilecek RAHAT kalemler.
|Lojistik özellikler  ve/veya gereksinimlere ilişkin uygunsuzlukların dokümante edilmesi ve müşteri  tarafından kabul edilmesi gereklidir.
|-
|Hazır bulunan ve minör  değişiklikler gerektiren kalemler.
|Orta  seviye bilgi ve veri dönüşümü ihtiyacı vardır, daha  detaylı idame edilebilirlik analizi isteğe bağlı olarak yapılabilir.  
|-
|Hazır bulunan ve majör  değişiklikler gerektiren kalemler.
|Dikkatli veri  dönüşümü gereklidir, yeni koşullara göre daha detaylı bir idame edilebilirlik  analizi yapılması önemlidir.
|-
|İyi bilinen bir  teknolojiye bağlı olarak yeni geliştirilen kalemler. 
|Detaylı idame  edilebilirlik analizinin yapılması gerekir.
|-
|Yeni  bir teknolojiye bağlı olarak yeni geliştirilen kalemler.
|Detaylı idame  edilebilirlik analizi mutlaka yapılmalıdır.
|}
İdame edilebilirlik analiz sonuçları dikkatli bir şekilde dokümante edilmeli ve analiz sonucunda ortaya çıkan bakım konsepti ile ilişkili veriler lojistik veri tabanına kayıt edilmelidir.

==== <big>5.4.1.7. Test Edilebilirlik Analizi</big> ====
Test edilebilirlik analizi için gerekli olan girdiler;

* İdame edilebilirlik stratejisinin tanımlanması
* Tüm test mimarisinin ve test prensiplerinin tanımlanması
* Sözleşmesel test edilebilirlik gereksinimlerinin tanımlanması ve doğrulanması
* FMEA/FMECA dokümanlarında geçen test edilebilirlik ile ilişkili bilgilerin değerlendirilmesi
* İlişkili tüm seviyelerde gereksinimlerin fonksiyonel kontrolünün tanımlanması
* İlişkili lojistik kaynak gereksinimlerinin (personel, yüklenebilir yazılım, test yazılımı gibi) tanımlanması

Test edilebilirlik analizi, idame edilebilirlik analizi ile yakından ilişkilidir. Test edilebilirlik analizi sonuçları idame edilebilirlik analizlerini doğrudan etkiler. Kalemin test özelliğine ilişkin herhangi bir düzeltici bakım, düzeltilecek hatanın fark edilebilmesine bağlıdır. Bir hata herhangi bir test prosedürüyle doğrulanamazsa, ilgili onarım görevi gerçekleştirilemez. Tüm bunlara ilave olarak, bir kalemin onarım sonrası da fonksiyonelliğinin test edilmesi gereklidir. Arıza fark etme/doğrulamanın detay seviyesi, bakım konseptini etkileyen en önemli etkendir.

Test edilebilirlik özelliklerinin tasarım tamamlandıktan sonra belirlenmesi neredeyse imkânsızdır. Bu nedenle, test edilebilirlik gereksinimleri uygulanabilir her kalem için geliştirme safhasında tanımlanmalıdır.

Cihaz İçi Test (CIT) yeteneği olan tüm kalemler için test edilebilirlik analizi zorunludur. İlişkili test edilebilirlik özellikleri tanımlanmalı ve dokümante edilmelidir. Bir şekilde tüm test mimarisinde gözlenen indirgenmiş (reduced) CIT yeteneğine sahip kalemler için (RAHAT kalemler gibi) test edilebilirlik analizinin yapılması önemlidir.

Test edilebilirlik özellikleri ile ilgili veri tipleri lojistik veri tabanında ya da test edilebilirlik raporlarında dokümante edilmelidir. Üreticiler için test edilebilirlik özelliklerinin ne şekilde uygulanacağına ilişkin kuralların tanımlanması ve doğrulanması gereklidir.

==== <big>5.4.1.8. Olaya Dayalı Bakıma İlişkin Analiz Faaliyetleri</big> ====
'''<big>5.4.1.8.1. Hata Türleri Etkileri ve Kritiklik Analizi/Hata Türleri Etkileri Analizi (HTEKA/HTEA)</big>'''

HTEKA’nın amacı, bir ürünün potansiyel hata durumlarını tanımlamaktır. Hata durumlarının kritikliğinin hesaba katılmadığı durumda, yapılan analiz faaliyeti HTEA olarak adlandırılır. Fonksiyonel hatalar sistem HTEKA’sı yapılarak tanımlanır/analiz edilir, teknik hatalar ise alt sistem HTEKA yaklaşımı ile tanımlanır/analiz edilir.

'''Sistem Hata Türleri Etkileri ve Kritiklik Analizi (HTEKA)'''

Sistem HTEKA’sı yukarıdan aşağıya yaklaşımını kullanarak, Ürünün farklı sistemlerini analiz eder. Bu amaçla, potansiyel fonksiyonel hatalar, bu hataların etkileri, kritikliği, son etkisi ve hata sebepleri belirlenir.

Emniyet, yasal ya da çevre bütünlüğünden dolayı kritik olduğu tespit edilen potansiyel hata etkilerinin önlenmesi zorunludur. Operasyonel/görev ilişkili ya da ekonomik sebeplerden dolayı istenmeyen diğer hata etkileri de önlenmelidir. Analiz sonuçları, önleyici bakım (planlı bakım) ve düzeltici bakım faaliyetlerinin tanımlanması için ya da yeniden tasarım gereksinimleri için ana çizgiyi oluşturacaktır.

'''Alt -Sistem Hata türleri Etkileri ve Kritiklik Analizi (HTEKA)'''

Alt sistem HTEKA’sı, üründe bulunan herhangi bir alt sistemde meydana gelebilecek teknik hataların olasılığını ve sonucunu tanımlayacak detayda aşağıdan yukarıya yaklaşımı ile gerçekleştirilir.

Emniyet analizi faaliyetleri (örneğin hata ağacı analizi) sistem ve alt sistem HTEKA’sına bağlıdır. Hata ağaçlarında, emniyet kritik hata kombinasyonları da tanımlanabilir. Hataların gerçekleşme olasılık seviyelerine bağlı olarak, yeniden tasarım, düzeltici bakım (onarım ya da yenisi ile değişim gibi) ve/veya önleyici (planlı) bakım gereksinimleri tanımlanmalıdır.

'''<big>5.4.1.8.2. Hasar Analizi</big>'''

Hasara elverişli bileşenler, en azından kısmi LDA adayı kalemi olarak değerlendirilmelidir. Genelde hasarlar, her bir durum için kritikliğinin ya da derecesinin önceden belirlenemeyeceği özel olaylardır. Yine de aynı yolla meydana gelebilen ya da aynı yolla tespit edilebilen hasar sınıflarının tanımlanması yararlı olacaktır. Analiz sonuçları, lojistik veri tabanında dokümante edilmelidir (örneğin yapısal elemanlar için test ve onarım prosedürlerinin veri tabanında belirtilmesi gibi). Hasarlarla ilgili güvenilirlik değerleri normalde mevcut değildir. Yalnızca, istatistiksel değerlendirmelerin yardımıyla bir tahminde bulunmak mümkün olabilir.

<big>'''5.4.1.8.3. Özel Olay Analizi'''</big>

Özel olayın bir türü olarak hasarlar dışında, başka diğer olayların da AAK’nin ya da ürünün bakım konseptine etkisi olabilir. Fonksiyonelliğini garanti etmek için özel bakım uygulamaları gerektiren, olası özel olayların tanımlanması ve dokümante edilmesi önemlidir. Ayrıca, gerekli bakım uygulamalarının ve personel, malzeme, yazılım gibi gerekli kaynaklarla ilişkili bilgilerin tanımlanmış ve dokümante edilmiş olması gereklidir.

Bakım uygulaması gerektiren bazı özel olay örnekleri;

* Sıcaklık limitlerinin aşılması
* Mekanik yükleme limitlerinin aşılması (örneğin aşırı torklama)
* İzin verilen hız limitlerinin aşılması
* Tuz yüklü atmosferde operasyonel kullanım
* Kumlu ortamda kullanım
* Yıldırım
* Uçaktan zor iniş
* Harici nesnelerle çarpışma
* Sert İniş (Hava Araçları)

==== <big>5.4.1.9. Planlı Bakım Analizi</big> ====
Planlı Bakım Analizi (Scheduled Maintenance Analysis), emniyet ilişkili, büyük ölçüde ekonomik ve ekolojik hataları önlemek için yapılır. Emniyet kritik bir durum varsa analizin yapılması zorunludur. Beklenen önemli ekonomik ya da ekolojik dezavantajlar varsa analizin tekrar yapılması gerekir. Analiz sonuçları bakım konseptini doğrudan etkiler. Planlı bakım uygulamalarının lojistik veri tabanı üzerinde mutlaka dokümante edilmesi gerekir.

==== <big>5.4.1.10. Onarım Seviyesi Analizi (OSA)</big> ====
Genel destek stratejisine bağlı olarak, her bir kalem için bakım ve/veya onarımının hangi seviyede yapılacağına karar verilmesi gereklidir. Bu kararı desteklemek için analiz edilecek LDA adayı kalemin tipine bağlı olarak birkaç yöntemden birisi uygulanarak OSA gerçekleştirilir.

'''Tablo 6 OSA’nın Farklı Derinliklerinin Sınıflandırılması'''
{| class="wikitable"
|'''OSA Sınıflandırması'''
|'''Tanım'''
|-
|Basitleştirilmiş OSA 
|Mevcut en iyi bilgiler  göz önünde bulundurularak en iyi mühendislik yaklaşımının temellerinden elde  edilebilir. Sonuçların mutlaka dokümante edilmesi gerekir. 
|-
|Tam OSA 
|Bu kapsamlı analizin  yapılabilmesi için kalemin kendisiyle ve kullanım içeriği ile ilişkili olarak  gerekli tüm verinin (örneğin; operasyonel senaryolar, yedek parça tedariki,  maliyet gibi) olması gereklidir.
|-
|Simülasyon Üzerinden Analiz
|AAK bu kalemin intikal ve operasyonel senaryoları ile ilgili  oldukça detaylı bilgileri hesaba katan bir simülasyon en iyi OSA sonuçlarını  oluşturabilir. Bu durum simülasyon için yazılım paketinde kullanılacak uygun  formattaki tam bir bilgi/veri setini gerektirir. Bu bilgi/veri setini  hazırlamak ilave çabaya sebep olabileceğinden bu durumun da ayrıca değerlendirilmesi  gerekecektir.
|}
Her durumda, uygulanabilir olduğu ölçüde OSA yapılması zorunlu bir analizdir.

==== <big>5.4.1.11. Bakım Görev Analizi (BGA)</big> ====
Bakım Görev Analizi, LDA sürecindeki merkezi analiz faaliyetlerinden birisidir. Burada, tanımlanmış bakım görevleri (hem planlı hem plansız) mevcut olan gerekli tüm bilgilerle aşağıdaki gibi detaylandırılır.

* İlgili bakım görevinin yerine getirilebilmesi, eğitim gereksinimleri ve kritik görevler için ön koşulların ne olduğu gibi genel görev bilgilerinin dokümante edilmesi,
* Bakım görevlerinin tanımlı olaylara (arızalar, hasarlar, özel olaylar, zaman kısıtlamaları gibi) atanması,
* İlgili lojistik kaynak gereksinimlerinin (personel, destek ekipmanı, yedek parçalar, alt yapı, yazılım gibi) tanımlanması,
* Görev sıklığının hesaplanması,
* Tanımlanmış görevden önce ve sonra yapılması gerekli olan görevler.

==== <big>5.4.1.12. Yazılım Destek Analizi</big> ====
Kullanıcı tarafından yüklenebilir veri/yazılım içeren her bir kalem aşağıdaki hususlar kapsamında analiz edilmelidir. Bu analiz, bakım ve hizmet görevlerini kapsar.

* Kullanıcı tarafından yüklenebilir yazılım/veri içeren donanım bakımı
* Kullanım hazırlığı için gereken veri ve/veya operasyonel yazılım
* Kullanıcı tarafından yüklenebilir yazılım sürümleri ile birlikte kalemin/birimin revizyonunun güncellenmesi için verilecek yazılım desteği

Yazılım Destek Analiz programı yazılım değişikliklerini, sürümleri ve yazılımda bir virüs (bug) olması durumunda yazılımın bakımını yönetecekse, oluşturulacak süreç donanım için olan LDA süreci ile aynı çizgide olmalıdır.

==== <big>5.4.1.13. Lojistik İlişkili Operasyonlar Analizi</big> ====
Bir ürünün kullanımı ve bakımına ilişkin görevlerin yanısıra, operasyon açısından dikkate alınması gereken bazı ilave hususlar vardır. Bazı durumlarda doğrudan ürünün kullanımıyla veya bakımıyla ilişkilendirilemeyen görevler söz konusu olabilir. Ancak bu görevler, operasyon ve bakım tesislerinde normal operasyonlara destek olarak yürütülür (ör; paketleme, elleçleme, depolama, ulaştırma, demirleme gibi).

Bu görevler ürünün doğru kullanımı açısından son derece önemlidir. Lojistik ilişkili operasyonel görevler olarak nitelendirilebilecek bu görevler, operasyonları çeşitli açılardan kısıtlayabilirler (kullanım kolaylığı, kullanılabilirlik, kullanım esnekliği, mobilite gibi). Bu doğrultuda Analiz Altındaki Sistemin (AAS) genel kullanımı için önemli olan görevlerin tanımlanabilmesi amacıyla operasyonel gereksinimler analiz edilmelidir ve bu görevler lojistik veri tabanında dokümante edilmelidir.

==== <big>5.4.1.14. Eğitim İhtiyaçları Analizi (EİA)</big> ====
Bu analiz kapsamında, belirli bir görevin özel bir eğitim gerektirip gerektirmediğine karar verilir. Eğitim gerekli ise, eğitimin etkili bir şekilde nasıl uygulanabileceği belirlenmelidir. Bu süreç, belirlenen görevlere ilişkin LDA veri tabanında yer alan içerikten faydalanarak desteklenebilir.

Eğitim gereksinimlerine yönelik kriterler LDA İş Tanımlama Toplantısı esnasında Yüklenici ve Müşteri arasında görüşülmeli ve uyumlu hale getirilmelidir. Belirlenen kriterler LDA veri tabanına aktarılmalı ve her bir görev bu kriterlere göre değerlendirilmelidir. Elde edilen sonuç, LDA veri tabanında yer alan görevlere dair mevcut verilere dayalı bir ön Eğitim İhtiyaçları Analizi kararı olabilir.

==== <big>5.4.1.15. Envanterden Çıkarma Analizi</big> ====
Bir sistemin faydalı ömrü sona erdiğinde, emniyet (patlayıcı emniyeti dahil), güvenlik ve çevreye dair hukuki ve düzenleyici gereksinimlere uygun olarak envanterden çıkarılması gerekir. Tasarım süreci boyunca, sistemde yer alan tehlikeli maddeler dokümante edilmeli ve sistemin emniyetli bir şekilde bertaraf edilmesi planlanmalıdır.

Bu analizlerin amacı sistem/birim ve ilişkili tesis ekipmanları için envanterden çıkarma prosedürlerinin belirlenmesidir. Bu amaçla, komponent, komple, tali komple, parça ve malzemelerden tehlikeli madde, atık ve çevre kirletici madde içerebilecek olanlar ile yeniden işlenebilecek, yeniden kullanılabilecek veya kurtarılabilecek malzemeler belirlenir.

Malzemelerin envanterden çıkarma prosedürlerinin belirlenmesi ve dokümante edilmesi gerekir. Bu faaliyetin gerçekleştirilmemesi, ürün işletimi ve idamesinde görev yapan personelin sağlık ve emniyetini etkileyebilir. Ekipman veya komponentlerin demilitarize edilmesi, ulusal güvenlik açısından önemli bir konu olup gizli verilerin tehlikeye atılmasının önlenmesi gerekir.

Komponent, komple, tali komple, parça ve malzemelerin envanterden çıkarılmasına yönelik detaylı prosedürlerin oluşturulmasından yüklenici, bütün olarak sistem/ekipmanın envanterden çıkarılması/demilitarize edilmesinden ise ihtiyaç makamı/kullanıcı/idame makamı sorumludur.

== 5.5. MÜŞTERİNİN LDA PROGRAMINA KATILIMI ==
LDA sürecine dair yüklenici’nin yorum ve yaklaşımının müşterininkiyle aynı doğrultuda olduğunu garanti altına almak için müşteri tüm LDA programı boyunca uygun derinlikte sürece dahil olmalıdır.

=== 5.5.1. MÜŞTERİNİN ADAY KALEMLERİ DEĞERLENDİRMESİ VE TAVSİYE EDİLEN ANALİZ AKTİVİTELERİ ===
LDA adaylarının seçimi ve bu aday kalemlere uygun analiz aktivitelerinin atanması, LDA sürecinde maliyeti önemli ölçüde etkileyen husustur. Bu sebeple, LDA adaylarının seçimi projenin erken aşamalarında büyük bir özenle yapılmalıdır. Riski azaltmak için, uygulanabilir olması durumunda sözleşmenin imzalanmasından önce taslak aday kalem listesi hazırlanmalıdır.

==== <big>5.5.1.1. LDA Süreci Değerlendirme Kurallarının Konulması</big> ====

==== Değerlendirme kuralları yüklenici ve müşterinin ortak kararı ile belirlenmelidir. Değerlendirme kurallarının belirlenmesi için en az aşağıdakileri içerecek şekilde bazı genel kurallar koyulmalıdır: ====
Yalnızca LDA GGT’de anlaşılan kuralları içeren hususlar veya müşteri ile yüklenici arasında anlaşılan gelecek LDA süreci içerisindeki (ör. LDA gözden geçirmeleri) kurallar dikkate alınmalıdır.

Eğer bir değerlendirme gerçekleştirilmiş ve başarılı olarak sonuçlanmışsa, doğrudan ilgili yeni bir husus olmadığında aynı konu tekrar değerlendirilmemelidir.

* Yalnızca LDA ile ilişkili kurallar değerlendirmeye alınmalıdır.
* Diğer hususlar (ör. teknik dokümantasyon, ikmal desteği, eğitim vb.) LDA değerlendirme kuralları kapsamına alınmamalıdır.
* Müşteri veya yüklenici kadrosunda oluşan bir değişiklik daha önce karar alınmış değerlendirmeleri etkilememelidir.
* LDA teslimatlarının yayımlanması ile bu teslimatlara verilecek görüşler için cevapların oluşturulması süreleri arasında geçecek zaman için sınır kuralları koyulmalıdır.
* Yüklenicinin LDA teslimatlarının içerisindeki detay değerlendirme daveti ve değerlendirme sonuçları uygun kodlar kullanılarak bir durum kodu ile belirtilmelidir.
* Bilgilerin detayları, yapısı ve  kullanılacak kodlar müşteriyle de koordine edilmek suretiyle yüklenicinin sorumluluğunda olmalıdır.
* LDA gözden geçirme yapısı durum kodu tarafından temsil edilen bilgi grubu doğrultusunda organize edilmelidir.
* Durum kodu için lojistik veri tabanı içerisinde uygun veri elemanı tanımlanmalıdır.
* Her LDA adayını ilgilendiren durum kodu lojistik veri tabanında uygulanabilir olarak güncel tutulmalıdır.

Değerlendirme sonuçları dokümante edilmeli ve belirlenmiş değerlendirme prosedürüne uygun olarak yükleniciye gönderilmeli ve tüm konular açıklığa kavuşana kadar takip edilmelidir.

Ürün kırılımının özellikle yapısı, içeriği ve derinliğinin uygunluğu, LDA aday kalem seçim kriterlerinin net bir şekilde tanımlanmış olması ve bu kalemler için yapılacak analiz faaliyetlerinin seçim kriterlerinin uygunluğu müşteri tarafından ilk değerlendirme kapsamında değerlendirilmeli ve görüşler yükleniciye iletilmelidir. Bu aşamadan sonra yapılacak değerlendirmeler, yüklenici tarafından yapılan her bir teslimat kapsamında olacaktır. Proje LDA programına göre uyarlanarak yüklenici tarafından hazırlanan dokümanların nasıl iletileceği, görüşlerin/yorumların nasıl hazırlanacağı, ilgili görüş/yorumların değerlendirme süreci, üzerinde mutabakatın sağlanması gibi tüm aşamaları içeren değerlendirme süreci (yorum verme süreci de içeren) dokümante edilmeli ve LDAP kapsamında tanımlanan sürece uygun olarak tanımlanmalıdır. Müşteri, LDA sürecinde ilerleme sağlayabilmek için yaptığı değerlendirmeleri, özellikle mutabık kalınan/kalınmayan noktaları ve mutabık kalınmayan hususlarda açıklamalarını yükleniciye resmi olarak aktarmalıdır. Tüm LDA çıktıları konfigürasyon yönetim ilkelerine göre kayıt altına alınmalıdır. Ayrıca, müşteri tarafından verilen görüş/yorumlar, bunlara oluşturulan cevaplar ve son durumun da kayıt altına alınması izlenebilirlik açısından gereklidir.

Şekil 7’de müşteri ve yüklenici arasındaki bilgi alışverişi için örnek bir süreç gösterilmiştir. Tablo 7’de ise zaman aralıkları hakkında açıklamalar verilmiştir. 
[[Dosya:TSSODYP06.07.jpg|alt=|sol|küçükresim|645x645pik|Şekil 7 Müşteri İle Yüklenici Arasındaki Veri Alışverişi Süreci (Örnek)]]
































'''Tablo 7 Yorumlama Sürecinin ZamanTakvimi ile Açıklanması'''
{| class="wikitable"
|'''Zaman'''
|'''Eylemler'''
|-
|Sözleşme T0+…
|Yüklenici tarafından  LDA teslimat kalemlerinin hazırlanmasına başlanması. 
|-
|T1
|Sözleşmesel LDA  teslimat kalemlerinin müşteriye anlaşılan formatta teslim edilmesi
|-
|T2
|T2 ve T1 arasında  müşterinin teslim edilen kalemler üzerinde (LDA verisi, LDA raporları) yorum  verme süreci gerçekleşecektir. T2 için anlaşılan zamanda yorumların  yükleniciye iletilmesi gerçekleşecektir.
|-
|T3
|LDA gözden geçirme  eforunun azaltılması için, kolayca cevaplanacak her tipte yorumlar LDA gözden  geçirme öncesinde eğer mümkünse yüklenici tarafından ele alınmalıdır. Bununla  beraber, müşterinin yorumlarıyla ilgili her karar dikkatlice dokümante  edilmelidir.

Bu süreçte, birden  fazla soru-cevap döngüsü özel soruları detaylıca açıklayabilir, fakat döngü  sayısı, daha fazla kapsamlı soruların netleştirilmesi gerektiğinden  sınırlandırılmalıdır. (ör. LDA gözden geçirmesinde veya yüklenici ve müşteri  arasındaki daha uzun netleştirme süreci)
|-
|T4
|T2 ve T4 arasındaki zamanda,  müşteri ve yüklenici arasındaki netleştirme döngülerini dikkate alarak, kalan  müşteri yorumları yükleniciye teslim edilecektir. Bu yorumlar LDA gözden  geçirmesindeki netleştirme ve tartışmalar için temel oluşturacaktır.
|-
|T<sub>Gözden Geçirme</sub>
|LDA gözden geçirme  zamanı. LDA gözden geçirmesindeki her kararın karşılık gelen durum bilgisi  güncellemesi ile birlikte dokümante edildiğinden emin olunmalıdır.
|}
Müşteri ile gerçekleştirilecek analiz verilerinin değişimi hususunda uygulanması gereken adımlar LDAP kapsamında ele alınacaktır:

* Veri ve doküman değişimi için uygun kuralların koyulması (bkz: 5.5.1.2)
* Yüklenici tarafından LDA veri ve dokümanların toplanması (bkz: 5.5.1.3)
* Yüklenici tarafından LDA veri/dokümanlarının teslimatı (bkz: 5.5.1.4)
* Müşteri değerlendirmesi ve değerlendirme sonuçlarının dağıtımı (bkz: 5.5.1.5)
* Yüklenici tarafından müşteri cevaplarının dağıtımı (bkz: 5.5.1.6)
* Anlaşılmayan yorumlarla ilişkili yüklenici cevaplarının dağıtılması (bkz: 5.5.1.7)

==== <big>5.5.1.2. Veri ve doküman değişimi için uygun kuralların koyulması</big> ====
Uygun anlaşmalar ve kurallar LDA GGT’de ve devamındaki LDA anlaşmalarında müşteri ile yüklenici arasında dokümante edilip üzerinde anlaşılmalıdır. Örneğin:

* Kullanılan yazılımlar,
* Veri ve rapor formatları (ör. Dex-formatı),
* Periyodiklik,
* Teslimat ve cevap süreleri,
* Dağıtım paydaşları ve uyulması gereken akış.

==== <big>5.5.1.3. Yüklenici tarafından LDA veri ve dokümanlarının toplanması</big> ====
Müşteri ve yüklenicinin arasında yapılan LDA GGT ve sonrasında yapılan LDA anlaşmaları mutabakatla dokümante edilmelidir. Bu dokümantasyon en az aşağıdaki hususları içermelidir:

* Uygun veri/doküman değişiminin ve endüstri içindeki veri/doküman paylaşım ağının kurulması,
* İş ilişkisinde bulunulan firmalar ve LDA ile ilişkili disiplinler arasında istenen teslimatlar için veri/dokümanların toplanması,
* Endüstri içi kalite kontroller, harmonizasyon ve teslimat anlaşması performansları.

==== <big>5.5.1.4. Yüklenici tarafından LDA veri/dokümanlarının teslimatı</big> ====
Müşteri ve yüklenicinin arasında yapılan LDA GGT ve sonrasında yapılan LDA anlaşmaları üzerinde anlaşılarak dokümante edilmelidir. Bu dokümantasyon en az aşağıdaki hususları içermelidir:

* LDA teslimlerinin son teslim tarihini içerecek şekilde (uygulanabilir olduğu durumda) üzerinde anlaşılan dağıtım kurallarının dikkate alınarak dağıtılması,
* Yüklenici iç dokümantasyonu ve resmi LDA teslimatlarının dağıtımı.

==== <big>5.5.1.5. Müşteri değerlendirmesi ve değerlendirme sonuçlarının dağıtımı</big> ====
Müşteri ve yüklenicinin arasında yapılan LDA GGT ve sonrasında yapılan LDA anlaşmaları üzerinde anlaşılarak dokümante edilmelidir. Bu dokümantasyon en az aşağıdaki hususları içermelidir:

* Yüklenicinin LDA teslimatının gerektiği gibi dağıtılması,
* Resmi müşteri yanıtlarına verilen tüm cevapların uyumlandırılması,
* Müşteri yanıtının yükleniciye dağıtımı.

==== <big>5.5.1.6. Yüklenici tarafından müşteri cevaplarının dağıtımı</big> ====
Müşteri ve yüklenicinin arasında LDA GGT ve sonrasında yapılan LDA anlaşmaları üzerinde anlaşılarak dokümante edilmelidir. Bu dokümantasyon en az aşağıdaki hususları içermelidir:

* Resmi müşteri cevaplarının kaydı,
* Endüstri iç dağıtımı,
* Yüklenici araştırma sonuçlarının tanımlanması, dağıtılması ve uyumlandırılması,
* Müşteri yanıt detaylarına göre (uygun olabildiğince) LDA veri tabanının güncellenmesi,
* Genel yorum ve anlaşmazlıklara yüklenici cevabının uyumlandırılarak hazırlanması.

==== <big>5.5.1.7. Anlaşılmayan yorumlarla ilişkili yüklenici cevaplarının dağıtılması</big> ====
Yükleniciden gelen tekrarlı analiz verileriyle ilgili adımlar 5.5.1.4’te verilmiştir.

== 5.6. LDA İŞ TANIMLAMA GÖZDEN GEÇİRME TOPLANTISI ==
Yüklenici ve müşterinin katılımıyla aşağıdaki hususları gerçekleştirmek için bir LDA İş Tanımlama Gözden Geçirme Toplantısı (LDA İş Tanımlama GGT) planlanmalıdır:

* Açıkta kalan konularla ilgili bir karara ulaşarak mutabakatın sağlamak,
* Müşterinin açıkta kalan konularla ilgili onayına ulaşmak,
* LDA aday kalemlerinin durumunu izlemek, (ör. tamamlanması ve kalitesi),
* Sürecin tüm fazlarıyla ilişkili lojistik desteği değerlendirmek,
* LDA sürecini geliştirmek için müşteri ve yüklenici arasındaki ek anlaşmalara ulaşmak.

=== 5.6.1. LDA GÖZDEN GEÇİRME SÜRECİ ===
LDA GGT, LDA aday kalem seviyesinde gerçekleştirilmelidir. Toplantıdan önce, yüklenici müşteriyi üzerinde konuşulacak LDA adayları ile ilgili bilgilendirmelidir.

LDA GGT’de LDA teslimatları ve ilişkili veri elemanları değerlendirilmeli ve belirlenmiş olan kabul kriteri gözetilerek kararlar alınmalıdır. Alınan her karar raporlanmalıdır.

Karmaşık LDA aday kalemleri uzun zamana yayılan projelerin farklı aşamaları içinde ulaşılabilir tipte bilgiye bağlı olarak bir dizi analiz aktivitesi gerektirebilir. Diğer yandan, bazı kararlar projenin en erken aşamalarında var olan kısıtlı bilgiye dayanarak alınmalıdır (ör. Ön bakım konseptinin belirlenmesi) Bazı kararlar ise projenin oldukça ileri bir aşamasına kadar belirli olmayan netleşmiş bir tasarım gerektirir (ör. Planlı bakım görevlerinin zaman açısından belirlenmesi vb.). Bu sebeple, birden fazla gözden geçirme gerçekleştirilebilir. Her LDA GGT’si değerlendirmesi istenen ve durum kodlarıyla gösterilen LDA adaylarına ait tüm adımları içermelidir.

LDA sürecinin yinelemeli doğasından ötürü, LDA GGT’si esnasındaki herhangi bir onay geçici değerlendirme olarak alınmalı fakat yüklenicinin LDA sürecine devam etmesine de izin vermelidir.  LDA sürecinin doğası gereği, tasarım değişikliklerinden, teknik verilerin güncellenmesinden ve/veya destek ve operasyonel çevreden ötürü veriler tekrar gözden geçirilmelidir.

Nihai sonuçlar LDA dokümanlarında ve/veya veri tabanlarında dokümante edilmelidir ve her proje fazında dondurulmuş olarak düşünülmelidir. Buna ilişkin kabul kararları üzerinde LDA GGT’de anlaşılmalıdır.

LDA GGT’leri değişen tasarım ve analiz faaliyetleriyle paralel olarak gerçekleştirilmelidir. Bu toplantılar üzerinde anlaşılan periyotlarda veya değerlendirilecek bilgiye dayalı olarak düzenli olarak gerçekleştirilmelidir. Toplantı notları müşteri ve yüklenicinin gerçekleştireceği eylemleri içerek şekilde hazırlanmalıdır.

=== 5.6.2. GÖZDEN GEÇİRME KONUSU ===
Bir LDA GGT’sinde veya sonrasındaki anlaşmalarda müşteri ve yüklenici arasındaki sözleşmesel tüm kalemler LDA GGT’sinde gözden geçirilmelidir. LDA süreci için gerekli olarak tanımlanan ve belirlenmiş olan LDA programıyla ara yüzü olan diğer lojistik süreçleri etkileyebilecek her şey gözden geçirmenin konusudur.

LDA ile ilişkili analizlere ilişkin prosedür ve prensiplere giriş, analizlerin amaçları hakkında ortak bir anlayışa ulaşmak, ilgili kısıtlamalar ve LDA sonuçlarını değerlendirmek için yüklenici tarafından müşteriye sunulmalıdır.

Müşterinin özel olarak ilgilendiği kalemleri yansıtan raporların yanında ilerleme raporları ve veri kalite raporları da yüklenici tarafından sağlanmalıdır. Aşağıda bazı örnekler verilmiştir:

* Çalışma saati başına ortalama adam-saat gibi idame edilebilirlik değerleri,
* Belirlenmiş limitler içerisinde gerçekleşecek idame edilebilirlik görevleri için Ortalama Geçen Zaman gibi lojistik performans parametreleri.

=== 5.6.3. GÖZDEN GEÇİRME YAPISINA ÖRNEKLER ===
LDA gözden geçirme süreci içerisindeki adımlar bir projenin LDA verilerinin yayımlanması ve onaylanması için aşağıdaki şekilde düzenlenebilir:

* LDA gözden geçirme basamağı- 1. Aday Kalem listesi ve bakım analiz ataması (bkz: 5.6.3.1),
* LDA gözden geçirme basamağı- 2. Onarım seviyesi analizi ve bakım konsepti bilgisi (bkz: 5.6.3.2),
* LDA gözden geçirme basamağı-3. HTEA ve Planlı Bakım Analizi sonuçları (bkz: 5.6.3.3),
* LDA gözden geçirme basamağı-4. Bakım Görev Analizi (bkz: 5.6.3.4).

==== <big>5.6.3.1. Aday Kalem Listesi ve Bakım Analizi Ataması</big> ====
Bu basamak, sonrasında gelen LDA veri tabanı içerisinde dokümante edilen tüm LDA aktivitelerinin temelini oluşturmaktadır. Aşağıdakileri içerir:

* LDA aday kalemlerinin uygulanabilir olduğu durumda gruplanarak seçimi,
* Aday tipinin ve ilgili özelliklerinin (HDB’lerin tanımlanması, potansiyel maliyetler, potansiyel bakımlar, potansiyel kullanıma hazır olma) tanımlanması,
* Seçilmiş her aday için gerçekleştirilecek LDA ilişkili analiz aktivitelerinin atanması
* Detayları gösteren durum kodu,
* Aday kalem seviyesindeki her tasarım konfigürasyonundaki değişikliklerin LDA veri tabanında yönetilmesi.

==== <big>5.6.3.2. Onarım Seviyesi Analizi ve Bakım Konsepti Bilgisi</big> ====
Bu basamakta, bakım görevleri ilgili bakım seviyelerine atanarak ön bakım konsepti hazırlanır. Tipik olarak aşağıdakileri içerir:

* Yüklenici tarafından önerilen bakım konsepti,
* Ürüne ekipman entegrasyonu ile ilişkili bakım görevlerinin tanımlanması (ekipman çıkarılması ve yüklenmesi, ekipman ve sistem seviyesinde fonksiyonel testlerin performansı vb.),
* Önerilen bakım konseptinin doğrulanması,
* Red veya alternatif çözüm olabilecek bakım konsepti üzerindeki müşteri kararı.

==== <big>5.6.3.3. HTEA ve Planlı Bakım Analizi sonuçları</big> ====
Bu basamakta, bakım konsepti planlanmamış bakım görevlerinin HTEA ile belirlenmesiyle son haline getirilir. Planlı Bakım Analizi sonuçları ise planlı bakım görevlerini belirler.

==== <big>5.6.3.4. Bakım Görev Analizi</big>  ====
Bu basamakta, belirlenmiş bakım görevleri, gereksinimlere ve uygulanmasına göre analiz edilir.

* Uygulanabilir derinlik ve ölçüde gerekli bakım görevlerinin tanımı
* Her görev adımının süresi
* Bakım aktivitelerini destekleyecek ilgili lojistik kaynakların tanımlanması (ör. Personel, destek ekipmanı, yedek parça, veri ve yazılım, sarf malzeme, tesisler)

==== <big>5.6.4. DURUM KODU ÖRNEKLERİ</big> ====
Durum kodları aşağıdaki ifadeleri yansıtacak şekilde düzenlenir:

* Dahil olan firmaların sorumlulukları; her görev grubu için görevli firma belirlenmelidir. Bu aynı zamanda üzerinde anlaşılan iş dağılımının detaylarını da yansıtır.
* LDA adayının tipi (tam aday, kısmi aday vb.)
* Önemli konular (kullanıcı tarafından yüklenebilir yazılım, veri vb.)
* Gözden geçirme aşaması göstergesi

Tablo 8, potansiyel kodlar ve karşılık gelen anlamları için örnek vermektedir. (Her LDA adayı için gözden geçirme aşaması göstergesi olarak)

'''Tablo 8 Durum Kodu Örnekleri'''
{| class="wikitable"
|'''Kod'''
|'''Tanım'''
|-
|X
|“Çalışır durumda”,  değerlendirme istenmiyor
|-
|N
|İlgili LDA adayı için  uygulanabilir değil
|-
|R
|Değerlendirme istendi  ve Sıradaki LDA GGT’sinde karar verilecek
|-
|A
|Gösterge üzerinde müşteriyle  geçici olarak anlaşıldı
|-
|B
|Müşteriyle geçici  olarak anlaşıldı ancak son kabul için küçük bir çalışma gerektiriyor
|-
|O
|Müşteriyle üzerinde  anlaşılamadı ve açık konu olarak kaldı.
|}

=== 5.6.5. DURUM KODU ATAMASININ DERİNLİĞİ ===
Her LDA adayı için minimum bir gereksinim olarak ilgili durum kodları atanmalıdır. Ayrıca, değerlendirme konusu detaylı bir şekilde adreslenebilir. (modifiye edilen bir LDA adayının değerlendirme ihtiyacı vb.) Bu karar LDA GGT’da alınmalıdır.

=== 5.6.6. DURUM KODLARININ İŞLEVİ ===
Durum kodları, gözden geçirme sürecinin yapısını yansıtır ve LDA veri tabanı içerisinde dokümante edilmesi gereken tüm sözleşmesel konuları adresler. LDA veri tabanı içeriğiyle ilgili tüm durum özeti raporları için kullanılabilir. (örneğin her LDA GGK sonrası LDA alanındaki gelişmelerin yansıtılması.)

Durum kodu tarafından filtrelenen bir LDA aday kalem listesi, müşterinin dikkatini özel bir konuya çekmek için kullanılabilir.

Durum kodu ayrıca ELD elemanlarına ilişkin ürünleri yaratırken karşılaşılabilecek riskler dikkate alınarak dur ya da devam et durumunu belirtmek için de kullanılabilir.

=== 5.6.7. LDA GGT’SİNDE DURUM KODUNUN TANIMLANMASI ===
Gözden geçirme aşamaları, ilgili durum kod yapısı ve uygulanabilir durum kodları yüklenici tarafından önerilip LDA GGT’sinde derinlik ve detay seviyesi ile beraber müşteri tarafından da onaylanmalıdır. 

= 6. TASARIMA ETKİ/TASARIM ETKİLEŞİMİ =
LDA’nın temel amaçları, tasarımı etkilemek, en etkin destek konseptini oluşturmak ve lojistik kaynak gereksinimlerini tanımlamaktır. Bu bölümde bu amaçlar içerisinden özellikle ürün tasarımına etki üzerinde durulmuştur.

LDA gereksinimlerini karşılamak ve ÖDM azaltabilmek amacıyla tasarıma etki edebilme fırsatı projenin geliştirme safhasında en yüksek düzeydedir. Erken dönemde gerçekleştirilecek tasarıma etki, ileriki safhalarda ürünü kullanıma ve desteğe uygun hale getirme amaçlı tasarım değişikliği ihtiyaçlarını azaltabilir veya tamamen ortadan kaldırabilir. Tasarımın etkilenmesi, proje dönemi boyunca gerçekleştirilecek gözden geçirmeler ve ana hatlar ile yapılandırılmış bir şekilde gerçekleştirilir. Tasarımda (yazılım veya donanım) rol alan kişiler açısından bu faaliyet tasarım programı ile LDA programı arasında etkileşim sağlanması açısından önemlidir.

== 6.1. LDA’DAN ETKİLENEN VE KARŞILIKLI OLARAK LDA’YI ETKİLEYEN TASARIM PARAMETRELERİ ==

* LDA’nın tasarıma etki edebilmesi için nasıl bir strateji geliştirilmesi gerektiği ve bunun sağlayacağı faydalar,
* Tedarikçi bakış açısı,
* Kilometre taşlarındaki gözden geçirmeler.

== 6.2. LDA TARAFINDAN ETKİLENEBİLECEK VE LDA FAALİYETLERİNİ ETKİLEYEBİLECEK TASARIM PARAMETRELERİ ==
Bir ürünü daha verimli ve maliyet açısından daha etkin hale getirmek üzere sistem/altsistem veya ekipman tasarımını etkilemede kullanılabilecek birçok özellik vardır. Bu özelliklerden başlıcaları aşağıda sıralanmış ve ilerleyen bölümlerde açıklamalar verilmiştir.

* Kullanıma hazır olma,
* Güvenilirlik,
* İdame edilebilirlik,
* Test edilebilirlik,
* Prognostik,
* Standartlaştırma,
* Değiştirilebilirlik
* Çevresel hususlar,
* İnsan faktörü/ergonomi,
* Demodelik,
* Desteklenebilirlik,
* Maliyet etkinlik,
* Yazılım tasarımı.

=== 6.2.1. KULLANIMA HAZIR OLMA ===
Bir ürünün kullanıma hazır olması, ürürün bilinmeyen bir zamanda görev veya operasyon ihtiyacı doğduğunda söz konusu görev veya operasyonun başlangıç anında faal ve kullanıma uygun olma durumunun bir ölçüsüdür.

Güvenilirlik, idame edilebilirlik ve desteklenebilirlik ürünün kullanıma hazır olmasına etki eden faktörlerdir (Şekil 8).
[[Dosya:Şekil8 Kullanıma Hazır Olma Kırılımı.jpg|alt=|sol|küçükresim|583x583pik|Şekil 8 Kullanıma Hazır Olma Kırılımı]]























Bir sistemin Tasarımsal Kullanıma Hazır Olma ölçüsü (Inherent Availability), ürünün güvenilirlik ve idame edilebilirliği tarafından belirlenir ve sistemin zaman içinde herhangi bir anda, tanımlı kullanım koşulları altında ve ideal destek ortamında (destek kaynaklarında herhangi bir zafiyet olmadığı durumda) yeterli düzeyde çalışacağı olasılık olarak tanımlanır. Önleyici bakım ve gecikme zamanlarını kapsamaz.
[[Dosya:Tasarımsal Kullanıma Hazır Olma.jpg|sol|küçükresim]]









A<sub>İ</sub>= Tasarımsal Kullanıma Hazır Olma

MTBF = Arızalar Arası Ortalama Süre

MTTR = Ortalama Onarım Süresi


Ulaşılabilir Kullanıma Hazır Olma (Achived Availability) ise tasarımsal kullanıma hazır olmaya benzemekle birlikte kapsamında önleyici bakım faaliyetlerini de bulundurur ve aşağıdaki şekilde ifade edilir:
[[Dosya:Ulaşılabilir Kullanıma Hazır Olma .jpg|sol|küçükresim]]









A<sub>a</sub> = Ulaşılabilir Kullanıma Hazır Olma

MTBM = Bakımlar Arasındaki Ortalama Süre

M= Ortalama Aktif Bakım İşlem Süresi


Operasyonel Kullanıma Hazır Olma (Operational Availability) ise ürün ve destek sisteminin birleşimi ile ortaya çıkar. Bir sistemin tanımlı kullanım koşullarında, ideal olmayan gerçek destek ortamında ihtiyaç duyulduğunda yeterli düzeyde çalışma olasılığı olarak tanılanır ve aşağıdaki şekilde ifade edilir:
[[Dosya:Operasyonel Kullanıma Hazır Olma .jpg|sol|küçükresim]]









A<sub>O</sub>= Operasyonel Kullanıma Hazır Olma

MTBM = Bakımlar Arasındaki Ortalama Süre

MDT = Bakım İçin Sistemin Servis Dışı Kaldığı Ortalama Süre

=== 6.2.2. GÜVENİLİRLİK ===
Güvenilirlik, bir sistemin destek kaynaklarına etki eden birincil faktördür. Ürünün belirli koşullar altında hatasız performans gösterme süresi veya belirli koşullar altında belirli bir süre kendisinden beklenen işlevini yerine getirme olasılığı ile ilişkilidir. Güvenilirlik kullanıma hazır olma değeri ile doğrudan ilişkilidir.

Yüksek güvenilirlikli ürünler genellikle maliyet etkindir. Ancak, düşük güvenilirlikli ürün kullanımından kaçınmanın mümkün olmadığı durumlarda, ürün tasarımı bu durumu hatanın yerinin kolay belirlenmesinin ve bakım faaliyetlerinin kolay olmasını sağlayarak dengelemelidir. Bunun için sistem tasarımının erken aşamasında güvenilirliğin bir tasarım parametresi olarak ele alınması gerekmektedir. Kullanıma hazır olma oranını koruyabilmek için düşük güvenilirliğin idame edilebilirlik ve desteklenebilirliğin artırılması ile dengelenmesi bir ölçüde mümkün olabilmektedir.

Projenin güvenilirlik ile ilgili gereksinimleri incelenerek (eğer yoksa hedef bir güvenilirlik değeri yüklenici tarafından benzer sistemlerin verileri kullanılarak belirlenebilir) güvenilirlik ataması yapılır. Böylelikle her bir fiziksel alt sistemin sahip olması gereken güvenilirlik metrik değerleri projenin geliştirme safhasında belli olur. Güvenilirlik atamaları yapılırken çeşitli askeri standartlardan, veri tabanlarından veya geçmişteki sistemlerin saha verilerinden faydalanılabilir. Güvenilirlik metrik ölçüsü onarılabilir olan sistemler için (tek kullanımlık olmayan araç, silah sistem gibi) arızalar arası ortalama süre olarak tanımlanabilir. Tek kullanımlık olan sistemler (füze sistemi gibi) için ise görev güvenilirlik değeri yüzde olarak tanımlanabilir.

Güvenilirlikle ilgili olarak tasarım kapsamında dikkate alınması gereken hususlara ilişkin örnekler aşağıda verilmiştir:

* Üründe güvenilirliği düşük alt sistem ve bileşenler için yedekleme yapılabilir.
* Uygulanabilir olduğu ölçüde askeri standartlara uygun ürün seçimleri yapılmalıdır.
* Benzer sistem ve projelerdeki güvenilir olduğu bilinen parçaların yeniden kullanımı ilk kez kullanılacak parça seçimine göre tasarımda öncelikli olmalıdır.
* Yalıtım malzemelerinin kullanımı değerlendirilmelidir.

Güvenilirlik açısından bir diğer tasarıma etki etme faaliyeti ise HTEKA (Hata türleri, Etkileri, Kritiklik Analizi) vasıtası ile olur. Sistemin arıza verme senaryoları tek tek incelenerek olasılıklar hesaplanır ve sistemin arıza durumunda arızanın göreve engel teşkil edip etmeyeceği araştırılır. Göreve engel teşkil eden arızaların tek hatadan kaynaklanması durumunda bazı önlemler alınarak sistemin tek hatadan gayri faal olma durumunun engellemesi hedeflenir. Ayrıca kritik bir arıza birden çok kez tekrarlanıyor ya da tekrarlanma olasılığı yüksek çıkıyor ise tasarıma geri bildirim verilerek tasarımın değiştirilmesi ya da sistemin yedeklenmesi gibi önlemler alınması sağlanır.

Tasarıma etki ara yüzünün oluşturulması kapsamında başlangıç noktası olarak kullanılabilecek kontrol listesi aşağıda verilmiştir;

* Hata modları ve etkileri tanımlandı mı?
* Kalemlerin arıza oranları biliniyor mu?
* Arıza oranı yüksek parçalar belirlendi mi?
* Ortalama ömrün ne olduğuna karar verildi mi?
* Ekipman tasarım karmaşıklığı minimize edildi mi?
* Uygulanabilir olan durumlar için ikincil hatalara (birincil hataların sonucu olarak meydana gelen hatalar) karşı korunma önlemleri alındı mı?
* Güvenilirlik gereksinimleri karşılanıyor mu?

=== 6.2.3. İDAME EDİLEBİLİRLİK ===
İdame edilebilirlik güvenilirliğin yanında kullanıma hazır olmayı etkileyen bir diğer önemli faktördür.

İdame edilebilirlik, belirlenmiş prosedür ve kaynaklar kullanılarak, tanımlı bakım onarım seviyelerinde belirlenmiş yeteneğe sahip personel tarafından bakım faaliyeti gerçekleştirildiğinde, odak sistemin öngörülen performans seviyesinde tutulabilmesi veya öngörülen performans seviyesinde tekrar çalışır duruma geri getirilebilmesi kabiliyetinin ölçüsüdür.

İdame edilebilirliğin karakteristikleri

* Bir ekipmanın işlevselliğini korumak veya işlevsel haline geri getirmek için ekipmanın değiştirilmesi,
* Onarım için geçen süre,
* Destek kaynaklarının miktarı ve karmaşıklığı ve
* Faaliyetleri gerçekleştiren personelin gerekli beceri seviyeleri olabilir.

Projenin idame edilebilirlik ile ilgili gereksinimleri incelenerek (eğer yoksa hedef bir idame edilebilirlik değeri yüklenici tarafından belirlenebilir) idame edilebilirlik süre kırılımı yapılır. Böylelikle her bir fiziksel alt sistemin sahip olması gereken idame edilebilirlik metrik değerleri projenin geliştirme safhasında belli olur. İdame edilebilirlik kırılımları yapılırken çeşitli askeri standardlardan, veri tabanlarından veya envanterde bulunan ve halihazırda kullanılan sistemlerin saha verilerinden faydalanılabilir.

İdame edilebilirlik ile ilgili gerçekleşen süreler, testler ve kullanıcıya verilen eğitimler sırasında ölçülüp doğrulanabilir. Ayrıca ürünlerin garanti döneminde yapılan bakımlardan toplanan verilerden de sistemlere yapılan bakımların ortalama süreleri çıkarılabilir.

İdame edilebilirlik ile ilgili yüklenicilerin karşılaştığı ulaşım, erişim, bakım yapılamama, sökülememe gibi problemlerin incelenmesi açısından 3B model yazılımları ve bazı destekleyici yazılımlar kullanılabilir. Bu yazılımların kullanılmasının amacı zorlukla yapılabilecek bir bakım onarım faaliyetini geliştirme safhasında modeller üzerinden önceden kestirebilmektir.

Tasarıma etki ara yüzünün oluşturulması kapsamında başlangıç noktası olarak kullanılabilecek kontrol listesi aşağıda verilmiştir;

* Farklı tiplerdeki bağlantı elemanlarının toplam sayıları minimuma indirildi mi?
* Bağlantı elemanları standart aletler için olan gereksinimlere bağlı olarak mı seçildi?
* Ekipman yenisi ile değiştirilebilir kalemler olarak mı tanımlandı?
* Bir kalemin yenisi ile değiştirilmesi için gereken süre minimize edildi mi?
* Operasyonel çevre koşulları dikkate alındı mı?
* Yazılımın nasıl yükleneceği, yükleme süresi vb. parametreler dikkate alındı mı?

=== 6.2.4. TEST EDİLEBİLİRLİK ===
Test edilebilirlik, bir bileşenin durumunun (çalıştırılabilir, çalıştırılamaz ve düşük fonksiyonlu çalıştırılabilir) ve hataların/başarızılıkların lokasyonunun zamanında ve belirli bir güven seviyesinde belirlenebilmesini sağlayan bir tasarım özelliğidir.

Test edilebilirlik gereksinimlerini karşılayacak bir tasarım çözümü, ürüne entegre bir test sistemi ile veya destek kaynaklarının bir parçası olan ve hataların lokalizasyonu için ürünle arayüzü bulunan bir test sistemi ile sağlanabilir. İyi tasarlanmış test sistemleri, hataların/arızaların bulunması ve düzeltilmesi için harcanacak çabayı azaltacağı gibi sistemin işlevselliğini doğrulamak için de kullanılabilir.

Test edilebilirlik gereksinimlerinden dolayı yeniden tasarım yapmak çok karmaşık bir faaliyettir

Arıza fark etme/doğrulamanın detay seviyesi, uygulanabilir bakım konseptini etkileyen en önemli etken olduğundan test edilebilirlik özelliklerinin tasarım tamamlandıktan sonra belirlenmesi mümkün olmayacaktır. Bu nedenle, test edilebilirlik gereksinimleri uygulanabilir her kalem için tasarım ve geliştirme safhalarında tanımlanmalıdır. HTEA/HTEKA sonuçları test edilebilirlik gereksinimlerini nasıl etkilediği konusuna EK-B’de değinilmektedir.

Test edilebilirlik analiz faaliyeti LDA faaliyeti olmayıp, yapılacak diğer lojistik destek analizlerinde bu çalışmanın çıktıları doğrudan kullanılacaktır. Bu anlamda analiz sonuçları, hem LDA girdisi hem de tasarım girdisi olacaktır. Hata Tespit Oranı, Hata İzolasyon Oranı ve Süresi test edilebilirlik parametreleridir. Testedilebilirlik analizi ile, FMECA çıktıları kullanılarak hata tespiti ile hata izolasyonuna ilişkin veriler belirlenir.  

* LDA girdisi; BGA’da belirlenen bir bakım görevi kapsamında bir kalemin test edilmesine ilişkin girdi sağlayacaktır.
* Tasarım girdisi; tasarıma etki kapsamında ise, arızalandığı durumda etki seviyesi yıkıcı olan bir donanıma test edilebilirlik özelliğinin kazandırılması, arıza sinyali olarak arıza mesajlarının tasarımına ve test ekipmanı gereksinimlerine girdi sağlanması örnek olarak verilebilir.

Tasarıma etki ara yüzünün oluşturulması kapsamında başlangıç noktası olarak kullanılabilecek kontrol listesi aşağıda verilmiştir;

* Uygulanabilir olan durumlar için birim içi test (self-test) durumu sağlandı mı?
* Birim içi test otomatik olarak mı yapılıyor?
* Doğrudan arıza göstergesi sağlandı mı (örneğin ışık yanması, uyarı çıkması gibi)?
* Kontrol ve hata izolasyonunu mümkün kılacak test ara yüzleri sağlandı mı?
* Test ara yüzleri erişilebilir mi?
* Test ara yüzleri fonksiyonel mi veya ardışık test yapmayı kolaylaştıracak şekilde mi?
* Test ara yüzleri yenisi ile değiştirilebilir kalemlerin doğrudan testini yapmaya olanak veriyor mu?
* Test noktaları gerekli olması halinde görsel olarak etiketlenmiş mi?
* Her ekipmanın işlev bozukluğu tespit edilebiliyor mu?
* Yazılım yeterli test bilgisini sağlıyor mu?

=== 6.2.5. PROGNOSTİK ===
Bazı ürün parametreleri ve verileri, bakım veya onarım ihtiyaçlarının kestirilmesine yönelik modellerde kullanılabilir. Prognostik, bir sisteme ilişkin ne zaman arıza oluşacağına dair kestirimde kullanmak üzere sistemin operasyonel durumuna dair veri toplanması ve analiz edilmesine izin veren bir tekniktir. Prognostik, test edilebilirliğin bir alt kümesi olarak düşünülebilir; ancak veri depolama ve anlık veri analizleri karmaşık olabilir, dolayısıyla genellikle kritik performans özelliklerine uygulanır.

Prognostiğin amacı, görev performansını sürdürebilmek için parçaları gerçekten arızalanmadan önce değiştirmek için optimum zamanı kestirmektir. Bileşenler özelinde ömrü, kullanım süresi, çevresel faktörler, benzer komponentlerin arızaları gibi bilgiler toplanır. Bu bilgiler daha sonra kestirimci modele veri olarak girilirse belirli bir komponentin ne zaman arızalanacağına yönelik bir tahmin oluşturulur.

Bakım/onarım prognostik işlevi, ürünün veya destek sisteminin bir parçası olarak tasarlanabilir.

Prognostiğin faydası, ürünün “sağlık” durumunun bilinmesi ve bu bilgiye dayanarak kritik arızalardan kaçınma ve sistemin işlevselselliğini idame edecek faaliyetleri planlayabilme olarak tanımlanabilir. Prognostik özellikleri olmayan bir sistemde, sistem ömrünü uzatmak için önleyici bakım kullanılır  ve sistem emniyeti düzeltici bakım işlem ve kaynaklarına karşı dengelenmeye çalışılır.

Ancak, parçaların arızalanmadan önce değiştirilmeleri yararlı ömürlerinin bir kısmının kullanılamaması ile sonuçlanmaktadır. Ayrıca, prognostik ancak yeterli ve uygun verinin toplanabilmesi durumunda etkin olacaktır. Dolayısıyla, prognostik tekniği kullanılması kararı, geliştirme ve kullanım maliyetlerinin operasyon esnasındaki arızaların etki ve maliyetleri ile kıyaslanarak verilmelidir.

=== 6.2.6. STANDARTLAŞTIRMA ===
Genel olarak, özel tasarlanmış ekipmanlar yerine standart ekipman kullanımı daha maliyet etkindir. Gereksinimleri karşılayan mevcut bir parça veya sistem kullanıldığında  geliştirme/ tasarım maliyeti ve süresi azalmaktadır.

Gereksinimleri karşılayan standartlaştırılmış ekipman kullanımı ile, mevcut lojistik destek kaynaklarının kullanımı da mümkün olabilir. Böylece destek sistemi kaynaklarının tasarım ve temini için yatırım ihtiyaçları azalır. Özel geliştirilmiş destek ekipmanı ihtiyacı ortaya çıkaran tasarım kararları, maliyeti artıracağı için dikkatle ele alınmalıdır.

Standartlaştırmanın diğer avantajı, ürün/sistem olgunluğu ve bilgisindeki artış ile operasyonel birimin hareket kabiliyetindeki artıştır.

Üründe kullanılan parçaların daha önce kullanıcı envanterinde kullanılıp kullanılmaması idame edilebilirlik açısından önemli rol oynar. Daha önce kullanıcının aşina olduğu sistemin aynısını veya bir benzerini yeni tasarımda kullanmak hem eğitimler hem ikmal hem de bakım personeli tecrübesinden faydalanabilme açısından faydalıdır.

Hali hazırda envanterde bulunan tüm sistemlerin tanıtıldığı ortak bir veri tabanı kullanılarak bir standartlaştırma yapılırsa veya yüklenici ve müşteri temsilcilerinin bulunduğu bir çalışma grubu ile envanterdeki benzer sistemler incelenirse aynı fonksiyon için tasarıma etki edilerek aynı veya benzer sistemlerin entegrasyonu sağlanabilir.

Standartlaştırmanın potansiyel faydalarını etkileyen faktörler aşağıda sıralanmıştır:

* Mevcut ekipmanların kullanımı, yeni destek kaynağı geliştirmede ortaya çıkacak geliştirme maliyetlerinden kaçınmayı sağlar,
* Yeni eğitim programı geliştirme maliyetlerinden kaçınılabilir,
* Destek kaynaklarının müşterekliği, destek kaynaklarının hazır olmasını artırırken lojistik hacmi azaltır,
* Standartlaştırılmış elemanların kullanımı destek kaynak gereksininmlerini belirlemek için gerekli geliştirme süresini kısaltır,
* Farklı ekipmanların kullanımı öğrenmek yerine aynı ekipmanın kullanımı söz konusu destek ve test ekipmanlarını kullanan personelin eğitim süresini azaltır ve personelin yetkinliğini artırır.

Standartlaştırma aynı zamanda değiştirilebilirliği de kapsar.

Yazılım tasarımı da örneğin programlama dilleri, bilgi yapıları veya yazılım ve bilgi taşıyan medya gibi konulara ilişkin standartlaştırma gereksinimlerinden etkilenebilir.

Standartlaştırmanın olası faydalarını gerçeğe dönüştürebilmek için ilgili gereksinimlerin tasarım faaliyetleri başlamadan önce belirlenmiş olması gerekir.

=== 6.2.7. BİRBİRİYLE DEĞİŞTİRİLEBİLİRLİK ===
Değiştirilebilirlik, performans ve dayanıklılık açısından eşdeğer işlevsel ve fiziksel karakteristiğe sahip olan iki veya daha fazla elemanın, kendileri veya bitişiklerindeki elemanlar üzerinde, ayarlama hariç tadilat gerektirmeden ve performans açısından seçim yapmadan, birbirleriyle değiştirilebilme kabiliyetine sahip olduğu durum olarak tanımlanır. Değiştirilebilirlik, benzer ekipmanlardaki parça veya komplelerin, tadilat veya fiziksel değişiklik gerektirmeden birbiri ile değiştirilebilme kabiliyeti olarak da adlandırılabilir.

Bir ürün tasarımının, uygun durumlarda ürünün kendi üzerinde veya ürünler arasında ekipman, komponent ve parçaların değiştirilebilirliğine olanak verecek şekilde gerçekleştirilmesi bir çok avantaj sağlayacaktır. Burada amaçlanan ekipman kullanımında esnekliği artırmak ve yedek parça stok seviyelerinde azalma sağlamaktır.

Değiştirilebilirlik, standartlaştırmanın sağlanmasında temel yöntemlerden birisidir. Standartlaştırma ile değiştirilebilirlik ilişkisine örnek olarak bir savunma ve güvenlik sisteminin gözetleme işinde kullanılan bataryanın başka bir sistem kapsamında da kullanılabilmesi verilebilir. Bu sayede batarya şarj cihazı da ortak olacağı için bir çok avantaj (tek bir bakım yönteminin olması gibi) sağlanacaktır.

Etkili olabilmesi için, değiştirilebilirlik ile ilgili gereksinimlerin tasarım faaliyetleri başlamadan tanımlanması gerekir.

=== 6.2.8. ÇEVRESEL HUSUSLAR ===
Bilinen operasyonel ve bakım çevresel koşulları ekipman ve tasarım çözümü tercihlerini etkileyebilir. Bakım ve operasyonu etkileyen parametrelere örnek olarak sıcaklık, nem, kumlu ve tuzlu ortamlar verilebilir. Ürün aynı zamanda ulaştırma, söküm, kurulum ve depolanması esnasında da gereksinimleri karşılamalıdır.

Bakım, iletim ve envanterden çıkarma için çevresel bir bakış açısıyla gerekli olan kimyasallar/malzemeler de önemlidir. Tehlikeli malzemelerin, tehlikeli atıkların ve çevresel kirleticilerin içerilmesinin sonuçlarının ürünle temas halinde bulunan personelin emniyeti ve ÖDM üzerinde etkisi vardır.

Çevresel etkilerin geliştirme safhasında göz önünde bulundurulması, sistemin kullanım, destek ve envanterden çıkarma safhalarında ortaya çıkabilecek sorunların önüne geçer. Bu nedenle çevresel hususların gereksinim olarak tanımlanması gerekmektedir.

Sistemin hangi çevresel koşullara maruz kalacağı bilgisi, sarf malzemelerinin (yağlar, yakıt vb.) seçiminde de göz önünde bulundurulması gereken hususlardandır.

=== 6.2.9. İNSAN FAKTÖRÜ/ERGONOMİ ===
İnsan faktörü mühendisliği, tasarıma etki kapsamında ele alınması gereken desteklenebilirlik mühendisliği fonksiyonlarından birisidir. Bu disiplin ile LDA süreci arasında sürekli bir ilişki ve entegrasyon söz konusudur.

İnsan faktörü/ergonomi ile ilgili olarak tasarım geri bildirimleri gereksinim olsun ya da olmasın üretilen sistemlerde insan-makine ara yüzü var ise göz önüne alınması gereken bir faktördür. İnsan faktörleri ve ergonomi ile ilgili kullanıcı makamı ve tedarik makamı yüklenicilere hangi istatistiksel antropometrik veri tabanını kullanarak sistem tasarımı yapılacağını bildirmelidir. Aksi halde sistem tasarımı çok geniş bir insan popülasyonunu kapsayacağından karmaşık hale gelebilir. Bu anlamda kullanıcı makamının karar vereceği bir antropometrik veri tabanının insan faktörleri ve ergonomi analizlerinde kullanılması önemlidir.

Bu analizler kapsamında, insan faktörü ve ergonomiye ilişkin ürün gereksinimleri belirlenmelidir. Ürün tasarımı operatör ve teknisyenler için erişilebilirlik hususlarını dikkate almalıdır.

Söküm takım faaliyetlerine ilişkin olarak erişilebilirliği analiz etmek için sanal araçlar veya başka yöntemler kullanılabilir. Konsept safhasından itibaren bakım ilişkili faaliyetleri simüle etmek maksadıyla bir takım ergonomi/simülasyon yazılımları kullanılabileceği gibi (Şekil 9), oluşturulan mock-up’lar üzerinden de analizler gerçekleştirilebilir. Böylelikle, tasarımın erken safhalarında bakım ve idame edilebilirliğe yönelik tedbirler (mühendislik değişimleri, bakım destek teçhizatı ihtiyacı tespitleri, bakım görev değişiklikleri vb.) alınarak tasarıma yön verilebilir.
[[Dosya:Şekil 9 Ergonomi-Simülasyon .jpg|sol|küçükresim|450x450pik|Şekil 9 Ergonomi/Simülasyon Yazılımlarından Örnek Görüntü]]

















Bakım, operasyon ve envanterden çıkarmada ihtiyaç duyulan kimyasallar/malzemeler de insan faktörleri perspektifinden önem taşır. Tehlikeli madde veya çevre kirletici ihtiva etmenin personelin emniyeti ve destek kaynağı ihtiyaçlarına etkisi vardır.

Tasarıma etki ara yüzünün oluşturulması kapsamında başlangıç noktası olarak kullanılabilecek kontrol listesi aşağıda verilmiştir;

* Uygulanabilir olan alanlar için kapaklar sağlandı mı ve açılır kapanır mı?
* Açıklıkların boyut ve konumu erişim için yeterli mi?
* Etiketlemeler yapıldı mı? Etiketlerin kapsaması gereken bilgiler yeterli mi?
* Kapaklara erişim için gerekli bağlantılar minimize edildi mi?
* Herhangi bir araç olmadan erişim sağlanabiliyor mu?
* Erişim için alet gerekiyorsa, sayılar minimize edildi mi ve standart aletlerin kullanımı sağlanabiliyor mu?
* Modüller ve komponentler arası erişim uygun mu?
* Tehlikeli malzemeler tanımlandı mı ve minimize edildi mi?
* Bir bakım görevini yerine getirirken koruyucu ekipman kullanmak gerekiyor mu? (Bu cevap BGA kaynak gereksinimlerine girdi olacaktır).
* Erişim gereksinimleri bakım sıklıkları ile uyumlu mu?

İnsan faktörleri ve ergonomi ile ilgili olarak MIL-HDBK 1472 ve DEF STAN-00-25 standartları referans olarak alınabilir.

İnsan faktörleri kapsamında gereksinimlerin tanımlanması ve bu gereksinimlerin lojistik açıdan da değerlendirilmesi gerekmektedir. İlave gereksinim tanımlama ihtiyacı ortaya çıkarsa sistem gereksinimlerine lojistik gereksinim olarak eklenmelidir. Örneğin, sistemin çalışma sıcaklığının 60 <sup>o</sup>C olduğu durum için sistem çevresel gereksinimleri kapsamında gereksinim tanımlanmış olabilir ancak sistemi doğrudan personel kullanacaksa sıcaklığa karşı koruyucu ekipmanla ilgili lojistik gereksinimi ya da personelin temas edeceği yüzeylerle ilgili alınacak tasarım önlemine ilişkin gereksinimin de tanımlanması gerekmektedir. Diğer taraftan insan faktörleri analizi ile ortaya çıkan sonuçların BGA kapsamında da uygulanması gerekmektedir. Örneğin, limitin aşıldığı bir bakım görevi varsa, ek bakımcılar, taşıma kolları eklenebilir ya da kalemin ağırlık yada boyutları kişi kaldırma limitlerini aşıyorsa ilgili bakım görevi için mekanik olarak taşıma tanımlanabilir.

=== 6.2.10. DEMODELİK ===
Ürünün ömür devrinin uzunluğuna bağlı olarak, muhtemel demodelik durumlarının geliştirme safhasında ele alınması önemlidir.  Demodelik sorunu, kullanıcı makamına teslim edilen sistemin önleyici veya düzeltici bakımı için yedek parça, sarf malzemesi veya ikmalde zafiyet oluşması ile ortaya çıkar.

Demodelik sorunları ortaya çıkmadan önce (proaktif yaklaşım) veya çıktığı durumlarda (reaktif yaklaşım) sistemin işlevselliğini koruyabilmek için eyleme geçmek gerekli olacaktır. Bu durumda alınabilecek tipik kararlar yeniden tasarım/modifikasyon, ömürlük satın alma veya sistemin hurdaya ayrılarak yeni bir sistemin devreye alınması vb’dir. Bu nedenle, bir sistemin tasarımı esnasında veya belli bir tasarıma uygun sistem veya alt sistem seçimlerinde, demodelik sebebiyle gelecekte bazı elemanların değiştirilme ihtimalini akılda tutmak gerekir. 

Demodeliği doğru yöneterek yüksek maliyetlerden kaçınmak mümkündür.

Demodelik yönetiminde amaç, sistemin demodeliği oluşmadan uyarı veren bir sistem kurmak, böylelikle demodelik oluştuğundaki yüksek maliyetlerden ve kullanıma hazır olma oranının düşmesinden kaçınmaktır.

Teknolojik eskimeye ise genellikle modernizasyonlar ile çözüm bulunmaktadır.

Sistemin tasarımı yapılırken teknolojik, ekonomik, siyasi vb. öngörülerde bulunularak uzun yıllar ikmal sorunu yaşanmayacak sistemleri veya parçaları tercih etmek ileride oluşabilecek ikmal problemlerinin önüne geçecektir (Detaylı bilgi için Bkz. [https://tssodypwiki.ssb.gov.tr/index.php/Sistem_%C3%96m%C3%BCr_Devri_Y%C3%B6netiminde_Demodelik_Y%C3%B6netimi_Rehberi TSSÖDYP-08 Sistem Ömür Devri Yönetiminde Demodelik Yönetimi Rehberi]).

=== 6.2.11. DESTEKLENEBİLİRLİK ===
Desteklenebilirlik, bir ürünün kullanılabilmesi ve idame edilebilmesi için gerekli olan bütün kaynakların yeterli miktarda sağlanma derecesine dair bir ölçüttür. Desteklenebilirlik sadece ürün değil bütün lojistik destek kaynaklarını (teknik dokümantasyon, destek ekipmanı, yedek parça, personel vb.) kapsar.

Sistem tasarımı esnasında, idame edilebilirlik ve güvenilirlik hususları dikkate alınarak sistemi desteklemek için ihtiyaç duyulacak kaynakların miktarı azaltılabilir. Aktif bakım süreleri ile lojistik ve idari gecikmelerin toplamından oluşan kullanım dışı kalma süresi (downtime) bu şekilde azaltılabilir. Daha çok destek kaynağına ihtiyaç duyan bir sistem bu kaynaklarda yaşanacak sıkıntı ve bekleme risklerine daha çok maruz kalacaktır.

=== 6.2.12. MALİYET ETKİNLİK ===
ELD’nin ve aynı zamanda LDA’nın en önemli konularından bir diğeri maliyet etkinliktir. Maliyet etkinlik, sistemin maliyet ve sistem etkinliği hedefleri ile destek maliyetleri üzerinde birbiri ile ilişkili etkileri bakımından alternatiflerin (faaliyetler, yöntemler, yaklaşımlar, silah sistemleri, destek sistemleri, vb) analizinden türetilen karşılaştırmalı bir değerlendirmedir.

Tasarım ve tasarım ilişkili kararların ÖDM üzerinde önemli etkisi vardır. Alternatif tasarım çözümleri arasında, destek kaynaklarını da içeren karşılaştırmalı analizlerin yapılması gereklidir. Maliyet etkinlik bu anlamda kullanıma hazır olma karakteristiği ile ÖDM’nin dengelenmesidir.

Desteklenebilir sistemlerin maliyet etkin bir şekilde işletme ve idamesi için her alanda tasarım iyileştirmesi yapılabilir. Örnek olarak idame edilebilirlik kapsamında yapılan tasarım geri bildirimleri ile bakım onarım süreleri azaltılarak maliyet etkinlik bir açıdan sağlanmış olur.

Ayrıca sistemin ÖDM analizi yapılarak analizde çıkan yüksek maliyet kalemlerine odaklanmak suretiyle kullanım ve destek maliyetlerinin düşürülmesi hedeflenir.

=== 6.2.13. YAZILIM TASARIMI ===
Yazılım tasarımı; ürün tasarımlarının ayrılmaz bir parçasıdır. Yazılım tasarımı, bu bölümde daha önce tanımlanan bazı özellikleri kazandırabilmek üzere hassasiyetle ele alınması gereken bir konudur.  

EK-H’de tanımlanan yazılım destek faaliyetlerinin sonuçları dikkate alındığında, sistemin kullanıma hazır olma gereksinimini karşılamak üzere yazılımın nasıl tasarlanacağı ve gerçekleştirileceğine dair bazı kararlar alınması gerekmektedir.

== 6.3. TASARIMA ETKİ ==
LDA’nın genel hedefleri tasarımı etkilemek, en etkin destek konseptini oluşturmak ve lojistik destek kaynak gereksinimlerini belirlemektir. Tasarımda serbest hareket edebilme özgürlüğü (esneklik) ve tasarımı etkileme fırsatları program/proje türlerine göre değişmektedir. Bu durum strateji belirlerken temel girdiyi oluşturur.

Geliştime programlarının yapısı aşağıdaki şekilde çeşitlilik gösterebilir:

* Savunma ve güvenlik sistemi ve destek ürünlerinin en baştan geliştirildiği yeni geliştirme programları
* Mevcut bir ürün için sistem/alt sistem tasarım değişiklikleri/iyileştirmeler
* İhtiyaç makamı/kullanıcı veya bir tedarikçi tarafından yürütülen ve mevcut teknolojiyi kullanan hızlandırılmış geliştirme programları

Dolayısıyla bir geliştirme programındaki tasarım esnekliği ve olası tasarım etkisi derecesi değişkendir. Genellikle, bir geliştirme programı, birden fazla değişik yapının bir kombinasyonudur. LDA faaliyetleri ve hedefleri de buna uygun şekilde odaklanmalıdır. Ayrıca, bir programda destek sistemi için tasarım esnekliği söz konusu iken ürün için bu esneklik daha az olabilir veya tersi durum da söz konusu olabilir. 

Tasarımcılar, tasarım faaliyetlerinin başlangıcından itibaren güvenilirlik, idame edilebilirlik, kullanıma hazır olma ve desteklenebilirlik hedeflerine yönelmiş olmalıdırlar. 

Diğer taraftan,  alt yüklenici tarafından gerçekleştirilen tasarım faaliyetleri de kurum içi tasarım gibi ele alınmalıdır. Tasarım faaliyetleri daha başlamadan tasarımı etkileyebilmek üzere alt yükleniciye özel LDA hedefleri ve gereksinimlerinin sağlanması, detaylı takvimlerin oluşturulması gerekmektedir. LDA gereksinimlerinin gözden geçirilmesi ve değerlendirilmesi de proje kapsamında gerçekleştirilen gözden geçirme toplantılarının gündemine dahil edilmelidir. Altyüklenici ve tedarikçileri dahil eden, “aşağıdan yukarıya” gözden geçirmeler de uygulanabilir olduğu ölçüde planlanmalıdır.

Desteklenebilirliği belirleyen tanılama özellikleri, arayüzler, güvenilirlik tahminleri, demodelik değerlendirmeleri, bileşen işlevleri gibi teknik tasarım bilgileri tasarım dokümantasyonun parçası olmalıdır.

Gözden geçirmelerde gündeme alınabilecek bazı konular aşağıda belirtilmiştir:

* LDA’nın iş dağılım ağacına göre yürütülmesi,
* Önerilen tasarım özelliklerinin desteklenebilirliği, maliyeti, kullanıma hazır olmayı ve yeni veya kritik destek kaynakları gereksinimlerini içerecek şekilde LDA açısından değerlendirilmesi,
* Karşılaşılan, önerilen, alınan düzeltici faaliyetler (değerlendirmedeki destek alternatifleri, değerlendirme ve ödünleşim analiz sonuçları, varolan ürünlerle yapılan karşılaştırmalı analiz, önerilen veya alınan tasarım yada yeniden tasarım eylemleri vb.),
* LDA gereksinimlerinin gözden geçirilmesi,
* Hedef belirleme veya ulaşma yolundaki ilerleme,
* Gerekli, tamamlanan, planlanan LDA dokümantasyonu,
* LDA’yı etkileyen tasarım, planlama, konfigürasyon değişiklikleri ve analiz problemleri. 

= 7. KULLANIM ve DESTEK SAFHALARINDA LOJİSTİK DESTEK ANALİZLERİ =
Ürün Ömür Devrinin ilk safhalarında, LDA metodolojisi kullanılarak geliştirilen destek faaliyetleri, ürüne ait kapasite ve kullanım gereksinimlerinin karşılandığını, ömür devri maliyetlerinin optimize edildiğini ve ürünün sürdürülebilir olduğunu garanti eder. Kullanım safhası süresince ise bir ürünün bakım ve çalışabilirliğinin sürekliliğini sağlamak için; kullanıcıdan alınan geribildirim verilerinin analiz edilerek, ilk varsayımlar ile gerçek kullanıma ait deneyim ve verilerin karşılaştırılması, uygulanacak olan destek faaliyetlerinin izlenmesi, değerlendirilmesi ve gerekmesi halinde güncellenmesi ve/veya uyarlanması faaliyetleri yürütülecektir.

Kullanım safhası LDA, ürün ömür devri faaliyetlerinin vazgeçilmez bir parçasıdır. Ürün kullanıma alındıktan sonra, ilgili hizmet içi veriler toplanmalı ve tanımlanmış destek gereksinimlerine karşı analiz edilmelidir. Destek gereksinimleri ürün ömür devri boyunca ihtiyaca göre değişiklik gösterebilmektedir. Bu nedenle, LDA metodolojisi uygun şekilde güncellenerek ürün destek gereksinimlerine yönelik çözüm ve önerilerin sürekli iyileştirilmesi sağlanmalıdır.

Bu aktiviteler neticesinde, destek çözüm ve önerileri:

Kullanım dönemi LDA faaliyetlerinin olumlu etkileri arasında aşağıdakiler sayılabilir:

* Ürün kullanılabilirliğinin arttırılması
* Ürünü desteklemek için gerekli kaynakların gerçek kullanım dönemi ile uyumlulaştırılması ve gerekli olması halinde iyileştirilmesi
* Modifikasyonlar ile ürünün geliştirilmesi
* Lojistik hacmin azaltılması
* Lojistik destek maliyetinin düşürülmesi

Kullanım dönemi safhasında LDA faaliyetlerinin uygulanması hem kullanıcı hem de yüklenici için bir kazan-kazan yaklaşımı oluşturmaktadır çünkü:

* Yüklenici, fiili ürün kullanımı hakkında bilgi alma ve ürün destek hususlarını öngörme noktalarında daha iyi bir pozisyona sahip olmakta ve destek sorunlarının çözümünde etkinliği arttıracak yeteneklerini geliştirmektedir.
* Kullanıcı ise, yüklenicinin ürün desteklenebilirliği ve destek sistemi verimliliğine getirdiği sürekli iyileştirmelerden faydalanarak ihtiyacının sürekli olarak sağlanması durumuna sahip olabilmektedir.

Kullanım dönemi LDA aktivitelerinin derinliği ve kapsamı yaşanacak değişikliklerin ölçeğine bağlı olacaktır. Bu değişiklikler aşağıdakilerden kaynaklanabilir:

* Ürün değişiklikleri ve yarı-ömür güncellemeleri (Bazen ‘teknoloji ekleme’ olarak da adlandırılır); bu seçenek, sistemin tümü ya da bazı bölümlerinde gerçekleştirilecek tasarım güncellemelerinin ve yenilemelerin, uygulanabilir olması durumunda ürün ömrü boyunca hangi noktalarda yapılacağının önceden kararlaştırılmasını gerektirir.
* Operasyonel ve çevresel gereksinim değişiklikleri veya operasyonel ve çevresel koşullardaki değişiklikler; bu değişiklikler, verilen destek üzerindeki etkilerin belirlenmesi için değerlendirilmelidir. Gerekli görülen analiz tekrarları sonucunda ürün veya destek çözümünde de değişiklikler gerekebilir.
* Mevzuat değişiklikleri; eğer değişiklikler ürün ile alakalı ise verilen destek çözümü üzerindeki etkileri değerlendirilmelidir.

Kullanım safhası LDA süreci genel hatlarıyla Şekil 10‘da verilmiştir.     
[[Dosya:Şekil10 Kullanım Safhası LDA Süreci.jpg|alt=|sol|küçükresim|600x600pik|Şekil 10 Kullanım Safhası LDA Süreci]]



































Kullanım ve Destek safhalarında LDA, kullanıcının teknik, lojistik ve ekonomik gereksinimlerine uyumluluğu sağlamak için ürün destek kaynaklarını – gerektiğinde – incelemeyi amaçlar. Bu incelemeler aşağıdaki nedenlerden dolayı tetiklenebilir:

* Elde edilen ve tahmin edilen sonuçlar arasında tutarsızlık olması
* Kullanıcı talebini karşılamak ya da harici kurallar ve mevzuata uyumlu olmak için üründe modifikasyon ve değişiklik yapılması
* Kullanım ve destek geri bildiriminin, risk ve fırsat yönetimini destekleyen genel sürecin bir parçası olarak dikkate alınıp optimizasyon alanlarının aranması

Kullanım dönemi boyunca birkaç LDA tekrarı yapılabileceği için LDA faaliyetlerinin sonunda bir Konfigürasyon Yönetimi (KY) sürecinin işletilmesi hayati önem taşır. Bu, kapsamlı bir konfigürasyon kontrolü, muhasebe ve denetim içerir. Buna ek olarak, kullanım dönemi LDA, ürünün hizmete girişinde hazır bulunması gereken bir kullanım ve bakım geri bildirim sistemine de ihtiyaç duyacaktır.                                                             
=== 7.1.1. KULLANIM VE DESTEK SAFHASI VERİ ANALİZİ VE LDA ===
Ürünle ilgili kullanım ve destek safhalarında herhangi bir konfigürasyon değişikliği, durumununda etki analizinin gerçekleştirilmesi ve bu değişikliklerin idame edilen ürünlerde, değişiklik yönetimi ve sapmaların sahadaki birimlere uygulanmasının planlaması ve yönetimi önem arz eden konuların başında gelir.

Kullanım ve destek safhalarında öne çıkan konfigürasyon yönetimi faaliyeti yüklenici tarafından desteklenen her bir ünitenin destek varlıklarının (destek ekipmanları, test program setleri, eğitim dokümanları ve yardımcı malzemeleri, el kitapları ve yazılımlar) konfigürasyon bilgilerinin takip edilebilirliğinin sağlanmasıdır. Eğer bu kalemlerde herhangi bir değişiklik varsa bu değişiklik, sapma ve feragat önerilerinde (MDT) değişen konfigürasyon bilgilerinden dolayı değişmesi muhtemel destek unsurları ve ELD elemanlarının (kullanıcı el kitapları, bakım kitapları, bakım araçları, tamir kitleri, yedek parçalar vb.) değişiklikten nasıl etkileneceği detaylı bir şekilde tanımlanmalıdır.

Sistemin envantere girmesiyle birlikte sistemin kullanım verilerinin toplanması önemli olacaktır. Destek kaynaklarının gerçek kullanımdaki durumları (bakım ihtiyaçları, eğitim yeterlilik durumu, yedek parça ihtiyaç durumu vb.) ve sistem performansının izlenmesi için bu verilerin toplanarak gerekli değerlendirmelerin yapılması gerekmektedir. Kullanım ve destek safhaları kapsamında toplanan veriler, güvenilirlik ve bakım yapılabilirlik gereksinimleri ile ilgili olarak kullanım başarısının ne olduğuna karar vermeyi ve destek çözümünün eksikliklerinin belirlenmesini mümkün kılacaktır. Bu verilerin analiz edilmesi, eksikliklerin sebebinin anlaşılmasını ve uygun çözümlerin geliştirilmesini sağlayacaktır. Hizmet içi kullanım döneminde toplanan kullanım verileri ile daha önceden yapılmış olan lojistik destek analiz faaliyetlerinin bir kısmının ya da tamamının tekrarlanması gerekebilir.

Tekrarlanması gereken lojistik destek analiz faaliyetlerinin hangileri olduğu ve tekrarlanacak olanların da kapsamı ve detay seviyesi aşağıda örnek olarak verilen değişikliklere bağlı olacaktır;

* Ürün modifikasyonları ve yarı ömür güncellemesi (eskimiş ya da demode olmuş kalemlerin değiştirilmesi de dahil edilebilir)
* Operasyonel ya da çevresel gereksinimlerin değişmesi durumunda bunun sağlanan destek üzerine etkilerinin değerlendirilmesi gerekir. Bu değerlendirme sonucunda, tekrar yapılması gereken analizler ve dolayısıyla destek çözümü ile ilgili değişiklikler ortaya çıkabilir.
* Kullanım esnasında, tasarım ve geliştirme döneminde yapılan analiz sonuçları ile kullanım esnasında ortaya çıkan durumlar arasında tutarsızlıklar varsa, ilgili analizlerin tekrar gözden geçirilmesi gerekebilir. 
* Kullanım ve destek geri bildirimlerinin dikkate alınmasıyla optimizasyon alanları araştırılabilir ve buna bağlı olarak gerekli olduğu düşünülen LDA faaliyetleri de tekrar gözden geçirilebilir.
* Kullanıma hazır olma, yedek parça sayıları gibi tasarım güvenilirlik değerlerine göre yapılan hesaplamaların, operasyonel ortam koşullarındaki mevcut durumu yansıtacak şekilde güncellenmeleri gerekmektedir.

Şekil 11’de kullanım ve destek safhaları bakım gözden geçirme süreci verilmiştir.
[[Dosya:Şekil 11 Kullanım ve Destek Safhası* Bakım Gözden Geçirme Süreci.jpg|alt=|sol|küçükresim|700x700pik|Şekil 11 Kullanım ve Destek Safhası* Bakım Gözden Geçirme Süreci]]



                                                























                           
















<nowiki>*</nowiki>Destek safhası, destek planlama ve destek uygulama olmak üzere iki aşamadan oluşmaktadır. Bu süreçte destek uygulama aşaması kastedilmektedir.

=== 7.1.2. MODİFİKASYON VE DEĞİŞİKLİK UYGULAMASI İÇİN KULLANIM SAFHASI LDA ===
LDA faaliyetlerine olan ihtiyaç, tasarlanan ürünün Kullanım ve Destek Safhası’nın başlamasıyla birlikte son bulmamaktadır. Bir ürüne ait en uzun safha olan Kullanım ve Destek Safhası süresince, ürün konfigürasyonunda yapılacak modifikasyonlardan dolayı LDA faaliyetlerinin ihtiyaç duyulan derinlikte tekrar icra edilmesi ve modifikasyonlardan önce üretilmiş olan verilerin güncellenmesi veya bazı faaliyetlerin baştan yapılması gerekebilir. Bu nedenle LDA faaliyetleri boyunca üretilen verilerin ve analiz faaliyetleri süresince alınan kararların, ürünün envanterden çıkarılması safhasına kadar kayıt altında tutulması ve güncelliğinin sağlanması gerekmektedir.

Sürece ilişkin örnek Şekil 12’de verilmiştir.
[[Dosya:TSSODYP06.12.jpg|alt=|sol|küçükresim|615x615pik|Şekil 12 Modifikasyon ve Değişiklik Uygulaması İçin Kullanım Safhası LDA]]





































=== 7.1.3. KULLANIM VE DESTEK SAFHALARI MALZEME YÖNETİMİ ===
Kullanım ve destek safhaları boyunca ürünler üzerinde güvenilirliği ve/veya performansı iyileştirmek, bir sistem elemanını/ekipmanı millileştirmek, vb. amaçlarla çeşitli modifikasyonlar yapılabilir. Müşteri’nin, ikmal desteğini planlayabilmesi ve tedarik süreçlerini yönetebilmesi için ürün konfigürasyonunda yapılan bu modifikasyonların konfigürasyon yönetimi faaliyeti kapsamında işlem görmesi ve ilgili veri kayıtlarının güncellenmesi gerekmektedir.

Kullanım ve destek safhaları süreci malzeme yönetimi süreci Şekil-13’te verilmiştir.
[[Dosya:Şekil13 Kullanım ve Destek Safhaları Malzeme Yönetimi Süreci.jpg|alt=|sol|küçükresim|700x700pik|Şekil 13 Kullanım ve Destek Safhaları Malzeme Yönetimi Süreci]]
































= 8. LDA VE KONFİGÜRASYON YÖNETİMİ =
Konfigürasyon Yönetimi (KY), farklı ürün konfigürasyonlarının doğru belirlenmesi, değişikliklerin kontrol edilmesi ve değişikliklerin uygulanma durumunun kayıt altına alınmasını sağlayan bir disiplindir.

KY, ürün ağacının en alt seviyesinden başlayarak gerçekleştirilir ve istenilen, tasarlanan, üretilen, desteklenen ürün bilgisini belirlerken değişikliklerin teknik ve operasyonel performansının yanı sıra ELD faaliyetleri üzerindeki etkilerini de değerlendirir.

== 8.1. LDA SÜRECİNDE KONFİGÜRASYON YÖNETİMİ ==
LDA faaliyetlerinin çıktıları, bir projenin KY süreçlerine dahil olmalıdır. KY sürecinin ana unsurlarından birisi ürün kırılımının oluşturulmasıdır. Ürünün konfigürasyonunu tanımlamak için oluşturulan kurallar ürün kırılımının ELD dahil bütün proje alanlarında izlenebilirliğini sağlamalıdır.

Belirlenen kurallara göre geliştirilen ürün kırılımı, ilgili ürünün farklı konfigürasyonlarını da kapsayıcı özellikte olmalıdır. Ürün kırılımının, ELD’nin tüm alanları için temel olacak şekilde oluşturulması oldukça önemlidir.

Projede farklı amaçlara yönelik farklı ürün kırılımları oluşturulabilir. Genel olarak çoğu projede ürünün tasarım kırılımı bir veri yönetim sistemi altında kontrol edilir. Aynı ürün için bir LDA kırılımı oluşturulabileceği gibi operasyonel ve bakım verilerinin geri beslemelerine yönelik ayrı bir kırılım da oluşturulabilir. Farklı amaçlar için farklı kırılımlar oluşturulması, çoğu zaman bu kırılımlar arasında tutarsızlıkların oluşmasına ve farklı disiplinler arasında ürün ilişkili verilerin iletilmesinde sorunlara yol açmaktadır. Bu nedenle proje kapsamında yürütülen konfigürasyon faaliyetleri ile izlenebilirliğin kurulması ve kayıt altına alınması önemlidir (Bkz. [https://tssodypwiki.ssb.gov.tr/index.php/Sistem_%C3%96m%C3%BCr_Devri_Y%C3%B6netiminde_Konfig%C3%BCrasyon_Y%C3%B6netimi_Rehberi TSSÖDYP-11 Sistem Ömür Devri Yönetiminde Konfigürasyon Yönetimi]).

= 9. LOJİSTİK YÖNETİM VE LDA İLİŞKİSİ =

== 9.1. LOJİSTİK DESTEK ANALİZ KAYITLARI (LDAK) ==
LDA süreci sonunda ortaya çıkan veriler mühendislik ve ürün destek faaliyetleri tarafından kullanımlarını geliştirmek için belirli biçimlere uyarlanır ve kayıt altına alınırlar.  Bu veriye lojistik yönetim bilgisi adı verilir ve çeşitli endüstri standartlarına uygun olarak oluşturulan veri tabanı da Lojistik Destek Analiz Kayıtları (LDAK) olarak adlandırılır.

Sözleşmelerde yer verilen LDAK gereksinimleri planlanan destek konsepti ile uyumlu ve uyarlanmış içerikte olmalıdır. Müşteri uyumsuzlukları ve gerekenden fazla olabilecek sözleşmesel teslimatları önleyebilmek için programın çeşitli işlevsel alanlarından gelecek verilere yönelik gereksinimleri koordine etmelidir. LDAK, nihayetinde bütün ELD unsurlarını dikkate alan etkin bir ürün destek paketi oluşturulmasında yardımcı olur.

Bir LDA veri tabanı içerisinde genel olarak aşağıdaki başlıklara yönelik veriler kayıt altına alınır:

* İşlevsel Gereksinimler
* Operasyonlar ve Bakım
* Güvenilirlik gereksinimleri ve analizlerin sonuçları
* Görev analizleri
* Personel becerileri ve eğitim
* Destek ekipmanları
* Test Altındaki Birim
* Tesisler
* Taşınabilirlik
* Tedarik ve kataloglama verileri

Bir projede lojistik yönetim verisi olarak nelerin kayıt altına alınacağı ve LDA sonrası oluşturulacak dokümantasyon, projeye özel olarak ve ürünün ömür devri safhasına göre uyarlanmalıdır.  LDAK’ın uyarlanması analizler için seçilen standart, gerçekleştirilmek üzere seçilen analizler ve bunların derinliği konusunda verilen kararlarla uyumlu olmalıdır. Uyarlama LDAK için referans alınacak standardı/spesifikasyonu, ihtiyaç duyulan veri elemanlarını ve formatını, tercih edilen veri transfer ve/veya raporlandırma yönetmini de kapsamalıdır.

== 9.2. LDAK STANDARTLARI/SPESİFİKASYONLARI ==
LDAK kayıtlarına yönelik standartlar, bir sistem veya nihai ürünün geliştirilmesi veya tedarik edilmesi esnasında üretilen lojistik destek analiz bilgilerini tanımlar. Bu konuda geliştirilen standartlar genel olarak ELD programını desteklemek için gerekli olan teknik verilerin oluşturulması, idamesi, temini ve kullanımında maliyet etkinliği sağlamaya yöneliktir.

LDAK’a yönelik yaygın olarak bilinen standart Amerika Savunma Bakanlığı tarafından 1991’de yayımlanan MIL-STD-1388-2B’dir. Standardın amacı, LDA Kayıtlarının geliştirilmesi ve teslimatına yönelik bir örnek gereksinimleri ortaya koymaktır. MIL-STD-1388-1A’da tanımlı olan lojistik destek analizlerden uygulanabilir olanlarının gerçekleştirilmesi sonrasında ortaya çıkan bilgilerin kayıt altına alınmasını düzenler. Standart içerisinde yer alan veri elemanı tanımları (data item definition) üretilecek verilerin tanımı ve biçimini belirleyerek standardizasyonunu sağlar. MIL-STD 1388-2B, 1996 yılında iptal edilmiş olmasına rağmen günümüzde halen bazı projelerde kullanımı devam etmektedir.

MIL-HDBK-502, Tedarik Lojistiği kılavuzudur. Plan ve program ilkelerini ortaya koyan MIL-STD-1388-1A kılavuzuna benzerdir. Bir anlamda, MIL-STD 1388 1A gelişerek MIL-HDBK-502’ye dönüşmüştür. MIL-PRF-49506 (Lojistik Yönetim Bilgisi) lojistik destek tanımlarıdır ve MIL-STD-1388 2B’nin yerini almıştır. Lojistik kayıtlarının “neler” olması gerektiğini değil de “nasıl” tutulması gerektiğini tarif etmeye çalışır. Gene de MIL-STD 1388-2B başlıklarının yaklaşık üçte birini kullanır. Aynı şekilde; MIL-STD 1388-2B gelişerek MIL-PRF-49506’ya dönüşmüştür.

SAE Lojistik Komitesi’nin yayımladığı GEIA-STD-0007 standardı ise; XML kullanılmasını, verilerin ve bunlarla yapılan işlemlerin, karakter tahdidi olmaksızın saklanmasını sağlar. MIL-STD 1388-2B’de yer alan başlıklar aynen korunur ancak, bu standardın vurguladığı nokta ilişkisel veri tabanlarında olduğu gibi verinin nasıl kaydedileceğinden ziyade nasıl transfer edileceğidir (örn., XML şemaları). Amerika’da yaygın olarak kullanılan standart artık GEIA-STD-0007’dir.

Yukarıdaki standartlara ek olarak AeroSpace and Defence Industries Association of Europe (ASD) bünyesinde geliştirilmekte olan S-Serisi spesifikasyonları arasında hem LDA süreçlerinin hem de LDAK yapısının tanımlandığı ASD/AIA S3000L spesifikasyonu vardır. S3000L’de yer alan veri yapıları da GEIA’da olduğu gibi XML formatındadır.

LDAK konusunda dikkate alınması gereken önemli bir nokta, standartların herhangi bir programda ihtiyaç duyulabilecek her türlü veri elemanını tanımlamaya yönelik oldukları, bu nedenle belli bir projede nasıl kullanılacaklarına özellikle dikkat edilmesi gerektiğidir. Standartlarda yer alan veri elemanı tanımlarının yaklaşık %15-20 kadarı tek bir projede gerçekten uygulanabilir olmaktadır.

== 9.3. ORTAK KAYNAK VERİ TABANI ==

* LDAP’da tanımlanan faaliyetler, belirlenen aday kalemler üzerinde uygulandıkça, ortaya o aday kalemlerin sahip olduğu özelliklerle ve birbirleri ile ilişki içinde olan pek cok bilgi çıkmaya başlar (örn., bir pompanın hata türleri, hata türünü gidermek için uygulanması gereken bakım/onarım faaliyeti, bakımda ihtiyaç duyulan yedek parçalar, bu yedek parçaların paketleme bilgileri, vb.). Bu bilgiler yapısal bir veri tabanı, yani ilişkili veriler arasındaki bağlantıların ve referansların tanımlanabildiği bir veri tabanı uygulaması içinde kayıt altına alınabilir. Bu sayede ürünün tüm ömür devri boyunca yaşayacağı değişimler de düşünüldüğünde ürüne ait LDA kayıtlarının yönetimi, tutarlılığı, revizyon takibi gibi konularda ciddi kazanımlar elde edilebilir. Bu özellikleri taşıyan veri yapıları/standartları, 9.2 numaralı konu başlığında yer almaktadır.

* LDA kayıtlarının tutulacağı bir veri tabanı uygulaması hem ihtiyaç makamı hem de yükleniciler açısından projenin kapsam ve türü, ürünün karmaşıklığı, LDA verilerinin miktarı vb. parametrelere göre bir ihtiyaç olabilir. Bu ihtiyaç, LDA faaliyetlerinin ürünün tüm ömür devri süresince devam eden canlı faaliyetler olmasından kaynaklanmaktadır. Ana Yükleniciler ve alt yükleniciler LDA faaliyetlerinde çoğunlukla tasarım ve test verilerini kullanarak, ürünün envantere girdiği andan itibaren ihtiyaç duyulacak lojistik verileri geliştirirler. İhtiyaç Makamı ise tasarım ve test verileri yerine saha verilerini kullanarak Ana Yüklenici’den temin ettikleri LDA kayıtlarını idame ederler ve gerekli hallerde güncellerler veya güncellenmesi için yüklenici ile görüşürler. Ana Yüklenici ve İhtiyaç Makamı arasında LDA kayıtlarının transfer edilebilmesi için her iki kurumun kullandığı veri tabanı uygulamasının da aynı standart veri yapısını desteklemesi gerekmektedir. Aksi takdirde iki farklı veri yapısını birbirine dönüştürebilecek bir diğer yazılıma daha ihtiyaç duyulacaktır.

== 9.4. VERİ TÜRLERİ VE SEÇİMİ ==
Bir projede hangi verilerin üretileceği yüklenici ve ihtiyaç makamı’nın birlikte yapacağı bir çalışma ile LDAP’da tanımlanan LDA faaliyetleri, faaliyetlere ait kural ve varsayımlar, bu faaliyetlerin derinliği, uygulanacak LDAK standardı ve aday kalem listesi göz önünde bulundurularak belirlenmelidir. LDA kayıtlarının yönetiminde ürünün ömür devri süresince hem müşterinin hem de yüklenici’nin rol ve sorumlulukları olduğundan dolayı, ortak bir çalışma yürütülmesinde fayda vardır. Bu verilerin projenin hangi safhalarında üretileceği, hangi sıklıkla paylaşılacağı/transfer edileceği ve yayınlanacağı ise LDA zaman planına göre belirlenmelidir.

== 9.5. VERİ SINIFLANDIRMASI ==

=== 9.5.1. MÜŞTERİ TARAFINDAN SAĞLANAN VERİLER ===
Müşteri, ürünü geliştiren/temin eden firmanın ulaşması gereken hedef değerleri tanımlamalıdır. Bu değerler, İhtiyaç makamının/kullanıcının operasyonel gereksinimlerine, hali hazırda kullanılmakta olan benzer sistemlerin lojistik verilerine ve lojistik operasyonlarının yarattığı maliyetlerin bir arada değerlendirilmesiyle belirlenebilir. Örneğin 20 tankın görevlendirildiği bir operasyonda operasyonun başarıyla tamamlanabilmesi için 18 tank yeterli oluyorsa, tedarik edilecek tankın hedef güvenilirliğinin kabaca %90 olduğu söylenebilir veya bir alt sistemin erişim kolaylığını tanımlamakta hedef bakım süreleri tanımlanarak ilgili alt sistemin kolay sökülebileceği bir tasarıma gidilmesi sağlanabilir. İhtiyaç Makamı/Tedarik Makamı’nın sağlayacağı veriler rasyonel ve ölçülebilir olmalıdır. Bu verilerin bir kısmının belirlenmesinde yüklenici ve müşteri birlikte çalışarak envanterdeki ürünler üzerinde ölçümler ve analizler yapabilir ve ortak bir paydada buluşulması sağlanabilir.

=== 9.5.2. YÜKLENİCİ TARAFINDAN ÜRETİLEN VERİLER ===
Yüklenici, müşteri tarafından tanımlanan hedef değerleri ve ürünün mühendislik ve test verilerini kullanarak belirlenen LDA faaliyetlerini yürütür. Bu faaliyetlerinin sonucu olarak da ürünün özelliklerini yansıtan lojistik verilerini üretir.

== 9.6. LDAK’IN GELİŞTİRİLMESİ VE YÖNETİLMESİ ==
LDAK ile ilgili karşılaşılan önemli sorunlardan birisi veri tabanının nasıl geliştirileceğidir. İhtiyaç duyulan bilgiden ziyade spesifik veri elemanlarına konsantre olmak uygulamayı temel amacından saptırabilmektedir. Veri tabanı geliştirilirken odaklanılması gereken temel nokta verileri türeten analiz sürecinin kendisidir.

LDAK’ın ürünün ömür devri boyunca kullanılacak verileri içermesi bir başka hususu daha ön plana çıkartır. Başlangıçta analizler çoğunlukla sistemin güvenilirliği, idame edilebilirliği, test edilebilirliği ve sistem kullanımının çevresel etkileri konusundaki kesitirimlere dayanır. Gerçekte bu kestirimler çoğunlukla sanıldığı kadar hassas değildir. Sistemi ömür devri boyunca destekleyecek kaynakların ayarlanması ve yönetilebilmesi amacıyla bu verilerin zaman içerisinde gerçek kullanımdan toplanan veriler ile yer değiştirmesi önemlidir.

== 9.7. LDAK’IN KULLANILMASI ==
LDAK veri tabanı, sadece oluşturulup bir yerlerde dosyalanmak için değil gerçek anlamda kullanılmak üzere tasarlanmalıdır. Oluşturulan/kayıt altına alınan veriler bütün ELD elemanları tarafından program kapsamında detaylı destek planlarının ve gereksinimlerinin oluşturulması için kullanılmalıdır. LDAK içerisinde yer alan veriler, sistemi desteklemek için gerekli lojistik kaynakları belirlemenin yanı sıra, desteklenebilirliği artırmaya yönelik tasarım değişikliği ihtiyaçlarını belirlemek için de kullanılır.

Bir proje başlatıldığında LDAK’ın nasıl kullanılacağının belirlenmesi, kullanım yöntemlerinin tanımlanması ve herkes tarafından anlaşılması açısından önemlidir. LDAK’ın gerçek faydalarının ve potansiyelinin anlaşılabilmesi öncelikle ortak kaynak veri tabanı konseptinin ve LDAK raporlama kabiliyetlerinin anlaşılmasını gerektirir.

== 9.8. LDA ÖZETLERİ/ RAPORLARI/ÇIKTILARI – STANDARTLARA GÖRE KARŞILAŞTIRMA ==
LDAK veri tabanlarından çeşitli konu başlıklarına göre raporlar üretilmesi mümkündür. Söz konusu raporlar veri tabanı içerisinden detaylı ama kullanılabilir bir biçimde veri derlemesi yapılarak hazırlanmalıdır.Raporlar, çok zaman gerektiren veya kritik bakım görevleri, personel ve beceri gereksinimleri, eğitim ihtiyaçları, bakım atama çizelgeleri (maintenance allocation chart) ve test ve detsek ekipmanı gereksinimleri gibi konuları kapsayabilirler.

= 10. FİZİKSEL DESTEK KAYNAK GEREKSİNİMLERİNİN BELİRLENMESİ VE DESTEK ÜRÜNLERİNİN OLUŞTURULMASI =
Fiziksel kaynak gereksinimi olarak nitelendirilen ELD ürünlerinin oluşturulmaya ne zaman başlanacağı teknik dokümantasyon ve resimli parça verilerinin mevcut olması dahil birçok faktöre bağlıdır. Tasarım ya da bakım konseptinde ortaya çıkabilecek değişikliklerin de lojistik ürünler üzerine etkisi oldukça fazladır. Bu kapsamda, dikkate alınması gereken ELD ürünleri şunlardır:

* Teknik Dokümantasyon
* Malzeme Desteği (resimli parça verileri)
* Genel ve Özel Destek Ekipmanları
* Eğitim
* Üretim tesisleri uzun süren planlama/gerçekleştirme/kalifikasyon gibi sebeplerle tipik bir ELD ürünü olarak kabul edilmezler. Üretim tesisleri vb.leri geniş kapsamlı olarak projelerin erken safhalarında dikkate alınmalıdır.

== 10.1. TEKNİK DOKÜMANTASYON ==
Teknik dokümantasyon iki ana bölümden oluşur;

* Sistemin bakım ve onarımına ilişkin el kitapları
* Sistemin kullanımına ilişkin el kitabı (Kullanıcı Dokümantasyonu)

Geliştirme safhası boyunca gerçekleştirilen lojistik destek analiz faaliyetleri ile esas alınacak bakım konseptinin ne olduğu, ne tür personel, destek ekipmanı ve yedek parçaların gerekli olduğu ve bakım onarım faaliyetlerinin nasıl gerçekleştirileceği gibi bilgileri tanımlanmış olur. Bu nedenle, sistemin bakım onarım faaliyetleri ile ilgili olan teknik dokümantasyonun geliştirilmesine, analiz çalışmalarının bir seviyeye gelmesiyle başlanmalıdır.  

Teknik el kitaplarının lojistik destek analiz sonuçlarına uygun olarak hazırlanması durumunda hatalı teknik dokümantasyon oluşturma ve dolayısıyla yeniden işleme riski ortadan kalkacaktır. Ancak bazı durumlarda, teknik dokümantasyon geliştirme süreci zaman kısıtları veya sözleşmesel şartlar nedeniyle projenin daha erken safhalarında başlamak zorunda olabilir. Bu durumda verilen bilgiler analizler sonuçlanana kadar bir seviyede kalacaktır.

Sistemin bakım ve onarımına ilişkin teknik dokümantasyon geliştirme sürecinin temeli LDA veri tabanında dokümante edilen bakım görevleridir. Ürünün ömür devri boyunca ihtiyaç duyacağı lojistik destek analizleri ile tanımlanan tüm görevler bakıma ilişkin dokümantasyonlarda yer almalıdır. Bu amaçla, Yüklenici bünyesinde teknik dokümantasyon geliştiren ekipler ile LDA faaliyetlerini yürüten ekipler arasında sıkı bir koordinasyon sağlanması önemlidir. LDA ile teknik dokümantasyon arasındaki ilişki Şekil 14’de gösterilmiştir.
[[Dosya:Şekil14 LDA ve Teknik Dokümantasyon.jpg|alt=|sol|küçükresim|550x550pik|Şekil 14 Lojistik Destek Analizleri ile Teknik Dokümantasyon Arasındaki İlişki]]


























Ürünün kullanımına yönelik teknik dokümantasyonun (Kullanıcı El Kitapları vb.) geliştirilmesi genel olarak LDA sürecinden bağımsız bir faaliyettir. Özellikle operasyonel analiz faaliyetleri sonucu ortaya çıkan bilgilerin kullanıcı dokümantasyonu geliştirilirken de dikkate alınması gereklidir. Bu alanda tanımlanan ve LDA veri tabanında dokümante edilen görevler, hem bakım-onarım hem de kullanım için olan teknik dokümantasyonun bir parçası olabilir.

LDA faaliyetleri sonucu belirlenen ve LDA veri tabanında dokümante edilen her bir bakım/onarım görevi ürünün bakım/onarımına ilişikin teknik dokümantasyona yansıtılmalıdır. Bununla birlikte, bakım onarım teknik dokümantasyonu, dokümante edilmiş LDA görevlerinin ötesinde bilgiler de içerebilir (LDA veri tabanında her bir bakım faaliyeti olmayabilir ya da her parça LDA adayı olmayabilir). LDA’nın amacı, doğru derinlikte bakım ve maliyet ile doğrudan ilişkili kalemlerin analiz edilmesidir. Teknik dokümantasyonlarda kalan ekipmanların ya da parçaların da göz önünde bulundurulması ve bunlara ilişkin bilgilerin de yer alması gerekmektedir. Bu bilgilerin detayları ve derinliği de müşteri ve yüklenici arasındaki anlaşmalara bağlıdır ve gözden geçirmelerin gündem maddelerinden olmalıdır. 

Dikkat edilmesi gereken hususların bazıları aşağıda verilmiştir;

* Teknik dokümantasyon için bakım görevleri hazır mı?
* LDA çıktıları teknik dokümantasyon için yeterli değilse, yine de doküman hazırlıklarına başlamanın riskleri nelerdir?
* LDA veri tabanının bir parçası olmayan hangi ilave faaliyetlerin teknik dokümantasyon içerisinde yer alması gereklidir?

== 10.2. İKMAL DESTEĞİ ==
Yedek parçaların neler olduğu, LDA faaliyetleri ile belirlenir.  Bakım konseptine bağlı olarak yedek parçaların belirlenmesi büyük ölçüde farklılık gösterebilir. Örneğin 2 seviyeli basit bir bakım senaryosunda komple bileşenler değiştirilecek ve sistemin operatörü tarafından onarım faaliyetleri gerçekleştirilmeyecektir. Bu durumda sadece az sayıda yedek parça tanımlanacaktır. Bununla birlikte, tanımlanmış bütün bileşenlerin ek olarak ihtiyaç duyduğu standart parçalar gibi ilave yedek parçalar da tanımlanabilir.

Belirleyici soru LDA içindeki arızanın boyutudur. Teorik olarak son parçaya kadar bir parçalama mümkündür ancak çaba çok büyük olduğundan bu kabul edilemez olacaktır. Bu nedenle uygulamada, LDA süreci içindeki yedek parçaların tanımlanması belirli bir seviyede duracaktır. Tipik olarak bakım ve maliyet faktörleri LDA süreci içerisinde tanımlanmalıdır. Bu bilgi LDA veri tabanındaki bakım görevlerinin gereksinimleri kapsamında belgelenmiştir. Teknik destek için açıklandığı gibi benzer bir süreç de malzeme desteği için oluşturulmalıdır. LDA faaliyetlerinin ilerlemesine bağlı olarak malzeme desteği ile ilgili lojistik ürünlerin oluşturulmasının başlangıcı LDA'nın ilgili bakım ve maliyet faktörleri tarafından tetiklenmelidir.

Aynı durum teknik dokümantasyon için de geçerlidir; çoğu durumda, gerekli tüm yedek parçalar LDA tarafından belirlenemez. Bununla birlikte, bir LDA görevi tarafından belirlenen tüm yedek parçalar malzeme destek kapsamında değerlendirilmelidir. Tablo 9 farklı türdeki yedek parçalara genel bir bakış ve bunların tanımlama sürecinde dikkate alınması gerekenleri göstermektedir.

'''Tablo 9 LDA Tarafından Belirlenen Farklı Yedek Parça Türleri Listesi'''
{| class="wikitable"
|'''Yedek Parça Tipi'''
|'''Açıklama'''
|'''LDA ile Malzeme Desteği Arasındaki Korelasyon'''
|-
|Komple ekipman  parçası
|·          Bakım odaklı

·          Maliyet odaklı

Kullanım sahasında  yer değiştirme görevlerinin (planlı veya plansız) değiştirilmesi için gerekli  yedek parçalar (kullanım sahasında herhangi bir onarım yapılmadan komple  ekipmanın değiştirilmesi)
|Ekipmanın gerekli bir yedek parça olarak tanımlanması  LDA'da tanımlanan bir bakım görevi tarafından onaylanmalıdır.
|-
|Özel yedek parça
|Kullanım sahasında  ekipman onarımı veya bakım işleri için gerekli yedek parçalar (ekipmanın  onarımı kullanım sahasında yapılacaktır)
|Bu bileşenin gerekli bir yedek parça olarak tanımlanması  LDA'da tanımlanan bir bakım görevi tarafından onaylanmalıdır.
|-
|Standart parçalar
|Kullanım sahasındaki  onarım veya bakım görevleri için gerekli standart parçalar (örneğin,  parçaların veya contaların takılması) (ekipmanın onarımı kullanım sahasında  yapılacaktır)
|Bu bileşenin gerekli  bir yedek parça olarak tanımlanması LDA'daki eksiklik kaynaklı malzeme  desteği tarafından onaylanmalıdır.
|-
|Sarf malzeme
|Sıvı, gres, özel  kimyasal ürünler, kaynak malzeme, tutkal gibi gerekli sarf malzemeleri
|Bu bileşenin gerekli  bir yedek parça olarak tanımlanması malzeme desteği veya LDA tarafından  onaylanabilir.
|}
LDA ile malzeme desteği drasındaki ilişki Şekil 15’de gösterilmektedir.
[[Dosya:Şekil15Lojistik Destek Analizleri ile Malzeme Desteği Arasındaki İlişki.jpg|alt=|sol|küçükresim|550x550pik|Şekil 15 Lojistik Destek Analizleri ile Malzeme Desteği Arasındaki İlişki]]

























== 10.3. GENEL VE ÖZEL DESTEK/TEST EKİPMANLARI ==
Sistemler ve ekipmanlar genel olarak kullanımlarını ve idamelerini desteklemek için ilave ekipmanlara ihtiyaç duyarlar. Bir ürünün kullanım ve bakımı için gerekli olan herhangi bir ekipman destek ekipmanı olarak adlandırılır. Destek ekipmanı bazen, özel bir kullanım için tasarlanmış bir “özel ekipman” olabileceği gibi bazen de birden fazla kullanım alanı olan “genel bir ekipman” olabilir  

LDA sürecinde ilgili destek ve test ekipmanının belirlenmesi ana görevlerden birisidir. Gerekli destek/test ekipmanının zamanında tedarik hazırlığının yapılmasının kritik önemi vardır ve bu anlamda ortak ve özel destek/test ekipmanı arasındaki ayrım yapılmalıdır. Özellikle, özel destek/test ekipmanlarına yönelik ihtiyaçlar ve gereksinimleri LDA sürecinde belirlenmelidir. Bu belirlemeden sonra da  geliştirme ve tedarik süreci başlamalıdır.

LDA veri tabanındaki statü bilgileri destek ve test ekipmanlarından sorumlu birimler tarafından faaliyetleri başlatmak için kullanılabilir. Ancak, bazı durumlarda destek/test ekipmanı gereksinimleri dokümante edilmiş LDA görevleri dışında kaynaklardan da türetilebilir. Örneğin genel aletlerin belirlenmesi için mutlaka LDA veri tabanına giriş yapılması gerekmez (basit bir tornavida için belirli bir LDA görevi tarafından ihtiyaç belirlenmesi gerekmez).

Destek ekipmanı gereksinimlerinin belirlenmesinde bakım konseptinin büyük bir rolü vardır. Kaç seviyede bakım yapılacağı ve her seviyede gerçekleştirilmesi beklenen bakım görevlerinin neler olabileceği, genel olarak destek ekipmanı ihtiyaçlarını tanımlayan temel girdidir. Teorik olarak, organizasyonel seviyede gerçekleştirilecek bakımların ara seviye ve fabrika/depo seviyesi bakımlara nazaran daha az destek ekipmanına ihtiyaç duyması beklenir. Buna paralel olarak organizasyonel seviyede kullanılacak destek ekipmanlarının maliyetleri de normalde diğer seviyelere göre daha düşük olacaktır.

Destek ekipmanı gereksinimlerini etkileyen önemli bir diğer faktör üründe yer alacak cihaz içi test (BIT) kabiliyetidir. Örneğin, bir ekipman bir arızayı sistem içerisinde küçük bir modüle kadar ayrıştırabilecek test kabiliyetine sahipse ve operatör bu modülü genel aletler kullanarak söküp değiştirebiliyorsa hem organizasyonel hem de diğer bakım seviyelerinde karmaşık bir destek ekipmanı ihtiyacı olmayabilir. Bu durumda ara seviye sistemin tamamında hata ayrıştırması yapmak yerine değiştirilen modüllerin onarımına odaklanılabilir.

Sistemin kullanıma hazır olma hedefleri gerek duyulacak destek ekipmanlarının belirlenmesinde dikkate alınması gereken bir diğer faktördür. Güvenilirlik, İdame Edilebilirlik ve Kullanıma Hazır Olma unsurları öncelikle belirlenmelidir. Bu sayede ürünle ilgili işletim ve bakım ihtiyaçlarına uygun ekipmanların belirlenmesi sağlanacaktır. Tasarım olgunlaştıkça, destek ekipman tür ve miktarlarına dair gereksinimler Bakım Görev Analizi (BGA) kapsamında belirlenir.

Destek ekipmanları belirlenirken işletme ve çevre şartları göz önünde bulundurulmalı, ürün için yapılan lojistik destek analizleri ve ürün özellikleri dikkate alınarak yedek malzeme stoklaması yapılmalı, ürünü kullanıma almak için gerekli test, ayar ve kalibrasyon cihazları belirlenmelidir. LDA ve test ekipmanları arasındaki ilişki Şekil 16’da gösterilmektedir.
[[Dosya:Şekil16LDA ve Test Ekipmanları Arasındaki İlişki.jpg|alt=|sol|küçükresim|500x500pik|Şekil 16 LDA ve Test Ekipmanları Arasındaki İlişki]]

























== 10.4. EĞİTİM ==
Gerekli bakım görevleriyle ilgili bütün bilgiler (örn. performans detayları, gerekli destek ekipmanı, zorluk ve kritiklik, süre, çalışma adımları, gerekli personel sayısı) sağlanana kadar bakım faaliyetleriyle ilgili eğitim ihtiyaçları belirlenemez. Eğitim gereksinimlerini tanımlamanın ilk adımı bir Eğitim İhtiyaçları Analizi (EİA) olmalıdır. Bu, LDA tarafından belirlenen bakım görevlerine dayanabilir. LDA ve eğitim arasındaki ilişki Şekil 17’de gösterilmektedir.
[[Dosya:Şekil17LDA ve Eğitim.jpg|alt=|sol|küçükresim|550x550pik|Şekil 17 LDA ve Eğitim Arasındaki İlişki]]































Eğitimin içeriğini belirleme ve geliştirme süreci müşteri ve yüklenici arasındaki anlaşmalara göre LDA sonuçları ve/veya mevcut teknik belgelerde geçen bilgiler kullanılarak sağlanmalıdır. Çünkü eğitim ekipmanlarının geliştirilmesi çok maliyetli olabilir (eğitim videoları, eğitim kuleleri, eğitim simülatörleri, vb üretimi).

Mümkün olan en iyi destek için LDA veri tabanındaki eğitim bilgilerinin belgelenmesi önemlidir. LDA veri tabanı "gerekli eğitim", personel için beceri seviyeleri veya varsa daha ayrıntılı bilgi gibi basit işaretler içerebilir. LDA veri tabanının eğitim gereksinimlerinin çıkarılmasını destekleyen sorgular içerecek şekilde tasarlanması önerilir.

== 10.5. TESİSLER VE ALTYAPI ==
Tesisler ve altyapı, bir sistemi desteklemek için gerekli olan kalıcı ve yarı-kalıcı gayrimenkul varlıklarından oluşmaktadır. Bu alanda yapılan çalışmalar, tesislerin türlerinin tanımlamasını (ör: eğitim, ekipman depolama, bakım, tedarik depolama, mühimmat depolama, bilgisayar donanım/yazılım sistemleri, ağ ve iletişim sistemleri) veya konum, alan ihtiyaçları, çevre ve güvenlik gereksinimleri ve ekipmanlarının belirlenmesi ile tesis iyileştirmelerini kapsar. Sistem çalışmasının etkililiğini en üst düzeye çıkarmaya olanak sağlayacak; eğitim, bakım ve depolama faaliyetlerinin gerçekleştirilmesi için en düşük sahip olma maliyetli tesisin belirlenmesi, planlanması, kaynak sağlanması ve satın alınması, bu öğenin amacıdır. Tesisler ve altyapı; tesis ve altyapı türlerini tanımlamak için yapılan çalışmalar, tesis ve altyapı iyileştirmeleri, konum, alan ihtiyaçları, çevre ve güvenlik gereksinimleri ve ekipmanları dahil olmak üzere bir sistemi desteklemek için gerekli olan kalıcı ve yarı kalıcı gayrimenkul varlıklarından ve altyapıdan oluşur. Yapılan LDA faaliyetleri savunma ve güvenlik sisteminin kullanımı ve idamesi için ihtiyaç duyulacak tesis ve altyapı özelliklerinin belirlenmesine katkı sağlayacaktır.

== 10.6. PAKETLEME, ELLEÇLEME, DEPOLAMA VE ULAŞIM ==
Bir ürünün normal kullanımı dışındaki paketleme, taşıma, depolama ve nakliye faaliyetleri ihtiyaca göre belirlenmelidir. Bu hususların bir kısmı analiz sonuçlarından ortaya çıkmayabilir. Ancak ürünün kullanıma alınmasıyla birlikte eksik ve/veya yetersiz bilgi sebebiyle kullanıma ilişkin hatalar olabilir. Bu nedenle, bu bilgilerin belirlenerek ilgili teknik dokümantasyonlarda belirlenmesi önemlidir.

=== 10.6.1. PAKETLEME ===
AKK ve/veya bileşenleri için paketleme konsepti aşağıda verilen örnek durumlara göre belirlenebilir;

* Paketleme kısa süreli ve/veya uzun süreli depolama için mi gereklidir?
* Paketleme nakliye için gerekli midir ve ne tür bir nakliye yapılacaktır?
* Depolama veya nakliye için özel bir konteyner gerekli midir?
* Depolama veya nakliye döneminde aşırı iklim koşullarından dolayı özel koruma gerekli midir? (Örneğin deniz taşımacılığı)
* Nakliye veya depolama süresince, örneğin bakım faaliyetleri (depolama görevleri) gerçekleştirmek için ürün ambalajından çıkarılıp yeniden ambalajlanması gerekir mi?
* Destek ekipmanı ve tesisleriyle ilgili muhafazanın çıkarılması ve paketin açılması için ne gereklidir?

=== 10.6.2. ELLEÇLEME ===
Ürün taşıma görevleri aşağıda verilen örnek durumlara göre belirlenebilir;

* Taşıma için gerekli güvenlik önlemleri ve sınırlamalar dikkate alınmalıdır.
* Normal kullanım haricinde herhangi bir şekilde park etmek, çekmek, vinçle kaldırmak veya taşımak için gerekli talimatlar belirlenmelidir.
* Ürünün yer değiştirmesi için gerekli talimatlar, örneğin takma noktaları, gerekli adaptörler, özel bileşenler için destekler, denge ağırlıkları, kriko prosedürleri belirlenmelidir.
* Ürün taşımada gereken ek ekipman ve malzemeler önceden belirlenmelidir. (örn. çekme çubukları veya kablolar)

=== 10.6.3. DEPOLAMA ===
Depolama süresi boyunca ve depolama sonucunda ürün işlevselliğini garanti etmek için depolama prosedürleri analiz edilmeli ve belgelenmelidir. Depolama koşulları aşağıda verilen örnek durumlara göre belirlenebilir;

* Gerekli depolama uzun süreli depolama veya kısa süreli depolama çözümü olarak mı değerlendiriliyor?
* Ürün/bileşen özel hassasiyette depolanacak mı?
* Depolanacak ürün bileşenlerini çıkarmak ve bu bileşenleri özel şartlarda ayrı olarak depolamak gerekli midir? 
* Depolama sırasında yapısal ve sistem bütünlüğünü korumak için ne tür bir kontrol ve önleyici bakım gereklidir? (örn. Tekerlek dönüşü, elektrik gücü, motor çalışması ve basınç kontrolleri vb.)
* Depo içi bakım için bir zaman çizelgesi sağlandı mı?
* Depolama süresince beklenen aşırı iklim koşulları (ısı, don, nem vb.) var mı? 
* Depolamaya giriş için gerekli özel teknikler var mı? (örn. Temizlik ve koruma, sıvı sistemi boşaltma/yenileme, statik topraklama, koruyucu boşluk, özel bileşenlerin sökülmesi vb.) 
* Depolamadan çıkarılması ve kullanıma geri dönmesi için gerekli özel teknikler var mı? (örn. Koruma ve temizleme, sıvı sisteminin yenilenmesi, özel bileşenlerin tekrar montajı, fonksiyonel kontroller, kullanıma hazırlama)
* Saklama süresi boyunca ne tür bir güvenlik önlemi gereklidir? (örn. Hareketli bir bileşenin demirlenmesi/sabitlenmesi ve bloke edilmesi, karanlık bir depolama alanında tutulup ışığa maruz kalmaması vb.)
* Depolanan ürün/bileşenin ömrü ile bağlantılı olarak depolama süresini dikkate almak gerekli midir?

=== 10.6.4. ULAŞIM ===
Müşteri gereksinimlerine dayanarak, ürünün taşınabilirliğinin analizi aşağıda verilen örnek durumlara  göre belirlenebilir;

* Nakliye için hazırlanma ve nakliye sonrası yapılması gerekli faaliyetler için harcanan iş gücü ve süre nedir? 
* Personel, araçlar, sarf malzemeleri ve tesislerle ilgili nakliye sonrası hazırlık ve iyileştirme için gereksinimler nelerdir?
* Özel koşullar altında nakliye için ek çevresel şartlar nelerdir? (örneğin deniz taşımacılığı, kumlu çöl ortamı, nem, ısı, don gibi aşırı iklim koşulları gibi)
* Özel koşullar altında nakliye için ek güvenlik gereksinimleri nelerdir? (örn. Hava taşımacılığı durumunda bir nakliye uçağı içinde demirleme/sabitleme) 
* Taşıma süresince gerekli servis işlemleri nelerdir? (özellikle uzun yolculuklarda)
* Ürün bileşenlerini nakliye için sökmek veya tüm ürünü belirli bir seviyeye indirgemek gerekli midir? 
* Konteyner/taşıma kutusu kavramı düşünülmeli mi? 
* Kızakların ve/veya paletlerin kullanımı kabul edilebilir mi?

= 11. LDA VE KAYITLARINA İLİŞKİN FAALİYETLERİN UYARLANMASI =
Sürecin uyarlanmasında bu rehberden etkin olarak faydalabilmek kullanıcıların kendi projelerine uygun olan işlevleri seçmeleri ve uygulamaları ile mümkün olabilir. Rehberin bölümleri ilgili projeye münferit olarak dahil edilebilir veya kapsamdan çıkartılabilir. Uyarlama aynı zamanda analize tabi tutulacak aday kalemlerin (ürün bileşenleri) çeşitliliği ve sayısı,  bir aday kalem için yapılacak analizlerin neler olacağı, analizler esnasında kullanılacak veriler ile analiz bilgilerinin nasıl kayıt altına alınacağı konularında da gerçekleştirilebilir.

Projenin/Programın erken safhalarında bir LDA stratejisi belirlemek ve LDA programı oluşturmak uyarlama için yapılması gereken ilk adımlardır.

Uyarlama esnasında dikkat edilmesi gereken önemli bir nokta sadece LDA sürecinin değil genel anlamda ELD sürecinin uyarlanması, farklı ELD disiplinleri açısından referans alınabilecek standartların/süreçlerin birbirleri ile uyumlaştırılarak LDA veri tabanına sonuçların yansıtılması ve uyarlama esnasında varsa eskiden kalan/mevcut verilerin (legacy data) nasıl ele alınabileceği, yeni standartalara ve yazılım araçlarına nasıl geçiş yapılabileceği gibi konuların da ele alınmasıdır.

Lojistik iş tanımlama toplantısı, uyarlamanın ilk olarak tartışılacağı ve kararlaştırılacağı adımlardan birisi olabilir.

LDA sürecinin bir proje kapsamında uyarlanması aşamalı bir faaliyettir. Genel LDA çerçevesinin belirlenmesinden LDAK içerisinde yer alacak veri elemanlarının belirlenmesine kadar devam eder. Bu kapsamda uyarlama aşamaları şöyle sıralanabilir:

* Projede uygulanacak analizlerin seçilmesi ve her bir aday kalem için hangi analizlerin uygulanabilir olduğunun belirlenmesi
* Projeye özel iş kurallarının belirlenmesi (örn. Ürün kırılımı için seçilecek yöntem, OSA yöntemi, lojistik FMEA, vb.)
* Proje gereksinimlerine göre belirlenen standart/spesifikasyon içerisinden veri elemanlarının seçilmesi

== 11.1. PROJE KAPSAMINDA ANALİZ GEREKSİNİMLERİNİN BELİRLENMESİ, SEÇİM KRİTERLERİ ==
Bölüm 5.4.1’de tanımlanan potansiyel lojistik destek analizleri içerisinden proje kapsamında hangilerinin gerçekleştirileceğinin belirlenmesi uyarlama sürecinin önemli bir adımdır.

Tablo 10’da LDA analiz faaliyetlerinin seçimi ve aday kalemlere atanması için dikkate alınabilecek örnek kriterler yer almaktadır. Seçim kriterleri de projeye göre farklılık gösterebileceğinden özel durumlar da dikkate alınarak uyarlanmaları mümkündür. Seçim faaliyetinden önce, kullanılacak kriterler üzerinde tüm paydaşlar arasında uyumlaştırılmış olması gereklidir.  Bu uyumlaştırma LDA GGT’de sağlanabilir.

'''Tablo 10 Analiz Faaliyetleri Seçim Kriterleri'''
{| class="wikitable"
|'''Kriter Grubu'''
|'''Kriter'''
|'''Öneri'''
|-
| rowspan="6" |Kullanım tecrübesine  sahip olunan kalemler
|Halen karşılaştırılabilir  koşullarda kullanılmakta olan kalemler
|Mevcut analiz  verilerinin orta derecede dönüşümünün yapılması
|-
|Halen kullanılan  -fakat karşılaştırılabilir şartlar altında olmayan- kalemler
|Mevcut analiz  verilerinin dönüşümünün dikkatli yapılması
|-
|Majör modifikasyon  gerektirmeden kullanılabilecek RAHAT kalemler
|Mevcut analiz  verilerinin orta derecede dönüşümünün yapılması
|-
|Minör/Majör  değişiklik gerektirecek kalemler
|Mevcut analiz  verilerinin dikkatli dönüşümünün yapılması yeni analizlerin  gerçekleştirilmesi
|-
|Bilinen bir  teknolojiye bağlı olarak yeni geliştirilen kalemler 
|Analiz  faaliyetlerinin gerekli detay seviyesinde yapılması (önemle tavsiye edilir)
|-
|Yeni bir teknolojiye  bağlı olarak yeni geliştirilen kalemler
|Analiz  faaliyetlerinin gerekli detay seviyesinde   yapılması gereklidir.
|-
| rowspan="3" |Geniş  bir bakış açısı gerektirdiği ya da özel öneme sahip olduğu için  değerlendirilmesi gereken kalemler
|Potansiyel göreve  hazır olma ve/veya maliyet etmenleri
|Bu kalemler için  kriterlerin LDA GGT’da detaylandırılması gerekir. 
|-
|Müşterinin ısrarlı  ilgisine konu olma  
| rowspan="2" |Kalemlerin LDA GGT’de  detaylandırılması gerekir.
|-
|LDA ilişkili sözleşmesel  yükümlülükler
|-
| rowspan="4" |Kendi tasarım  özellikleri gereği veya yerleşim yerinden dolayı değerlendirilmesi gereken  kalemler
|İlgili  arıza/hata sıklığı, iş yükü, özel lojistik gereksinimlere (personel ve/veya) ilişkin  olarak Bakım Önemli Kalemler
|Bu  kalemler için kriterin LDA GGT’de detaylandırılması gerekir.
|-
|Planlı bakıma veya  ömür limitlerine tabi  kalemler
|Planlı bakım analizi  için kriterlerin LDA GGT’de detaylandırılması gerekir.
|-
|Özel olaylardan  kaynaklanan önleyici bakıma tabi kalemler
|Özel olay analizi  için kriterlerin LDA GGT’de detaylandırılması gerekir.
|-
|Yerleşim yeri  nedeniyle potansiyel hasarlarla karşılaşmaya müsait kalemler 
|Hasar analizi için  kriterlerin LDA GGT’de detaylandırılması gerekir.
|-
| rowspan="4" |LDA aday tipleri
|Tam aday 
|Uygulanabilir  analizlerin yapılması, sonuçların LDA veri tabanında kayıt altına alınması, 
|-
|Kısmi Aday 
|Temel seviyede  bilgilerin LDAK içerisinde kayıt altına alınması
|-
|Aday aileleri 
|Bir grup bileşenin  tek bir LDA adayı kalem olarak ele alınması, uygulanabilir analizlerin  yapılması ve sonuçların LDAK içerisinde kayıt altına alınması, 
|-
|Standart prosedürlere  tabi kalemler
|Temel seviyede  bilgilerin LDAK içerisinde kayıt altına alınması
|-
| rowspan="5" |Müşteri tarafından bilgi  talep edilen durumlar
|LDA sürecinden  beklenen bilgiler
| rowspan="4" |LDA GGT süresince,  müşteri ile uyumlaştırılmalı ve üzerinde mutabık kalınmalıdır.
|-
|Tavsiye edilen lojistik  destek esaslarına dair öneri
|-
|Olası alternatiflerin  tanımlanması (donanım, yazılım, destek konseptleri için) ve ilişkili  sonuçları (ör., lojistik destek gereksinimleri)
|-
|Tavsiye edilen bakım  konseptleri ve ilgili bakım görevlerine dair teklif
|-
|İlgili lojistik  destek maliyetlerinin tahmini
|İlişkili lojistik destek  gereksinimlerin belirlenmesi, lojistik destek maliyet tahmini, erken dönem sistem/proje  kararlarına yönelik bilgiler (önemli maliyet etkisi) 
|}
Her bir LDA aday kalemine hangi analizlerin uygulanacağına dair seçimle ilgili kararların dokümante edilmesi için bir matris kullanılabilir. Seçimler esnasında, bütçe ya da zaman gibi kısıtlar varsa, buna göre önceliklendirme yapılabilir.

Bu matris, LDA adaylarının tanımlanması ve görev seçim kriterleri ile buradan çıkan sonuçları içerecek şekilde LDA GGT öncesinde yüklenici tarafından hazırlanmalı ve toplantı esnasında müşteri ile uzlaşılan kararları yansıtmalıdır. Dokümanın, değişiklikleri yansıtması, ‘kazanılmış dersler’e ilişkin sonuçları kapsaması ve sistemin ömür devri boyunca izlenebilirliği sağlayan yaşayan bir doküman olması önemlidir.

LDA aday kalemleri ve uygulanacak analizlere ilişkin taslak bir listenin, teklif süreci esnasında LDA görev atamalarına ilişkin rehberlik sağlaması ve risk azaltma amaçlı olarak müşteriye sunulması tavsiye edilir.

Seçilen analiz faaliyetlerini kayıt almaya dair matrise ilişkin bir örnek Tablo 11’da verilmiştir.

'''Tablo 11 Analiz Faaliyetleri Öneri Matrisi'''
{| class="wikitable"
|Seviye
|Aday Tipi
|Adı
|Genel   LDA Gerekleri
|Karşılaştırmalı   Analiz
|İnsan Faktörü Analizi
|Konfigürasyon   Değerlendirme
|Güvenilirlik Analizi   Değerlendirmesi
|İdame Edilebilirlik   Analizi
|Test Edilebilirlik   Analizi
|HTEA / HTEKA
|Hasar Analizi


|Özel Olay Analizi
|Planlı   Bakım Analizi
|OSA
|BGA
|Yazılım   Destek Analizi
|Lojistik İlişkili   Operasyonlar Analizi
|Eğitim İhtiyaçları   Analizi (TNA)
|Sıralama
|-
|1
|Sistem
|<nowiki>-</nowiki>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|-
|1.1
|Alt  Sistem
|<nowiki>-</nowiki>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|-
|1.1.1
|Aday  Değil
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|-
|1.1.2
|Tam  Aday
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|-
|1.1.3
|Kısmi  Aday
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|-
| colspan="20" |0 = Uygulanabilir  Değil      1 = İsteğe Bağlı      2 = Tavsiye Edilen      3 = Kuvvetle Önerilen   4 = Zorunlu
|}
LDA adayları tarafından yönlendirilmeyen bütün genel görevlere ilişkin tavsiyeler farklı dokümanlarda kayıt altına alınmalıdır.

== 11.2. ÖMÜR DEVRİ SAFHALARINA GÖRE ANALİZLERİN UYARLANMASI ==
LDA aktivitelerinin gerçekleştirilebilmesi için projenin farklı safhalarında farklı veri setleri erişilebilir durumda olmalıdır. Tanımlanan LDA görevlerinden bazıları projenin erken safhalarında gerçekleştirilebilirken bazıları tasarımla ilgili detaylı ve nihai bilgilerin oluştuğu dönemlerde yürütülebilir. Ömür devri safhalarına (Bkz.[https://tssodypwiki.ssb.gov.tr/index.php/Sistem_%C3%96m%C3%BCr_Devri_Y%C3%B6netimi_Rehberi_(Ana_%C3%87er%C3%A7eve) TSSÖDYP-01 Sistem Ömür Devri Yönetimi Rehberi (Ana Çerçeve)] ) göre analiz faaliyetlerinin akış süreci  Şekil 18’de örnek olarak verilmiştir.
[[Dosya:TSSÖDYP06 Ş.18.jpg|alt=|sol|küçükresim|689x689pik|Şekil 18 Ömür Devri Safhalarına Göre Analiz Akış Süreci]]













































LDA aktiviteleri geliştirme safhasının sonunda bitmez. Üretim safhasında da üründe gerçekleştirilecek değişikliklerin kapsamına bağlı olarak LDA birkaç kez daha tekrarlanabilir. Bu durum kullanım safhasında da geçerlidir. Kullanım safhasında ürüne kapsamlı modifikasyonlar yapılması söz konusu olabilir. Dolayısıyla LDA sürecinin belirli şartlara bağlı olarak tekrarlanması gerekmektedir. Bu yüzden, lojistik verinin ve kararların dokümantasyonunun sistem ömür devri boyunca envanterden çıkarma safhasına kadar devam ettirilmesi gerekir.

==== <big>11.2.1.1. Erken Dönem Analiz Faaliyetleri</big> ====
Projenin erken safhalarında, LDA aktiviteleri düşük seviyede bilgi gerektiren durumlarla sınırlıdır. LDA GGT’den önce operasyonel ve müşteri gereksinimleri ile ilgili bilgiler normalde erişilebilir durumdadır. Dolayısıyla LDA GGT’den önce LDA sürecinin temel kurallarına ilişkin taslağın hazırlanması GGT çalışmalarını hızlandıracaktır.

Analiz altındaki sistem veya kalem hakkında detaylı bilgi bu aşamada normalde erişilebilir değildir.  Bu aşamada, yalnızca sürecin uygulanması için temel koşul ve kurallar erişilebilir durumdadır, ancak genel LDA ihtiyaçlarının belirlenmesi analizi, karşılaştırmalı analiz, insan faktörleri analizi, operasyonlar analizi, konfigürasyon değerlendirmesi gibi bazı analizlere LDA sürecinin erken aşamalarında da başlanabilir.

==== <big>11.2.1.2. Tasarım ve Geliştirme Dönemi Analiz Faaliyetleri</big> ====
LDA süreci, tasarım ve geliştirme dönemi boyunca tasarım süreci ile beraber yürümelidir. Bu durum, çok erken faz ya da tasarım donduktan sonraki faz hariç, tüm LDA aktivitelerine uygulanır.  Bu aktiviteler aşağıdaki gibidir:

* Konfigürasyon değerlendirmesi
* Güvenilirlik analizi değerlendirmesi
* İdame edilebilirlik analizi
* Test edilebilirlik analizi
* HTEKA / HTEA
* Hasar analizi
* Özel olay analizi
* Planlı bakım analizi
* Onarım seviyesi analizi
* Bakım görev analizi
* Yazılım ve veri yükleme/indirme/taşıma analizi
* Yazılım tasarım ve yazılım bakım analizi
* Lojistik İlişkili Operasyonlar analizi

Tasarım donduktan sonra, lojistik ile ilgili veri toplanma işlemi büyük ölçüde tamamlanmış olmalıdır. Bu yüzden, detaylı veri gerektiren analiz aktiviteleri, sabitlenmiş tasarımı garantiye almak ve maliyetli analiz aktivitelerini tekrarlamak riskini azaltmak için tasarım sürecinin son aşamalarında gerçekleştirilmelidir. 

* Operasyonel senaryoların simülasyonu
* Eğitim ihtiyaçları analizi

==== <big>11.2.1.3. Kullanım Dönemi Analiz Faaliyetleri</big> ====
Kullanım safhası boyunca, lojistik analiz faaliyetleri tekrarlanacak olup bu durum azalan ölçüde olacaktır. Eğer ürün teknik güncellemeler ya da tasarım değişikliğine uğrarsa, lojistik gereksinimleri dikkate alan yeni bir analiz yapılmalıdır. Analizin derinliği ve genişliği, sistemin tipine ve değişikliğin ölçüsüne bağlı olacaktır.

==== <big>11.2.1.4. Sistem Ömür Devri Safhalarındaki Aktivitelerin Özeti</big> ====
Tablo 12, tüm ömür devri safhalarındaki potansiyel analiz aktivitelerinin özetini göstermektedir. (ör: veri ve bilgi toplama, yönetim, teknik/lojistik analizler ve hazırlık görevleri). Bu tablo, tasarım ve geliştirme dönemine ek olarak Ön Tasarım Gözden Geçirme (ÖTGG) ve Kritik Tasarım Gözden Geçirme (KTGG) gibi tipik aşamaları da içerir.

'''Tablo 12 Sistem Ömür Devri Safhalarındaki Aktivitelerin Özeti'''
{| class="wikitable"
| rowspan="2" |'''Ön Konsept & Konsept Safhası'''
| colspan="3" |'''Geliştirme Safhası'''
| rowspan="2" |'''Üretim Safhası'''
| rowspan="2" |'''Kullanım Safhası         (Destek Uygulama Aşaması ile  birlikte)'''
| rowspan="2" |'''Envanterden Çıkarma Safhası'''
|-
|'''Yapılabilirlik çalışması'''
|'''Ön Tasarım'''

'''(PDR)'''
|'''Kritik Tasarım (CDR)'''
|-
|Performans Ürün  verisi (CRD)
|Performans Ürün verisi  güncellemeleri (CRD)
|
|
|
|
|
|-
|Ürün kullanım verisi
|Ürün kullanım verisi  güncellemeleri (ORD)
|
|
|
|
|
|-
|
|İdame Edilebilirlik  Çalışmaları
|İdame Edilebilirlik  Analizleri
|İdame Edilebilirlik  Analizleri Güncellemeleri
|
| rowspan="4" |Geri besleme  verilerine dayanan destek konseptinin süregelen optimizasyonu→ Hizmet içi LDA


Analiz sonuçlarının  ve konfigürasyon değişikliği bazlı ELD ürünlerinin güncellenmesi
|
|-
|
|Güvenilirlik  Çalışmaları
|Güvenilirlik  Analizleri
|Güvenilirlik  Analizleri

Güncellemeleri
|
|
|-
|Karşılaştırmalı çalışmalar
|Karşılaştırmalı  çalışmalar
|Karşılaştırmalı  çalışmalar
|
|
|
|-
|
|
|ELD ürünlerinin  geliştirilmesinin planlanması
|ELD ürünlerinin  geliştirilmesi
|ELD ürünlerinin  güncellenmesi
|
|-
|
|
|
|
|
|Enventerden  Çıkarmanın planlanması
|
|}

= 12. EKLER =

== EK-A İNSAN FAKTÖRÜ ANALİZLERİ VE LDA ==


'''<big>1. GİRİŞ</big>'''

İnsan faktörü analizleri, LDA faaliyetleri esnasında bakım ekibi ve destek ekipmanı gereksinimlerinin belirlenmesi için kullanılabilecek kaynak veriyi sağlarlar. Bu ilişki tasarım süreci esnasında başlar ve bakım görev analizlerinin geliştirilmesi süreci boyunca devam eder.

LDA, idame edilebilirlik ve desteklenebilirlik işlevleri, potansiyel destek çözümlerinin insan faktörü gereksinimlerini de kapsayan eşik değerlerin içerisinde kalmasını sağlayacak şekilde koordine edilmelidir. Bunun için operasyonel ve bakım görevlerinin gerçekleştirilmesinde gerekli olan destek kaynaklarının ve ekip büyüklüğünün dikkate alınması gerekir. İnsan faktörü kısıtlamaları ürünün tasarımını etkilemenin yanı sıra destek ortamının oluşturulmasını da etkiler. İnsanın kısıtlı kabiliyetleri, ürün kullanımı ve desteği üzerinde kısıtlamalara yol açar.

Bu EK teknik ve LDA faaliyetleri gerçekleştiren personele yönelik olarak hazırlanmıştır. Bölümde insan faktörleri ve lojistik destek analiz süreci arasındaki ilişkiler ve entegrasyonu tanımlanmaktadır. İnsan faktörü analiz sonuçlarının projenin mümkün olan en erken safhalarında dokümante edilmesi tavsiye edilmektedir. LDA veri tabanı içerisinde insan faktörlerinin etkileri farklı yerlerde görünebilir. Uyarı ve ikazların yanı sıra, belirli bir görev yerine getirmek veya personeli olumsuz çevresel ortamda koruyabilmek için gerekli özel ekipman ihtiyaçları bu konuda örnek teşkil edebilir.


<big>'''2. LOJİSTİK DESTEK ANALİZLERİ VE İNSAN FAKTÖRLERİ'''</big>

'''<big>2.1. FİZİKSEL KABİLİYETLER VE KISITLAMALAR</big>'''

LDA ve insan faktörü entegrasyonu ürünün bütün ömür devri boyunca süreklilik arz eder. Üründe gerçekleştirilen modifikasyonlar veya önerilen tasarım değişiklikleri beraberinde bakım görevlerinde de değişiklik gerektirebilir.

LDA ve insan faktörü analizlerinin ortak hedeflerinin yanı sıra kendilerine özel amaç ve hedefleri de vardır. İnsan faktörleri antropometrik hususlar, ergonomik hususlar ve diğer fizyolojik hususlara ilişkin değişik standartlara odaklanabilir. LDA da bu standartları dikkate almalı ve potansiyel destek çözümlerini değerlendirmelidir. Bu konuya verilebilecek örneklerden biri, ortalama insan önkolunun çapıdır. Bilek hareketinin ötesinde erişim gerektiren bir panelin tasarımında uygun standartlarda verilen minimum ölçü dikkate alınmalıdır. Bu durumda, insan faktörü bütün erişim panelleri için söz konusu ölçü gereksiniminin dikkate alınmasını sağlamak üzere tasarıma etki eder. Buna ilave olarak LDA, kısıtlı hareket imkânları olan bir ortamda gerçekleştirilecek bir görevin tamamlanabilmesi için gerekli destek ekipmanlarını tanımlar. Eğer, analiz faaliyetleri esnasında alternatif tasarım çözümleri belirlenirse, bunlar tasarım sürecinde dikkate alınmak üzere tasarım ekiplerine bildirilir.

'''<big>2.2. TEHLİKELİ DURUMLARDAN KAYNAKLANAN KISITLAMALAR</big>'''

İnsan faktörlerinin dikkate alınması gereken bir başka nokta insan sağlığına karşı tehditlerden dolayı bazı aktivitelerin kısıtlanmasıdır. 

Tehlikeli maddelerin ele alınması, fiziksel bütünlüğün korunması açısından katı yasal düzenlemelere tabidir. Özellikle ürün ömür devri sonunda, ürününün envanterden çıkarma safhasında insan sağlığına zararalı olabilecek malzemelere maruz kalma ve dolayısıyla insan faktörü büyük önem arz eder.  

Çok sıcak veya soğuk, nemli, yeraltı veya sualtı, çok gürültülü vb. aşırı çevresel koşullar altında gerçekleştirilen faaliyetlere ilişkin kısıtlamalar da dikkate alınması gereken hususlardandır. İnsanların bu çevresel koşulların etkisine karşı korunmaları da fiziksel kısıtlamalar gibi LDA süreci içerisinde ele alınmalıdır.


<big>'''3. İNSAN FAKTÖRÜ ANALİZLERİ'''</big>

'''<big>3.1. TASARIMA ETKİ</big>'''

İnsan faktörü tasarım kısıtı ve gereksinimlerini tanımlayan çeşitli standartlar vardır. Bu standartlar, yüklenici/müşteri mutabakatında uygun şekilde referans verilmeli ve sözleşmelere dahil edilmelidir. 

İnsan faktörleri niceliksel verileri bakım ekibinin becerileri, sayısı ve destek ekipmanı ihtiyaçları belirlenirken dikkate alınmalıdır. Örneğin, insan faktörleri, tek bir kişinin taşıyabileceği ağırlık limitlerini belirler. Bu limitler mekanik kaldırma araçlarını, ayaklık ihtiyaçlarını ve/veya personel sayısını belirler. Bu bilgi, tasarım alternatiflerinin değerlendirilmesi için kullanılabilir.  İnsan faktörleri, bakım görevlerine uygulabilecek spesifikasyon ve standartları sağlar. 

Ekip büyüklüğüne ilişkin personel gereksinimler, uygulanabilir olduğu durumlarda demografik özellikleri de dikkate almalıdır. Örneğin tamamen erkeklerden oluşan bir ekip için tanımlanacak yük kaldırma limiti, kadın erkek karma bir ekibin yük kaldırma limitinden daha yüksek olacaktır. Yani ekipmanın ağırlığı, kaldırılabilmesi için gerekli personel sayısını belirler ancak bu sayı farklı demografik özelliklere göre değişiklik gösterebilir. Ağırlık sınırlamaları, mekanik kaldırma gereksinimleri için de dikkate alınarak destek ekipmanı gereksinimlerini etkilemelidir. 

<big>'''3.2. LDA İÇİN İLKELER'''</big>

LDA İş Tanımlama Toplantısı, LDA ve insan faktörü analizlerine uygulanacak kural ve ilkeleri belirlemelidir. Yüklenici ve müşteri arasında uygulanacak spesifik standart üzerinde mutabakata varmalı ve standarda yönelik istisnalar da tanımlanmalıdır. 

LDA tasarım sürecinden aldığı girdileri kullanır ve her altenatif tasarım/tasarım unsurları için ödünleşim analizleri gerçekleştirir. İlk tasarım faaliyetlerinden itibaren, LDA tasarımı analiz ederek alternatiflere yönelik destek gereksinimleri karşılaştırarak tavsiyelerde bulunur. Süreç bütün olası bakım görevlerini tanımlamayı içerir. Her bakım görevi için ihtiyaç duyulacak kaynakların listesi oluşturulur. Bu kaynaklar, yedek parça, sarf malzemesi, bakım işçilik saati, eğitim, destek ve test ekipmanlarını kapsar. İnsan faktörüne özel hususlar bakım personelinin sayısı, ilgili destek ekipmanları vb’dir. 

Bakım personeli sayısı, bakım görevine ilişkin gerekli beceriler, değiştirilen ekipmanın ölçüleri ve ağırlığndan etkilenir. MIL-STD 1472 gibi çeşitli insan faktörü standartları tek bir kişinin taşıyabileceği ağırlık limitlerini tanımlamaktadır. Ekipman belli bir uzaklığa taşınacaksa, bunun için de limitler söz konusudur. Bu limitler BGA esnasında dikkate alınmalıdır.  Limitlerin aşıldığı durumlarda ilave personel ihtiyacı ortaya çıkacak, ekipman üzerinde tutma yeri tasarlanması gerekecektir. Bu gibi durumlarda mekanik kaldırma araçları tanımlanması da dikkate alınabilecektir. 

Analiz süreci yinelemeli bir süreç olup, her tasarım değişikliğinde de tekrarlanmalıdır. LDA süreci içerisinde, detaylı BGA ürün tasarımın onaylanmasından sonra başlar. Her bakım görevi, ilgili insan faktörü standardı ile kıyaslanarak bütün bakım ve operasyon faaliyetlerinin insan faktörü limitleri içerisinde olduğu teyit edilir.

'''<big>4. DİKKATE ALINMASI GEREKEN İNSAN FAKTÖRLERİ</big>'''

Aşağıda sıralanan insan faktörleri, dikkate alınması gereken insan faktörleri açısından sınırlayıcı değildir; ancak ürün tasarımını etkileyecek ve özellikle LDA alanında destek ortamının tasarımında dikkate alınabilecek insan faktörlerine örnek olarak dikkate alınabilir. 

<big>'''4.1. ANTROPOMETRİK HUSUSLAR'''</big>
* Görüş hattı (yatay ve dikey görme alanı) 
* Ses sinyali gereksinimleri 
* Kol, el ve başparmak için kas gücü 
* Dikey çekme hareketleri için gerekli kas gücü 
* Yatay çekme ve itme hareketleri için gerekli kas gücü 
* Kaldırılabilecek ünitelerin azami ağırlığı 
* Destek ekipmanlarının azami ağırlığı 
'''<big>4.2. ERGONOMİK HUSUSLAR</big>'''
* Kumandaların tasarımı (ör. Anahtarlar, çevirme kolları, kumanda kolları, el çarkları, pedallar, düğmeler, vs.) 
* Minimum tutacak ölçüleri 
* Çalışma alanı tasarımı (oturarak, ayakta, mobil) 
* Zor erişilebilirlik – rampa ve merdivenler 
* Kapı ve erişim paneli ölçüleri 
* Aydınlatma gereksinimleri 
'''<big>4.3. ÇEVRESEL HUSUSLAR</big>'''
* Etkin sıcaklık 
* Aşırı sıcak ve soğuk sıcaklık limitleri 
* Rüzgarın soğutma etkisinin insan üzerinde etkisi 
* Aşırı iklim koşullarında insan performansındaki düşmeler 
* Havalandırma gereksinimleri 
* Ultraviyole ışımaya maruz kalma
* Toz ve duman gibi kirliliğie maruz kalma 
* Gürültü limitleri<br />
== EK-B  HTE(K)A ve SONUÇLARININ LDA İÇERİSİNDE KULLANIMI ==
<big>'''1. GENEL'''</big>

Hata Türleri ve Etkileri Analizi (HTEA) olaya dayalı bakım analizlerinden biridir. Önleyici Bakım Analizleri ve Özel Olay Analizleri önleyici bakımlara odaklanırken HTEA ve Hasar Analizleri düzeltici bakımlara odaklanır (Hasarlar aynı zamanda önleyici bakıma da tabi olabilir).

HTEA, üründe bünyesel bir arıza oluştuğu durumda uygulanması gereken düzeltici bakım görevlerinin belirlenmesine yönelik yöntem ve karar mantığını ortaya koyar.

Bütün ekipman ve bileşenler önleyici bakım uygulansın ya da uygulanmasın hata yapmaya eğilimli olup, önleyici bakım için adaydırlar. Bazı hata/arızalar operasyon esnasında veya bir bakım görevi ya da muayene esnasında teşhis edilebilir veya gözlenebilirler (kişiler veya entegre test sistemleri vasıtasıyla). Bazı hatalar ise teşhis edilebilmekle birlikte lokalize edilemezler ve bazıları da hiç teşhis edilemezler.

Dolayısıyla birçok durumda, hatalı ünitelerin sökülmesi ve değiştirilebilmesi için öncelikle teşhis ve tespit edilmelerine yönelik ilave arıza giderme (troubleshooting) işlemlerinin yapılması gerekir. Bu işlemler:

* HTEA’dan türetilen veriler ile karakterize edilir ve LDA kayıtları altında dokümante edilmelidir, 
* İlgili teknik yayınlarda dokümante edilmelidir 
* Özel aletler ve test ekipmanları gerektirebilir. 

HTE(K)A ve sonuçlarının LDA içinde kullanımının kapsamı:

* Mevcut dokümanlardan mümkün olduğunca yaralanmak (ör, tasarım ekibi tarafından gerçekleştirilen HTEKA) veya HTEA verisinin üzerine LDA ihtiyaçlarına göre uyarlanmış  çalışma inşa etmek ya da mevcut hiçbir doküman yoksa yeni bir HTEA çalışması gerçekleştirilmesi 

* Hataların tespit edilmeleri ve hatalı bileşenlerin lokalize edilmeleri için uygun vasıtaları analiz edilmesi 
* Özel arıza teşhis prosedürlerine yönelik olası gereksinimlerin belirlenmesi 
* Muhtemel özel alet ve test ekipmanı ihtiyaçlarının belirlemesi  
* Sonuçların kayıt altına alınması

faaliyetlerini kapsar.

Süreç, ürün içerisindeki yeni geliştirilen, başka bir projeden tekrar kullanılan veya RAHAT malzeme olarak temin edilen herhangi bir bileşen için uygulanabilir.

Tasarım, geliştirme ve üretim faaliyetlerine yönelik çeşitli HTEA ve HTEKA türleri söz konusudur.

'''<big>2. TASARIM VE GELİŞTİRME FAALİYETLERİNDE HTEKA</big>'''

HTEKA, geliştirme safhasında yapılması gereken analiz faaliyetidir. Diğer taraftan ihtiyaç olması halinde (tasarım değişikliği, modifikasyon vb) ilgili safhalarda güncellenebilecek bir analizdir.

HTEKA’nın hedefi bir sistem tasarımındaki bütün hata türlerini belirlemek olmakla birlikte, birincil amacı katastrofik ve kirtik hata türlerinin erken tespit edilerek, mümkün olan en erken safhada tasarım değişiklikleri ile ortadan kaldırılması ya da minimize edilmesidir. Dolayısıyla HTEKA çalışmaları, başlangıçta ön tasarım bilgileri ortaya çıkar çıkmaz en üst sistem seviyesinde işlevsel bir HTEKA ile başlayarak daha fazla tasarım bilgisi ortaya çıktıkça alt seviyelere yaygınlaştırılarak devam eder.

HTEKA, tasarım faaliyetlerine yönelik bir güvenilirlik görevi olmasına rağmen başka amaçlarla da kullanılabilir. HTEKA veya ondan türetilmiş başka diğer analizler idame edilebilirlik, emniyet, kullanılabilirlik, LDA için ve bakım konseptinin detaylandırılması, hata tespit ve teşhisi için kullanılabilir. HTEKA’nın bu çok amaçlı kullanımı, aynı proje kapsamında gerçekleştirilen faaliyetlerin kopyalanmasının önlenmesi açısından planlama aşamasında dikkate alınmalıdır.

<big>'''3. LDA HTEA VE TASARIM YÖNELİMLİ HTEKA'''</big>

Tasarım yönelimli HTEKA’nın bir ürünün her bir komponentinin güvenilirliğini ve niceliğini belirlemesi gerekirken bu seviyede bir detay, bakım amaçları için her zaman gerekli değildir, Bakım faaliyetleri bütün komponentlere değil, daha yüksek seviyede bir kırılımda yer alan değiştirilebilir veya onarılabilir komponentlere odaklanmalıdır.  Bu nedenle, LDA HTEA tasarım yönelimli HTEA ile genel olarak tutarlı olmakla birlikte birebir aynı değildir.  Bu iki faaliyet arasında yeterli uyum, zamanlamanın uygunluğu ve izlenebilirliği sağlamak açısından sıkı ara yüzler tanımlanmalı ve koordinasyon gerçekleştirilmelidir.

Tasarım HTEKA ve LDA HTEA arasındaki temel fark, tasarım açısından farklı olan bazı hata türleri, nihayetinde aynı bakım faaliyetine yol açıyorlarsa LDA HTEA açısından gruplanarak tek bir hata modu gibi ele alınabilir.

<big>'''4. LDA HTEA VE İDAME EDİLEBİLİRLİK, BAKIM VE EMNİYET ANALİZLERİ'''</big>

İdame edilebilirlik, bakım ve emniyet analizleri gibi diğer analizler LDA HTEA’dan veri kullanabilir veya tasarım HTEKA’dan türetilebilir (ör. OSA, GMB ve PBA gibi). Mevcut çalışmalardan azami fayda sağlamak ve tekrarlamaları önlemek için bu analizlerin de HTEKA ve LDA HTEA ile sıkı bir biçimde koordine edilmesi gerekir.  

== EK-C HASAR VE ÖZEL OLAY ANALİZLERİ ==
'''<big>1. GENEL</big>'''

Sistemin kullanımı esnasında meydana gelebilecek özel olaylar ve hasarların sistem kullanımına etkileri ve bu durumlar karşısında uygulanması gereken bakım faaliyetlerinin belirlenmesi amaçlanmaktadır. Bu bakım faaliyetleri tüm bakım konseptini etkileyeceğinden analiz edilmeleri kritiktir. Özel olaylar ve hasar durumları tanımlandıktan sonra BGA kapsamında analiz edilirler. Elde benzer sistemlerle ilgili kullanım verilerinin olması durumunda, bu bilgilerin de mutlaka referans alınmaları gerekmektedir. Hasar ve özel olay analizleri, geliştirme safhasının kavramsal tasarım aşaması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.

Olası tehlikelerin tanımlandığı ve bu tehlikelerin analiz edildiği (tehlikelerin neler olduğuna, hangi ömür evresinde meydana gelebileceğine, ciddiyetine, meydana gelme olasılığına ve alınacak önlemlere ilişkin bilgileri kapsayan) emniyet analizleri kapsamında gerçekleştirilen Ön Tehlike Analizi sonuçları hasar ve özel olay analizi için girdi olacaktır.

Bakım uygulaması gerektiren bazı özel olay örnekleri;

* Sıcaklık limitlerinin aşılması
* Mekanik yükleme limitlerinin aşılması (örneğin aşırı torklama)
* Nakliye ömür evresinde izin verilen araç hız limitlerinin aşılması
* Korozif ortamda sistemin operasyonel kullanımı
* Kumlu ortamda sistemin kullanımı
* Yıldırım çarpması
* Sistemin entegre olduğu harici uçar platformun ani iniş yapması
* Harici nesnelerle çarpışma

Aşağıda hasar ve özel olay analizi kapsamında kullanılan terimler ve tanımları verilmiştir.
{| class="wikitable"
|'''Hasar (damage)'''
|''':'''
|Fonksiyonelliğin  kaybı ya da azalmasıdır (sistemin doğal arızaları hariç). Bir hasar durumu  karşısında tanımlanmış bir bakım görevi gerekecektir. Sistem özelinde hasarlar  belirlenirken gruplara ayrılabilir; örneğin, çizikler, oyuklar ve çatlakların  bir hasar ailesi olarak belirlenmesi gibi.
|-
|'''Harici sebep (external cause)'''
|''':'''
|Sistemin  kullanımından bağımsız olarak meydana gelen durumdur.
|-
|'''Dahili sebep (internal cause)'''
|''':'''
|Yalnızca  sistem kullanımının bir sonucu olan durumdur.
|-
|'''Özel olay (special event);'''
|''':'''
|Sistemin  ömrü boyunca meydana gelebilecek ve normal kullanım olarak düşünülmemiş  olaydır. Dış sebeplerden (meteorolojik olaylar gibi) ya da kullanım dışı  durumlardan (bir uçağın aşırı ivmelenmesi) kaynaklı olabilir.
|}
<big>'''2. ANALİZ SÜRECİ'''</big>

<big>'''2.1. ÖZEL OLAYLARIN TANIMLANMASI'''</big>

1. Adım; özel olayların tanımlanması kapsamında, ilk olarak bir olay yaratabilecek farklı sebeplerin listelenmesi gerekir. Olaylar harici veya dahili sebeplerden kaynaklı olabilir ve doğal olaylardan ya da insan hatalarından etkilenebilir. Tablo 13’de olayların sebeplerine örnekler verilmiştir.

Hasarlar ise, her bir durum için kritikliğinin ya da derecesinin verilemediği özel olaylardır. Bu nedenle, aynı yolla meydana gelebilen ya da aynı yolla tespit edilebilen hasarların da özel olay analizi kapsamında ele alınması gerekmektedir.

'''Tablo 13 Olayların Sebep Tiplerine İlişkin Örnekler'''
{| class="wikitable"
| colspan="2" |'''Sebep Tipleri'''
|'''Örnekler'''
|-
| rowspan="4" |Harici sebepler  (external causes)
|Doğal sebepler
|Meteorolojik sebepler
|-
|İnsan kaynaklı  sebepler
|Kullanım, taşıma vb.  hataları
|-
|Operasyon çevresinden  kaynaklı sebepler
|·          Elektromanyetik alan

·          Yüksek akım

·          Tozlu, kumlu ortam 
|-
|Nakliye, depolama  koşullarından kaynaklı sebepler
|·          Şok

·          Titreşim

·          Basınç
|-
| rowspan="2" |Dahili sebepler  (internal causes)
|Olağan dışı  kullanımdan kaynaklı sebepler
|Operasyon  limitlerinin dışına çıkılması - ani iniş, aşırı ivme gibi
|-
|İşlev  bozukluklarından kaynaklı sebepler
|Aşırı ısınma
|}
2. adım; özel olaylar tanımlandıktan sonra, bu özel olayın sistemin hangi ömür evresinde (kullanım, bakım, depolama, nakliye vb.) meydana geleceğinin tanımlanması gerekmektedir. Örneğin, kullanım ya da nakliye için hazırlık süresince elle taşımanın dış yüzeye olan etkisi ya da kullanım ömür evresinde sistemin mekanik kısımlarında meydana gelen beklenmeyen aşınmalar gibi.

3. Adım; özel olaylar belirlendikten sonra her bir olayın meydana gelme olasılığı analiz edilmelidir.

'''Tablo 14 Olayların Meydana Gelme Olasılıkları'''
{| class="wikitable"
|'''Puanlama'''
|'''Meydana gelme'''
|'''Açıklama'''
|-
|1
|Son derece düşük  ihtimal
|Meydana gelme  olasılığı sıfıra yakındır.
|-
|2
|Düşük ihtimal
|Meydana gelme  ihtimali pek mümkün değildir. Özel olaylar seyrek olarak meydana gelir.
|-
|3
|Ara sıra
|Arada sırada (sadece  birkaç özel olay) meydana gelebilir.
|-
|4
|Olası
|Meydana gelme  ihtimali orta seviyededir.
|-
|5
|Sık 
|Meydana gelme  ihtimali çok yüksektir.
|}
4. Adım; özel olayların meydana gelme olasılıklarına bağlı olarak, bu olayların bakım gerektiren ya da hiçbir analiz gerektirmeyen şeklinde gruplandırılmaları gerekmektedir.

'''<big>2.1. POTANSİYEL ARIZALARIN TANIMLANMASI</big>'''

Sistem tasarımında kullanılan teknolojinin değerlendirilmesi iki bakış açısı ile yapılabilir;

* Teknoloji yeni geliştirilen mi yoksa hali hazırda kullanılan bir teknoloji mi?
* Teknoloji hasara karşı dayanıklı mı yoksa hassas mı?

1. Adım; sistemin tüm alt sistem ve kalemleri için kullanılan teknolojiler tanımlanmalıdır. Tablo 15’te teknoloji seviyeleri ve açıklamaları ile bunların puanlama bilgileri verilmiştir. 


'''Tablo 15 Teknoloji Seviyeleri'''
{| class="wikitable"
|'''Puanlama'''
|'''Teknoloji seviyesi'''
|'''Açıklama'''
|-
|1
|İyi bilinen
|Birçok benzer projede  kullanılmış bir teknolojidir.
|-
|2
|Bilinen
|Birçok benzer projede  kullanılmış bir teknoloji olup, ilgili proje kapsamında modifikasyonlar söz  konusudur.
|-
|3
|Tamamen yeni
|Yakın zamandaki  projelerde kullanılmış bir teknoloji olup, çok az geri bildirim olmuştur.
|}
2. Adım; teknolojinin hassasiyetinin değerlendirilmesi. 1. Adım’da tanımlanan her bir teknoloji için, meydana gelebilecek olası hata tiplerinin tanımlanması gerekir. (Örneğin, metaller üzerinde meydana gelebilecek korozyon ve bu korozyonun tipleri, montaj yerlerinde meydana gelebilecek gerilme korozyonu gibi). Teknoloji hassasiyetinin değerlendirilmesi Tablo 16’de verilmiştir.

'''Tablo 16 Teknoloji Hassasiyetinin Değerlendirilmesi'''
{| class="wikitable"
|'''Puanlama'''
|'''Hassasiyet Derecesi'''
|'''Açıklama'''
|-
|1
|Aşırı düşük
|Bu teknoloji için  ürünün ömrü boyuncaki hasar ihtimali aşırı düşüktür.
|-
|2
|Düşük
|Bu teknolojinin hasar  ihtimali çok düşüktür.
|-
|3
|Orta
|Bu teknolojinin hasar  ihtimali düşüktür.
|-
|4
|Yüksek
|Bu teknolojide ürünün  ömrü boyunca muhtemelen hasar meydana gelecektir.
|-
|5
|Aşırı Yüksek
|Bu teknolojide ürünün  ömrü boyunca hasar meydana gelmesi durumu çok olasıdır.
|}
Adım 3; teknoloji tanımlanması ile hassasiyet oranı birlikte değerlendirilerek seçim eşiği (selection threshold) tanımlanır. Seçim eşiği de proje ihtiyaçlarına bağlı olarak belirlenebilir. Teknoloji-hassasiyet değerlendirmesi Tablo 17’da verilmiştir. 

'''Tablo 17 Teknoloji-Hassasiyet Değerlendirmesi'''
{| class="wikitable"
| colspan="2" rowspan="2" |
| colspan="5" |Hassasiyet Derecesi
|-
|1
|2
|3
|4
|5
|-
| rowspan="3" |Teknoloji Seviyeleri
|1
|1
|1
|2
|3
|4
|-
|2
|1
|2
|3
|3
|4
|-
|3
|2
|3
|4
|4
|4
|}
'''<big>2.2. ÜRÜNÜN ELEMAN YA DA KISIMLARININ TANIMLANMASI</big>'''

1. Adım; seçilen her bir özel olay için ürün ağacı üzerinden etkilenen kalemler tanımlanmalıdır.

2. Adım; seçilen teknoloji ve hasarlar için ürün ağacı üzerinden etkilenen kalemler tanımlanmalıdır.

3. Adım; bir önceki adımlarda tanımlanan ürün ağacı kalemleri için farklı tehditlere maruz kalmaları durumunda tasarımlarının analiz edilip gerekirse sonuçlar tasarım girdisi olarak tanımlanmalıdır.

<big>'''2.3. KRİTİKLİK ANALİZİ'''</big>

Her bir potansiyel hasarlanabilir kalem için, sistemin hizmet ömrüne olan etkisini ifade edecek şekilde kritikliklerinin değerlendirilmesi gerekmektedir. Bunun için aşağıdaki sorulara verilen cevapların herhangi biri ‘evet’ ise kritik olduğu değerlendirilebilecektir.

* Hasar emniyeti tehdit eden seviyelerde mi sonuçlanıyor?
* Hasar kullanılabilirliğin tehdit edilmesi ile mi sonuçlanıyor?
* Hasar önemli mülkiyet kaybı ile mi sonuçlanıyor?
'''<big>2.4. BAKIM GÖREV GEREKSİNİMLERİNİN TANIMLANMASI</big>'''

Tanımlanmış özel olaylar ve hasarlar karşısında gerçekleştirilmesi gereken bakım görevlerinin tanımlanması gerekmektedir.

Meydana gelebilecek her bir hasarın tespit edilmesinin, lokalizasyonunun, ölçülmesinin veya takibinin yapılması (görsel muayene, tahribatsız muayene gibi) ile sistemin fonksiyonunun eski haline getirilmesi (örneğin, sökme ve takma görevleri, onarım görevleri) kapsamında uygulanması gereken tüm faaliyetlerin belirlenmesi gerekmektedir. Bakım görevleri BGA kapsamında belirlenecektir. 

== EK-D LOJİSTİK İLİŞKİLİ OPERASYONLAR ANALİZİ ==
<big>'''1. GENEL'''</big>

Sistemin bakım ve onarım faaliyetlerine ek olarak, operasyon ve kullanımı ile ilgili durumlar da söz konusu olduğundan; sistemin kullanılabilirliği, kullanım esnekliği, mobilitesi gibi hususlara ilişkin sınırların tanımlanması ve bu gibi hususlara ilişkin bilgilerin ilgili el kitaplarında tanımlanması hem sistemin doğru kullanımı hem de saha verilerinin doğru bir şekilde toplanması açısından gerekmektedir. Diğer taraftan, bu hususlar garanti dönemini kapsayan uygulamaları da doğrudan etkileyecektir. Lojistik ilişkili operasyonlar sistemin direkt olarak kullanımının ya da bakımının dokümante edildiği ilgili dokümantasyonlara atanamasa da sistemin uygun kullanımı açısından önem taşımakta olup bu bilgilerin de dokümantasyonlara eklenmesi gerekmektedir.

Lojistik ilişkili operasyonların tanımlanması (personel, destek ekipmanı, sarf malzemeler, yedek parçalar, eğitim vb. gereksinimlerle ilişkili) lojistik analiz faaliyetleri için önemli girdiler oluşturacaktır.  Sistemin kullanım konsepti bilgileri ile birlikte, lojistik ilişkili operasyonların bazıları sistem ömür döngüsünün konsept safhasında göz önünde bulundurulurken, bazıları daha sonraki safhalarda (örneğin prototiplerin üretilmesiyle ya da BGA analizinin yapılmasıyla birlikte) ele alınabilir. Diğer taraftan, lojistik ilişkili operasyonlar analizi ihtiyaç olması halinde (tasarım değişikliği, modifikasyon vb) ilgili safhalarda güncellenebilecek bir analizdir.

'''<big>2. ÜRÜN KULLANIM DESTEĞİ</big>'''

'''<big>2.1. KULLANIMA HAZIRLIK</big>'''

Sistemi operasyona hazırlamak için sistemi kullanıma hazırlama kapsamında yapılması gereken bakım faaliyetleri dışında kalan diğer gerekli faaliyetlerin tanımlanması gerekmektedir. Sistemin doğru kullanım için yanal sistemlerin ve/veya parçaların hazırlanması buna örnek olarak verilebilir. Tipik kullanıma hazırlama görevleri servis görevleri olarak sınıflandırılabilir (bir uçağa özel bir ekipman ekleyerek keşif görevine hazırlamak gibi).

<big>'''2.2. YÜKLEME VE İNDİRME'''</big>

Kargo olarak taşıması olan her bir ürün için yükleme ve indirme prosedürleri projenin erken safhalarında analiz edilmelidir. Örnek olarak, ne tarz bir kargo taşımasının planlandığı, hangi boyut ve ağırlık parametrelerinin göz önünde bulundurulduğu, kargonun özel etkilere (ivme, manyetik alan, nem vb.) hassasiyeti olup olmadığı, yanlış kullanım sonucu kargonun kritik ve tehlikeli durumlara sebebiyet verip vermeyeceği, ne tarz bir kargo güvenliği gerektiği verilebilir. Ayrıca yükleme/indirme ve kargo güvenliği için özel bir ekipman gerekip gerekmediği, topraklama ihtiyacının olup olmadığı da değerlendirilmelidir.

'''<big>3. PAKETLEME, ELLEÇLEME, DEPOLAMA VE ULAŞTIRMA (PEDU)</big>'''

Tipik PEDU görevleri, paketleme, koruma, güvenlik önlemleri, depolama, taşıma, ulaştırma, çekme, istifleme, kaldırma olarak tanımlanabilir.

'''<big>3.1. PAKETLEME</big>'''

Paketleme ve paketten çıkarma için asgari düzeyde aşağıdakiler değerlendirilmelidir:

* Paketleme uzun süreli mi kısa süreli mi depolama için yapılacak?
* Taşıma yapılacak mı, yapılacaksa ne tarz bir taşımaya göre paketleme yapılacak?
* Depolama ve taşıma için özel bir sandık, kutu vb. gerekiyor mu?
* Depolama ve taşıma periyodunda sıradışı iklim koşulları için özel bir koruma gerekiyor mu?
* Taşıma ve depolama esnasında sistemin bir bakım görevini gerçekleştirmek için paketlemesini açmak ve tekrar paketlemek gerekiyor mu?
* Paketlemeyi açmak için destek ekipmanı ve tesisi ilgilendiren bir durum var mı?
'''<big>3.2. ELLEÇLEME</big>'''

Elleçleme için asgari düzeyde aşağıdakiler değerlendirilmelidir:

* Sistemi taşırken gerekli olan güvenlik önlem ve limitleri nelerdir?
* Sistemin normal kullanımından farklı olan çekme, vinçle kaldırma ve hareket ettirme için gerekli yönlendirmeler nelerdir?
* Sistem elleçlenirken ekstra ekipman ve malzemeler gerekiyor mu?

Taşıma, yükleme, onarım, bakım vb. için sistemin kaldırma konsepti belirlenmelidir. Ürünün hem kendisinin hem de komponentlerinin kaldırılması söz konusuysa onlar da düşünülmelidir.

'''<big>3.3. DEPOLAMA</big>'''

Ürünün fonksiyonelliğini depolama esnasında ve depolama sonrasında da garanti etmek için depolama prosedürleri analiz edilmeli ve dokümante edilmelidir. Depolama için asgari düzeyde aşağıdakiler değerlendirilmelidir:

* Depolama çözümü kısa döneme yönelik mi uzun döneme yönelik midir?
* Depolanacak ürünün özel bir hassasiyeti var mıdır?
* Depolanacak üründen komponent çıkarmak ve bu komponentleri özel koşullar altında ayrıca depolamak gerekiyor mu?
* Depolama esnasında sıradışı  iklim koşullar var mı?
* Depoya giriş için özel teknikler (temizleme, koruma, özel parçaların çıkarılması vb.) gerekiyor mu?
* Depodan çıkarma ve tekrar depoya koyma için özel teknikler (fonksiyonel kontroller, kullanım hazırlığı vb.) gerekiyor mu?
* Depolama periyodu için ne tarz güvenlik önlemleri gerekiyor?  (ör. Hareketli parçaları bloklamak, ışığa karşı koruma sağlamak vb.)
* Depolama zamanı ürünün ömründen sayılacak mı?
<big>'''3.4. İSTİFLEME'''</big>

Depolama ve taşımanın bir parçası olan istifleme kapsamında gerekli güvenlik gereksinimleri tanımlanmalıdır. Depolamada itme vb. durumların gerçekleşme ihtimali varsa bu durumda sistem davraşının ne olacağı değerlendirilmelidir.

'''<big>3.5. TAŞIMA</big>'''

Taşıma için asgari düzeyde aşağıdakiler değerlendirilmelidir:

* Taşımaya hazırlık ve taşıma sonrası için gereken süre ve efor nedir?
* Taşımaya hazırlık ve taşıma sonrası için gereken personel, ekipman, sarf malzemesi ve tesisler nelerdir?
* Özel koşullarda taşıma için gereken çevresel ve güvenlik gereksinimleri nedir?
* Taşıma periyodu için gerekli servis aksiyonları var mıdır?
* Taşıma için üründen komponent çıkarmak gerekli midir?
* Taşıma sandığı konsepti olacak mı?
* Taşımada kızak ve palet kullanımı olacak mı?
'''<big>3.6. BAĞLAMA</big>'''

Bağlama kısa ya da uzun vadeli olarak, ürünü bir yere sabitlemek veya bir taşıma aracının içinde sistemin güvenli olarak bulunmasını sağlamaktır. Özel teknikler (ör. Denge ağırlığı, bağlama noktaları, bağlama esnasında gerekecek ekipman vb.) de değerlendirilmelidir.

'''<big>4. ENVANTERDEN ÇIKARMA VE GERİ DÖNÜŞÜM</big>'''

Sistemin (mühimmat, silah sistemi, destek ekipmanı vb.) envanterden çıkarma prosedürlerinin tanımlanmış olması gerekmektedir. Ayrıca tek kullanımlık sistemlere ait taşıma saklama kutuları için uygulanabilir olması için geri dönüşüm metotları da tanımlanmalıdır.

'''<big>5. LOJİSTİK İLİŞKİLİ OPERASYONLAR İÇİN KONTROL LİSTESİ</big>'''

Tüm faaliyetler (ayarlama, sızdırma, kalibrasyon, kontrol, temizleme, koruma, taşıma sandığı konsepti, tuzdan arındırma, envanterden çıkarma, kaldırma, yükseltme, kargoya yükleme, paketleme, geri dönüşüm, ikmal, güvenlik önlemleri, istifleme, depolama, taşıma, kargodan indirme, paketlemeyi açma, vinçle kaldırma vb.) ve bu faaliyetlerin sistemin hangi ömür evresinde gerçekleştirileceği/uygulanacağı belirlenmeli ve özel bir destek ekipmanı gerekliliği ile bu faaliyetlerin tasarım üzerinde bir etkisi olup olmadığı kontrol edilmelidir.

== EK-E PLANLI BAKIM PROGRAMI GELİŞTİRME ==
'''<big>1. GENEL</big>'''

Planlı bakım programının geliştirilmesi ile amaçlanan, planlı bakım görevlerinin yerine getirilmesi kapsamında ürünün Operatör Bakım Planının (Operator Maintenance Plan) geliştirilmesi için süreçleri ve kuralları tanımlamaktır. Planlı bakım görevleri de aslen Önleyici Bakım Görev Gereksinimlerinden (PMTR - Preventive Maintenance Task Requirements) ortaya çıkmaktadır.

Önleyici Bakım Görev Gereksinimleri ile ilişkili sistem ya da ekipman/kalemler otomatik olarak LDA adayı kalem olacaktır. LDA adaylarına atanmış tüm Planlı Bakım Görev Gereksinimleri daha sonra BGA’ya (bkz.EK-G BAKIM GÖREV ANALİZİ) tabi tutulacaktır. Planlı bakım programı geliştirme faaliyeti geliştirme safhasından başlar. Diğer taraftan ihtiyaç olması halinde (tasarım değişikliği, modifikasyon vb) ilgili safhalarda güncellenebilecek bir analizdir.

'''<big>2. ANALİZ YÖNTEMLERİ</big>'''

Önleyici Bakım Görev Gereksinimlerinin belirlenmesi kapsamında üç farklı analiz metodu tanımlanmıştır. (Analizler hakkında detaylı bilgi için; bkz. ‘S4000P International specification for developing and continuously improving preventive maintenance’.)

* '''Sistem analizi (System analysis)'''

Ekipman ve kalemleri de kapsayan sistem için uygulanabilir ve etkili Önleyici Bakım Görev Gereksinimlerinin geliştirilmesi için kullanılan bir analiz yöntemidir. Ürün kırılım yapısına bağlı olarak, bu sistemler tasarım HTEKA’sına göre şeffaf bir şekilde analiz edilir. Sistemin veya analiz edilen bir kısmının bakım yapılamaz olarak varsayılması durumunda, bununla ilgili geri bildirim mutlaka sağlanmalıdır.

* '''Yapı Analizi (Structure Analysis)'''

Ürünün mekanik yapısı için uygulanabilir ve etkili Önleyici Bakım Görev Gereksinimlerinin tanımlanması kapsamında yapılan analizdir. Analiz kapsamında, yorulma analizi sonuçları, çevresel bozulma (environmental deterioration) parametreleri, kazara oluşan hasar etkileri (accidental damage impacts) göz önünde bulundurulur.

* '''Bölgesel Analiz (Zonal Analysis)'''

Ürünün tipine ve kullanım alanına göre bağlı olarak yapılabilecek analizler;

Standart Bölgesel Analiz

Gelişmiş Bölgesel Analiz

Yüksek yoğunluklu radyasyon alanları analizi

'''<big>3. ÖNLEYİCİ BAKIM GÖREV GEREKSİNİMLERİ İÇİN EŞİKLER, ARALIKLAR VE TETİKLEYİCİ OLAYLAR</big>'''

Tek bir Önleyici Bakım Görev Gereksinimi için, planlı eşiklerin, aralıkların ya da tetikleyici olayların farklı tipleri seçilebilir;

* Bir kere yap eşikleri (perform once); örneğin silah sistemi üzerinden belirli sayıda füzenin ateşlenmesi sonrasında tetik mekanizmasının kontrol edilmesi ya da belirli bir süre kullanım sonrasında silah sistemi üzerinde bulunan özel vidaların torklarının kontrol edilmesi şeklinde tanımlanan bakım görevi. Periyodik aralıklarla tanımlanan bakım görevleri birbirine paralel de olabilir; belirli bir kullanım süresi sonunda silah sistemi üzerinde bulunan özel vidaların değiştirilmesi ve aynı zamanda her beş yılda bir kez ilgili vidaların değiştirilmesi gibi.

* Periyodik aralıklar (Periodical); örneğin, tanımlanmış her bir kullanım süresi sonunda (örneğin 3 yılda bir) silah sistemi üzerinde bulunan özel vidaların değiştirilmesi.
* Bir kere yap eşikleri ile periyodik aralıkların kombinasyonu; örneğin 500 döngülük kullanım sonrası ilk muayenenin yapılması (bir kere yap eşiği-PO) ve sonrasında her 1000 döngülük kullanım sonrası periyodik muayene.
* Periyodik aralıklar ile tetikleyici olayların kombinasyonu; örneğin her 1000 döngülük kullanım sonrası periyodik muayene şeklinde tanımlanan bakım görevi, periyodik yapılan bu muayeneler esnasında karşılaşılan bir olay sonucu periyodik bakım görevlerinin her 800 döngüde yapılmasının bakım görevi olarak tanımlanması.

Bakım görev gereksinimleri belirlenirken, sistemin tasarım ve geliştirmesi için esas alınan kullanım parametreleri kapsamında kullanım durumu mutlaka değerlendirmelidir. Önleyici Bakım Görev Gereksinimleri için belirlenecek aralıklar aşağıda belirtilenlere bağlı olabilir;

* Ürün kullanım parametreleri (örneğin, kullanım saatleri, döngü, katedilen mesafe gibi)
* Takvim bazlı parametreler (ana aralık olarak takvim bazlı parametreler seçilirse eğer ürünün gerçek kullanım yoğunluğu, planlı ürün bakım eforuna etki etmeksizin değişebilir. Diğer taraftan gerçek kullanım yoğunluğu, kullanıma yönelik olan ana aralıklar ile daha iyi gösterilecektir.)

* Ürün kullanımı ve takvim bazlı parametrelerin kombinasyonu
* Tanımlanmış etkili ve uygulanabilir her bir önleyici bakım görev gereksiniminin, fonksiyonel hata etkisinin kritikliğine göre en kötü senaryo karşısında kendine özgü durumu vardır. Kritiklik kategorisi, aralıkların artmasına ya da azalmasına karar vermeyi mümkün kılacaktır.

* Tanımlı önleyici bakım görev gereksinimleri tek bir bakım seviyesinde ya da birden fazla bakım seviyesinde gerçekleştirilebileceğinden, aralıklar tanımlanırken bu husus da göz önünde bulundurulmalıdır.
* Aralıkların uzatılması hata sebeplerinin ortaya çıkarılamaması riski artıracak fakat bakım maliyetleri azalacaktır.
* Aralıkların azaltılması durumunda ise hata sebeplerinin (Failure Causes) ortaya çıkarılması ile ilgili risk azalacaktır ancak bakım maliyetleri artacaktır.
* Fonksiyonel hata etkisi emniyet ile ilgili olan durumlarda aralık uzatılmamalıdır.
'''<big>4. TANIMLANACAK ÖNLEYİCİ BAKIM GÖREV GEREKSİNİMLERİNİN (PMTR) BELİRLENMESİ İÇİN KULLANILABİLECEK KAYNAKLAR</big>'''
* Yasal düzenlemelerden gelen gereksinimler
* Emniyet Analizi/hata ağacı analizinden gelen gereksinimler
* Yapısal muayeneler ile ilgili yorulmalar
* Üretici firma tarafından belirlenen gereksinimler
* Mühendislik yaklaşımları
* Diğer projelerden edinilen tecrübeler
* Depolama kriterlerine bağlı öngörülen planlı faaliyetler

İlerleyen analiz aşamalarında ortaya çıkan potansiyel bakım problemlerinin tespit edilebilmesi açısından, görev uygulanabilirliği ve etkinliği ile ilgili yapılmış olan varsayımları doğrulayabilmek için geri bildirimlerin sağlanması önemlidir.

'''<big>5. KULLANICI BAKIM PROGRAMININ GELİŞTİRİLMESİ</big>'''

Bir önleyici bakım görev gereksiniminin tip ve değer olarak bir tane ya da tip ve değerin kombinasyonlarından oluşan iki ya da daha fazla aralığı vardır. Eğer birden fazla aralık tanımlanmışsa, kullanım senaryosuna bağlı olarak ilk gelen aralık ile bakım başlatılır.

Her bir önleyici bakım gereksiniminin başlangıç aralık tipleri ve değerleri ile birlikte bakım seviyelerinin, personel, destek ekipmanı, yedek parça, teknik dokümantasyon gibi gerekli kaynakların belirlenmesi için BGA ve OSA kapsamında analiz edilmesi gerekmektedir.

Önleyici bakım görev gereksinimlerinin dokümantasyonunun ve sistem entegrasyon standartlarına göre geçerlilik onayının tamamlanmasından sonra, daha sonraki sistem bakım programı için ana görev paketlerinin aralıklarının tanımlanması ve asgari aşağıdaki hususların dokümante edilmesi gerekmektedir;

* Kullanım senaryoları ve sapmalar
* Ana görev paketlerinin aralık tipleri ile ilgili alınan kararlar/tahminler
* Aralıkların uyarlanması için hesaplama kuralları (örneğin, güvenilirlik değerleri ile kullanım saatlerinin birlikte değerlendirilmesi durumu)

Örneğin;

Bir silah sistemi için emniyet ilişkili bir önleyici bakım görev gereksinimi kapsamında, her 600 saatlik kullanım saatinde görsel muayene yapılması durumunda, herhangi bir ‘bir kez yap eşiği’ (perform once threshold) olmadan periyodik aralık 600 kullanım saati olacaktır. Önleyici bakım görev gereksinimi kategorisi de emniyet olacaktır.

Kullanım senaryosu; Silah Sisteminin bir takvim yılı içerisinde azami 1000 kullanım saati ile kullanılacağı planlanmıştır. Ana görev paketi için aralık tipinin kullanıcı tarafından takvim bazlı olmasına karar verilmiştir (Emniyet kritik durum göz önünde bulundurulduğunda, 600 saatlik muayene gerekliliğini sağlayacak şekilde her altı ayda bir muayene yapılması, senede bir kez de kapsamlı muayene yapılması şeklinde).

Bu kullanım senaryosundaki limitlere göre, birinci planlı görevin, 600 kullanım saatlik periyodik aralığı aşmayan ana görev paketleri kapsamında yerine getirilmesi gerekmektedir. Bu nedenle planlı görevin 500 kullanım saatini kapsayan her altı ayda bir yerine getirilmesi gerekir. Azami 1000 kullanım saati ile ilişkili her yıl gerçekleştirilecek bir görevin seçimine emniyet açısından aralık aşımı söz konusu olduğu için izin verilmemelidir.

Tüm önleyici bakım görev gereksinimleri için BGA kapsamında aşağıdaki hususların değerlendirilmesi gerekmektedir;

* Tek bir faaliyetin ve/veya bakım görevlerinin potansiyel karşılıklı bağımlılık durumu (örneğin, bir bakım görevi başlamadan bir diğerinin tamamlanmış olması gerekliliği)
* Potansiyel bir zaman tasarrufu, bir kez erişim sağlandıktan sonra görevlerin yerine getirilmesi ile sağlanabilir. (Örneğin; sistemde bulunan bir kapak açıldığında gerekli tüm görevlerin yerine getirilmesi)
* Sürenin etkili kullanılabilmesi için paralel yapılması gereken görevlerin mutlaka göz önünde bulundurulması
* Planlı bakım görevleri her zaman ardışık olarak yerine getirilmez, birbirine paralel olabilir ya da kısmen birbirinden bağımsız olabilirler, bu husus da göz önünde bulundurulmalıdır.

Diğer taraftan, farklı bakım seviyeleri, periyodik aralıklar ve bir kez yap eşikleri (eğer varsa) ile tanımlanan önleyici bakım görev gereksinimlerini etkileyeceğinden bu hususların da OSA kapsamında dikkate alınması gerekmektedir.

Önleyici bakım görev gereksinimleri, proje kapsamında uygulama kolaylığı sağlanacağı değerlendirildiği durumda üç ana grup altında toplanabilirler.

* Sistemin kullanıma/göreve başlamasından önce
* Sistemin kullanım veya görevine anlık kısa bir ara verilmesinden sonra
* Ürünün kullanım veya görevini tamamlanmasından sonra
'''<big>6. GÜVENİLİRLİK MERKEZLİ BAKIM (GMB) ANALİZİ YAKLAŞIMI</big>'''

GMB sistemin doğal güvenilirliğini kaynakların minimum israfı ile sürdürebilmesi için gerekli olan planlı bakım görevlerinin tanımlandığı analiz yöntemidir.

Sistemdeki olası hataların, sırasıyla emniyet ve çevre, görev ve kullanım ile maliyet üzerine olan etkileri incelenir. Buna göre gerçekleştirilecek faaliyetlere ilişkin önceliklendirme yapılmış olur. GMB hataların öncelikle planlı bakım faaliyetleri ile önlenmesini ve önlenemiyorsa da hataların etkilerini kabul edilebilir seviyeye indirmeyi amaçlayan güvenilirlik odaklı LDA faaliyetidir.

Şekil 19’da GMB kapsamında hata türlerine bağlı olarak bakım görevlerinin tanımlanması ile bu görevlerin analizinin yapılması için BGA’ya olan girdiler gösterilmiştir.
[[Dosya:Şekil19GMB – BGA Arayüzü.jpg|alt=|sol|küçükresim|650x650pik|Şekil 19 GMB – BGA Arayüzü]]




































== EK-F ONARIM SEVİYESİ ANALİZİ (OSA) ==
'''<big>1. GENEL</big>'''

OSA maliyet, güvenilirlik değerleri, bakım yapılabilirlik/test edilebilirlik kısıtlamaları ya da hazır bulunurluk gibi amaçların da gözetildiği; onarma, yenisi ile değiştirme gibi kararların alındığı ve ilgili görevler için bakım seviyelerinin belirlendiği analiz çalışmasıdır. Analiz sonuçları bakım görevlerini ve bu görevlerle ilişkili ekipman, personel, yedek parça gibi kaynakları doğrudan etkiler. OSA’nın amacı optimum bakım çözümüne karar vermektir.

Bir bileşenin doğasından kaynaklı olarak onarılabilir ya da onarılamaz olduğu bilgisi BGA’da belirlenir. OSA’nın ilk adımı ise bu kalemlerden onarılabilir olanların ekonomik maliyet kriterleri ile ekonomik olmayan kriterlerin göz önünde bulundurularak analiz edilmesidir. BGA’da onarılabilir olarak belirlenen kalem için OSA sonrasında değerlendirme kriterlerine göre yenisi ile değiştirilmesi kararı verilebilir.

OSA yaparken her bir seviyedeki, her bir bakım merkezindeki imkân ve kabiliyetlerin neler olduğunun önceden bilinmesi gerekir. Hat üzerinde sökülen ünitelerden başka, bunların içinin nerelerde açılabileceği, onarım sırasında üzerlerinde parça değişikliği yapılıp yapılmayacağı, onarımı mümkün değilse nerede envanterden çıkarılacağı belirlenir.

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.

'''<big>2. ANALİZ SÜRECİ</big>'''

Sistemler için onarım seviyeleri genellikle ikiye veya üçe ayrılır:

a)    Operasyonel seviyede (O-level) bakım-onarım

b)    Ara seviyede (I-level) bakım-onarım

c)    Fabrika/Depo seviyesinde (D-level) bakım-onarım

Analiz sonuçlarına göre her bir ekipman için, “Kaynak, Bakım ve Onarım” (Source, Maintenance and Recoverability – SM&R codes) kodlaması yapılır. Buna göre; bir ekipmanın arızası olduğunda onarım yapılıp yapılmayacağı, yenisiyle değiştirilip değiştirilmeyeceği, onarılamıyorsa envanterden çıkarılıp çıkarılmayacağı bilinir.

Analiz, yedek parça ile arızayı tespit etmek ve onarımını gerçekleştirmek için gerekli olan destek ekipmanı, personel, eğitim, teknik dokümantasyon gibi başlıca ekonomik maliyet faktörleri kullanılarak yapılır. Ayrıca, kullanıma hazır olma gereksinimleri, güvenilirlik, bakım yapılabilirlik gibi ekonomik olmayan faktörler de göz önünde bulundurulmalıdır. Bu faktörlerin, sistem için gereksinim önceliklendirmesine göre değerlendirilmesi yapılmalıdır. OSA süreç adımları Tablo 18’de yer almaktadır.

'''Tablo 18 Onarım Seviyesi Analizi Süreç Adımları'''
{| class="wikitable"
|'''İŞLEM ADIMI'''
|'''TANIMI'''
|'''GİRDİLER'''
|'''ÇIKTILAR'''
|-
| rowspan="2" |1
|Onarım Seviyesi  Analizi yapılacak donanım kalemleri belirlenir
|<nowiki>- Kırılımlı Parça  Listesi</nowiki>
|<nowiki>- Analizi yapılacak  ekipman ve cihazların listesi</nowiki>
|-
|Donanım ürünlerinin  üst seviye, alt seviye kırılımları saptanır. Parça listesindeki ürünler ‘onarılabili”,  “onarılamaz” ‘arıza yedeği’ vb. kategorilere ayrılır.
|<nowiki>- Üretici firmalardan  sağlanan teknik dokümanlar</nowiki>

- Kırılımlı Parça  Listesi

- Tasarım dokümanları
|<nowiki>- Analizi yapılacak  ekipman ve cihazların ‘yeniden tasnif edilmiş’ listesi</nowiki>
|-
| rowspan="5" |2
|Sökme ve takma  işlemlerinin hangi bakım-onarım seviyesinde yapılacağı belirlenir
|<nowiki>- Analizi yapılacak  ekipman ve cihazların yeniden tasnif edilmiş listesi</nowiki>
|<nowiki>- SM&R kodunun  ilgili hanesi doldurulur.</nowiki>
|-
|Yönetmelikler, lisans  hakları, bilgi güvenliği vb. kısıtlamalar incelenir
|<nowiki>- Üretici firmaların açıklamaları</nowiki>

- Üretici firmalardan  sağlanan teknik dokümanlar

- Teknik ve idarî  yönetmelikler
|Kısıtlamalarla ilgili  sorulara verilen “Evet” veya “Hayır” şeklindeki yanıtlar
|-
|Tesis (atölye), bakım  destek ve test ekipmanı, iş gücünün sahip olması gereken yetenekler  belirlenir.

  İş güvenliği, çevrenin korunması vb.  etkenler irdelenir.
|<nowiki>- Alan uzmanlarının,  sistem mühendislerinin ve diğer Proje paydaşlarının görüş ve  değerlendirmeleri</nowiki>
|Gereksinimlerle  ilgili sorulara verilen “Evet” veya “Hayır” şeklindeki yanıtlar
|-
|Operasyonel  seviyedeki uzun süren bakım faaliyetlerinden bilhassa ‘sök-tak’ işlemleri  (varsa) belirlenir.
|<nowiki>- Yapılan ölçümler</nowiki>

- Mühendislik  tahminleri

- (Varsa) Ürünle  ilgili geçmişte tutulmuş kullanım-bakım kayıtları
|Uzun süren söküm  takım faaliyetleriyle ilgili sorulara verilen “Evet” veya “Hayır” şeklindeki  yanıtlar
|-
|İhtiyaç  makamının/kullanıcının operasyonlara ve bakım faaliyetlerine yönelik  stratejileri incelenir
|<nowiki>- Gizli gizlilik  dereceli ekipman ve malzemelerin listesi</nowiki>
|İhtiyaç makamının/kullanıcının  operasyonel stratejisiyle ilgili sorulara verilen “Evet” veya “Hayır”  şeklindeki yanıtlar
|-
| rowspan="4" |3
|Hangi seviyede envanterden  çıkarılacağı belirlenir
|<nowiki>- Onarılabilen ve  onarılamaz ekipman ve cihazların listesi</nowiki>

- Tasfiye edilecek  olanların hangi seviyede envanterden çıkarılacağının bilgisi
|<nowiki>- Devre dışı  bırakılacak ürünler için, hangi İhtiyaç makamının/kullanıcının ya da firmanın  yetkili olduğu belirlenir.</nowiki>

- SM&R kodunun  ilgili hanesi doldurulur.
|-
|Onarılabilenler  belirlenir
|<nowiki>- Üretici firmaların tavsiyeleri,  çözüm önerileri</nowiki>

- Güvenilirlik, idame  edilebilirlik ve kullanıma hazır olma sonuçları
|<nowiki>- Onarılabilen  ekipman ve cihazların listesi </nowiki>
|-
|Daha masraflı olduğu  için onarımı tercih edilmeyenler belirlenir
|<nowiki>- MTBF değerleri</nowiki>

- Yeni ürünün birim  fiyatı

- Yeni ürünün  piyasada bulunup bulunmadığı bilgisi
|<nowiki>- Onarılmayıp,  operasyonel veya depo seviyesinde envanterden çıkarılacak olan ekipman ve  cihazların listesi</nowiki>
|-
|Operasyonel seviyede onarılabilecek  olanlar belirlenir
|<nowiki>- Birim fiyatının çok  yüksek olduğu bilinen ürünlerin listesi </nowiki>

- Operasyonel  seviyedeki onarım imkânları ve maliyeti
|Operasyonel seviyede,  ara seviyede ve depo seviyesinde onarılabilecek  ekipman ve cihazların listesi
|-
| rowspan="3" |4
|Onarım seviyesi  belirlenir
|<nowiki>- D-seviyesi bakım-onarım  merkezlerinin imkânlarının değerlendirilmesi</nowiki>
|<nowiki>- D-seviyesi bakımın  (onarımın) nerede yapılacağı belirlenir</nowiki>

- SM&R kodunun  ilgili hanesi doldurulur.
|-
|Depo seviyesi için  kurallar ve kısıtlamalar belirlenir
|<nowiki>- Yönetmelikler</nowiki>

- Lisans hakları,  bilgi güvenliği vb. kısıtlamalar
|<nowiki>- Depo seviyesinde,  yurt içinde veya yurt dışında onarım yapılacak  olan ekipman ve cihazların listesi</nowiki>
|-
|Maliyetlere bakılır
|<nowiki>- Yurt içi  merkezlerdeki bakım-onarım maliyeti</nowiki>

- Yurt dışı  merkezlerdeki bakım-onarım maliyeti
|<nowiki>- Belirlenmiş olan yurt  içi ve yurt dışı bakım-onarım merkezleri</nowiki>
|}
Örneğin, bir sistem için kullanıma hazır olma gereksinimi kritik ise, maliyet hususları ikinci planda kalabilir ve onarımın daha maliyet etkin olduğunun değerlendirilmesine rağmen, arızalı kalemin yenisi ile değiştirilmesi kararı verilebilir. MTTR değeri yüksekse arızalı sistemin onarımı maliyet etkin olsa bile, kullanıma hazır olma gereksinimini sağlayabilmek için arızalı kalemin yenisi ile değiştirme kararı verilebilir. Ya da bir sistemin kullanım konsepti düşünüldüğünde arıza oranı düşükse (örneğin, 10 yıllık raf ömrü olan sistemin yılda 300 saat kullanılmasının öngörüldüğü ve MTBF değerinin 4000 saat olması gibi) ve onarım maliyeti için gerekli kaynaklar düşünüldüğünde malzeme maliyetinin üzerine çıkıyorsa alınan karar yenisi ile değiştirilip arızalı parçanın onarımı değil elden çıkarılması olmalıdır.
{| class="wikitable"
|OSA’nın, projenin erken safhalarında  başlanması durumunda test edilebilirlik özellikleri, modülerlik,  erişilebilirlik gereksinimlerinin tanımlanması ile tasarıma etki  sağlanabilir.
|}
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.

Örneğin; ürün ağacında sistemin bir alt seviyesinde bulunan ‘elektronik komple’ arızası olayının meydana gelmesi durumunda BGA kapsamında tanımlanan düzeltici görevin (kalemin onarılabilir olduğu durum için) aşağıdaki gibi olduğu varsayılsın;

Düzeltici Görev 1; Arızalı olan elektronik komplenin yenisi ile değiştirilmesiyle sisteminin onarımı

Düzeltici Görev 2; Doğrudan arızalı elektronik komplenin onarımı ile sistem onarımının yapılması

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.

'''<big>2.1. OSA VERİLERİ</big>''' 

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.

'''<big>2.2. BAKIM SEVİYELERİNİN BELİRLENMESİ</big>'''

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.

Tablo 19’de bakım seviyeleri ve bu seviyeler kapsamında tanımlanabilecek görevlere ilişkin örnekler verilmiştir. Seviye isimleri, seviyeler için tanımlanacak yetkiler sisteme/projeye özgü kararlar olup tablo sadece örnekleme amaçlı olarak verilmiştir.

'''Tablo 19 Bakım Seviyeleri ve Tanımlı Görevlere İlişkin Örnekler'''
{| class="wikitable"
|'''Seviye Adı'''
|'''Amaç'''
|'''Tanımlı Bakım Görevleri'''
|-
|'''Seviye  1'''
|Sistemin hazır halde  olmasının sağlanmasıdır.
|·  Kullanıma  hazırlama (genel bakım)

·  Kullanım  öncesi ve sonrası yapılacak muayeneler, fonksiyonel kontroller

·  Arıza  tespiti

·  Önleyici  bakım faaliyetleri

·  Düzeltici  bakım (yenisi ile değiştirme ve ayarlama gerekiyorsa yapılması - kalibrasyon  vb.)

·  Basit  modifikasyonlar
|-
|'''Seviye  2'''
|Sistemin hazırda bulunma  seviyesini olası en yüksek seviyede tutmayı sürdürmektir. (Seviye 1  kapsamında yenisi ile değiştirilen arızalı alt sistem, HDB ve modüllerin  onarım faaliyetleri yapılabilir. Hem önleyici hem koruyucu bakımları  içerebilir. 
|·  Modül  ve alt sistem onarımları

·  Orta  seviye yapısal onarımlar

·  Büyük  planlı muayeneler

·  Orta  seviye modifikasyonlar

·  Seviye  1 için teknik destek

·  Mühendislik  verileri ile ilişkili yazılım hizmeti

·  Ürünün  korunması
|-
|'''Seviye  3'''
|Sistemin hazırda bulunma  seviyesini - mühendislik desteği de sağlayarak - olası en yüksek seviyede  tutmayı garanti etmektir. Tüm onarım ve büyük bakımlar yapılacaktır. Tasarımı  ya da operasyonel yeteneği iyileştirmek için büyük modifikasyonlar  yapılabilir.
|·  Özel  yetenek veya ekipman gerektiren onarımlar

·  Büyük  yapısal onarımlar

·  Büyük  planlı muayeneler

·  Kapsamlı  modifikasyon ve güncelleme programları

·  Seviye  1 ve 2 için teknik destek

·  Yazılım  modifikasyonları
|}
'''<big>2.3. BAKIM ÇÖZÜM ÖNERİSİNİN OLUŞTURULMASI</big>'''

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.


Örnek OSA tablosu:
[[Dosya:TSSÖDYP06.ÖRNEK OSA.jpg|alt=|sol|küçükresim|772x772pik]]

































{| class="wikitable"
|Not  1: "PAOKD" SM&R kodu açıklaması şöyledir:

▪  Malzeme belli bir süre kullanmak üzere satın alınmış ve depolanmıştır. ( PA -  - - )

▪  Malzeme operasyonel bakım seviyesinde sökülüp takılır ve değiştirilir. ( - -  O - - )

▪  Tamir edilebilir malzemedir. Tümüyle tamiri anlaşmalı yüklenici tesislerinde  yapılır. ( - - - K - )

▪ Malzemenin tamir maliyeti artarsa ve yenisiyle  değiştirmenin maliyetini geçerse, hurdaya ayrılır. ( - - - - D)
|Not 2: "PAOZZ" SM&R kodu açıklaması  şöyledir:

▪ Malzeme belli bir süre kullanmak üzere satın  alınmış ve depolanmıştır. ( PA - - - )

▪ Malzeme operasyonel bakım seviyesinde sökülüp  takılır ve değiştirilir. ( - - O - - )

▪ Tamir edilemeyen malzemedir. Yenisiyle  değiştirilir. ( - - - Z - )

▪ Malzeme hurdaya ayrılır. ( - - - - Z )
|}






== EK-G BAKIM GÖREV ANALİZİ (BGA) ==
'''<big>1. GENEL</big>'''

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.

Sistemde/ekipmanlarda herhangi bir arızanın ortaya çıkması mümkün olduğunca engellenmeli (önleyici bakım), arıza ortaya çıktığında ise çok kısa bir süre içerisinde müdahale ederek (düzeltici bakım) yeniden çalışır duruma getirilmelidir.

Bakım faaliyetleri ekipmanın onarım yapılmasını da kapsar. Ancak, operasyonel seviyedeki onarım işleri, ekipmanın yeniden çalışır hâle getirilmesi maksadıyla yapılacak temel müdahalelerle (arıza tespit, sökme, takma ve son test faaliyetleriyle) sınırlıdır. Depo seviyesinde ise, onarım yapılması gerekli görülen ekipmanlar için ihtiyaç duyulan her türlü imkân bulunmaktadır.

Planlı ve plansız bakım görevleri belirlendikten sonra, bu işlerin yapılabilmesi için gerekli personelin, eğitimlerinin, tesis veya atölye ihtiyaçlarının, test ekipmanlarının ve bakım sırasında ihtiyaç duyulabilecek malzemelerin belirlenmesi gerekir.

Bakım görevleri, işlem adımlarına ayrıştırılarak her bir adımın ne kadar sürede tamamlanacağı hesaplanır. Tüm bu verilerle, maliyet etkinliğinin sağlanmasına ve operasyonların olumsuz şekilde etkilenmeyeceği zaman aralıklarının belirlenmesine çalışılır.

Sistemlerin yazılım konfigürasyonunda bulunan geliştirilmiş yazılım kodlarının tamamı, kullanılan ticarî ve açık kaynak yazılım paketlerinin hepsi, vb kalemler için bakım planlaması garanti kapsamında yüklenici firmadan alınacak destekle sınırlı tutulmalıdır. Ancak, kritik görülen hususlar için ek tedbirlere ve düzenlemelere baş vurulmalıdır.

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.

'''<big>2. ANALİZLER</big>'''

'''<big>2.1. BAKIM GÖREVLERİNİN BELİRLENMESİ</big>'''

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.

Hata durumları, arızalar, özel olaylar vs. bakım görevlerini belirlerken ana etmenler olacaktır (HTEKA, özel olay ve hasar analizi, GMB). Ayrıca yazılım yükleme gibi durumlardan kaynaklı görevler de tanımlanabilir.
[[Dosya:TSSODYP06.20.jpg|alt=|sol|küçükresim|450x450pik|Şekil 20 Bakım Görevlerinin Belirlenmesi]]

























Ö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.

'''<big>2.2. BAKIM GÖREV YAPILARININ OLUŞTURULMASI</big>'''

Görev yapıları oluşturulurken görevler analiz faaliyetinde kolaylık sağlaması açısından iki sınıfa ayrılır.

'''Düzeltici görevler (rectifying tasks);''' Her düzeltici bakım görevi arıza, hata veya özel olay gibi bir durumdan dolayı gerçekleştirilir. Doğrudan ilgili olayı çözmek amaçlı (event solver) yapılan herhangi bir bakım faaliyeti düzeltici görev olarak adlandırılabilir. Hem alt görevleri hem de referans destek görevlerini kapsar.

Örneğin;
{| class="wikitable"
|'''Olay'''
|'''Düzeltici görev'''
|-
|Hata/Arıza     
|Onarım veya  yenisi ile değiştirme prosedürü
|-
|Özel Olay
|Muayene/arıza  yeri
|-
|Sistem ömrünün  eşik değerine yaklaşması
|Planlı bakım 
|}
'''Destek görevleri (supporting tasks);''' Düzeltici görevlerin aksine destek görevleri, meydana gelen durum karşısında (arıza, hata vb.) bu durumun çözülmesi amacıyla yapılmaz. Bağımsız bir görev olarak hata ya da arıza durumunu çözmez ve/veya özel bir olaydan sonra gerçekleştirilmez. Düzeltici görevlerin uygulanmasını sağlayan destekleyici görevlerdir. Test prosedürleri, erişim sağlama/kaldırmak, kurulum kaldırma/yükleme/montaj/demontaj prosedürleri örnek olarak verilebilir.

Tablo 20’de, ürün ağacında yer alan bir ‘elektronik komple’ arızası olayının meydana gelmesi durumunda, düzeltici görev, takip eden görevler ve uyarıların neler olduğu örneklenmiştir. Elektronik komple arızası karşısında, kalemin onarılabilir ve onarılamaz olması şeklinde iki farklı durum varsayılmıştır.

Elektronik komple arızası için varsayılan iki farklı durum;

1. durum; elektronik komplenin onarılamaz bir kalem olarak tanımlanmış olması

2. durum; elektronik komplenin onarılabilir bir kalem olarak tanımlanmış olması

'''Tablo 20 Görev Gereksinimleri Örneği'''
{| class="wikitable"
|'''Olay (Event)'''
|'''Düzeltici Görev'''
|'''Takip Eden Olası Görevler *'''
|'''Uyarı'''
|-
|Elektronik komple arızası (elektronik komplenin onarılamadığı durum)


|Arızalı olan elektronik komplenin  yenisi ile değiştirilmesi 
|Arızalı elektronik komplenin  elden çıkarılması
|·       Onarılamaz elektronik komplenin yedek parça olarak tanımlanmış olması  gerekmektedir. 

·       Arızalı elektronik komplenin elden çıkartılması prosedürlerinin ilgili  dokümanda belirtilmiş olması gerekmektedir.
|-
| rowspan="2" |Elektronik komple arızası (elektronik komplenin onarılabildiği durum)
|Arızalı olan elektronik komplenin  yenisi ile değiştirilmesiyle sistemin onarımı
|Arızalı olan elektronik komplenin  onarımı
|Elektronik komplenin yedek parça  olarak tanımlanmış olması gerekmektedir. Bu sayede son ürün olan sistem,  arızalı alt sistemin onarımı tamamlanana kadar beklememiş olacaktır.
|-
|Doğrudan arızalı elektronik  komplenin onarımı ile sistem onarımının yapılması
|Yok.
|Komponentin yedek parça olarak  tanımlanması gerekli değildir (onarılıp tekrar takıldığı için). Bu durumda  son ürün olan sistem, arızalı alt sistemin onarımı tamamlanana kadar beklemiş  olacaktır.
|-
| colspan="4" |* Bakım/onarım  seviyeleri belirlendikten sonra, bu seviyelere göre takip eden işlemler  değişebilecektir (arızalı sistemin bakım için belirlenen üst seviyeye  gönderilmesi gibi).
|}
Görev yapıları oluşturulurken, düzeltici görevlerden önce destek görevlerinin tanımlanması gerekmektedir. Destek görevleri de iş adımlarına bölünebilir. Destek görevleri tanımlanmadan önce, iş adımları öncesi yapılması gereken işlemler de tanımlanmalıdır. Adımlar öncesi yapılacak faaliyetler, sistem ile doğrudan ilişkili olmayan, erişim için yapılan faaliyetlerdir. Görev yapılarının oluşturulmasına ilişkin adımlar Şekil 21’de gösterilmiştir.
[[Dosya:Şekil21Görev Yapılarının Oluşturulması.jpg|alt=|sol|küçükresim|437x437pik|Şekil 21 Görev Yapılarının Oluşturulması]]




































Örneğin, bir ‘elektronik komple’ arızası, elektronik komplenin yenisi ile değiştirilmesi;

Elektronik Komple için sökme prosedürü (adımlar, görevler);

Adım 1 öncesi yapılacak işlem; kapağı kaldırmak için vidaların açılması

Görev 1; kapağın kaldırılması

Adım 2; elektronik komplenin gövdeden ayrılması

Görev 2; elektronik komplenin demonte edilmesi

Görevler tanımlanırken, ön koşulların ve/veya ön koşulların sağlanabilmesi için gereken faaliyetlerin de tanımlanması gerekir. Örneğin, görevin emniyetli bir ortamda gerçekleştirilmesi için gerekli olan tüm ön koşulları (uyarı ve dikkat edilecek hususların) kapsayacak şekilde emniyet ön koşullarının ve/veya emniyet yönetmelikleri de dahil gerekli personel yetenekleri, sertifikasyonları vs. durumlarını kapsayan personel ön koşullarının tanımlanması.

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.

'''<big>2.3. GÖREV KAYNAKLARININ BELİRLENMESİ</big>'''

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 21’de verilmiştir.

'''Tablo 21 Görev Kaynaklarına Örnekler'''
{| class="wikitable"
|'''Kaynak'''
|'''Açıklama'''
|-
|Yedek parçalar
|Yedek parçalar fiilen gerekli oldukları alt görevlere atanırlar.
|-
|Sarf malzemeler
|Sarf malzemeler fiilen gerekli oldukları alt görevlere atanırlar.
|-
|Destek ekipmanı **
|Destek ekipmanı fiilen gerekli olduğu alt göreve atanabilir ya da tüm  görev boyunca gerekliyse de tek bir alt görev yerine ana göreve atanabilir.

İlgili ekipmanı hangi personelin kullanacağı ve eğitimin gerekli olup  olmadığı bilgisinin de eklenmesi gerekir
|-
|Personel
|Personel (hem görev kapsamında ihtiyaç duyulacak personel sayısı hem  de personel gereklilikleri) fiilen gerekli olduğu alt görevlere atanırlar.
|-
|Tesis
|Tesisler fiilen gerekli olduğu alt görevlere atanırlar.
|-
|Teknik dokümantasyon
|Teknik dokümanlar fiilen ilişkili olduğu alt görevlere atanırlar.
|-
| colspan="2" |** Bakım görevlerine  destek ekipmanı atanırken ilgili ekipmanın mevcut ve doğrulanmış bir ekipman  olması, yeni geliştirilen bir ekipman ise tüm gereksinimlerinin tanımlanmış  ve dokümante edilerek yayımlanmış olması gerekmektedir. 
|}
Her bir görev kapsamında görev kaynakları belirlendikten sonra, sistem seviyesinde tüm görevler düzeyinde, alt görevler ve destek görevlerinden gelen tüm kaynakların özetlenmesi gerekmektedir. Tablo 22’de montaj prosedürü için gerekli görev kaynaklarına ilişkin örnek verilmiştir.

'''Tablo 22 Montaj Prosedürü için Gerekli Görev Kaynakları Örneği'''
{| class="wikitable"
| colspan="8" |'''Elektronik Komple için Montaj Prosedürü-Görev Kaynakları'''
|-
|'''Adım/Adım Öncesi Yapılacak İşlemler/Alt Görev'''
|'''Yedek'''
|'''Sarf Malz.'''
|'''Destek Ekipmanı'''
|'''Personel'''
|'''Özel Tesis'''
|'''Geçen Toplam Süre'''
|'''İşçilik Süresi'''
|-
|Alt görev; Elektronik Komplenin  gövde içine yerleştirilmesi
|Elektronik Komple
|Yok
|Yok.
|1 personel
|ESD korumalı alan.
|10 dk
|10 dk
|-
|Adım 1; Kapağın kapatılması
|Conta (x1)
|Yapıştırıcı
|Yok
|2 personel
|ESD korumalı alan.
|5 dk (işçilik)

60 dk (yapıştırıcının kuruması  için)
|5 dk + 5 dk
|-
|Adım 2; vidaların takılması
|Rondela

(x6)
|Yok.
|Yok.
|1 personel
|ESD korumalı alan.
|3 dk
|3 dk
|}
'''Tablo 23 Elektronik Komple İçin Montaj Prosedürü-Görev Kaynakları Özeti'''
{| class="wikitable"
|'''Kaynak tipi'''
|'''Kaynak'''
|'''Miktar'''
|-
| rowspan="3" |Yedek Parça
|Elektronik Komple
|1
|-
|Rondela
|6
|-
|Conta
|1
|-
|Sarf Malzeme
|Yapıştırıcı
|
|-
|Personel
|Personel
|2
|-
|Özel Tesis
|ESD korumalı alan
|<nowiki>-</nowiki>
|-
|İşçilik Süresi
|Personel
|18 dk
|-
|Montaj için gereken toplam süre
|<nowiki>-</nowiki>
|78 dk
|}
Geçen Toplam Süre (MET; Mean Elapsed Time); İlgili bakım görevinin yerine getirilmesi için gereken toplam süredir. Alt görevlerden ve referans verilen destek görevlerinden gelen sürelerin toplamı ile hesaplanır.

İşçilik Süresi (Labor time); yapılacak personel işinin toplam süresidir. Aynı alt görev için birden fazla personel çalışıyorsa her yetenek seviyesi için işçilik süresi toplanmalıdır. Örneğin aynı seviye kapsamında üç personel 20 dk süren bir görev için aynı zamanda çalışıyorsa, bu görev için gerekli toplam işçilik süresi 3x20=60 dk’dır.

BGA kapsamında görev süreleri, yedek parça, ekipman gibi gerekli olan tüm görev kaynaklarının hazır olduğu varsayımı ile hesaplanmalıdır (‘spanner in hand’ olan zamanlar). Bakım/onarım faaliyeti hazırlıkları ile ilgili olan dokümantasyon, destek ekipmanı veya malzemenin getirilmesi gibi üretken olmayan faaliyetler ve benzer şekilde lojistik gecikme süreleri (logistic delay time) bu sürelere dahil edilmemelidir.

Diğer taraftan, tüm faaliyetler görev sürelerine dahil edilmelidir. Örneğin, malzeme sertleşmesi ya da boya kuruması gibi üretken olmayan faaliyetlerin bir sonraki adım için tamamlanmış olmaları gerektiğinden mutlaka görev süresine dahil edilmelidir.

Bakım faaliyetleri ile ilgili olan ve bakım görevlerinden türetilen eğitim gereksinimlerinin her bir görev kapsamında tanımlanmış olması, faaliyeti yerine getirecek personel için yetenek seviyesi, karmaşık görevler için ekip eğitimi ihtiyacı olup olmadığı, eğitim gerektiren destek ekipmanının olup olmadığı, özel eğitim, tecrübe vs. ihtiyacının olup olmadığı gibi hususların göz önünde bulundurulması gerekmektedir. 

Bir kalem yedek parça olmayabilir ancak başka bir kalemin onarımı kapsamında yerinden çıkarılması gerekebilir. Yerinden çıkarılma sonrası hasar görme ihtimali varsa ve/veya tekrar kullanılamaz bir kalemse bunun da yedek parça olarak tanımlanması gerekmektedir.
{| class="wikitable"
| colspan="2" |'''Bakım uygulaması sürecinin sistem  hazır bulunurluğu ile ilişkisi;'''

Bakım faaliyetleri boyunca sistem hazır bulunurluğu sistem için en  önemli bilgilerden birisidir. Farklı kırılım seviyeleri için hazır bulunurluk  farklılık gösterebileceği gibi yapılan analiz sonuçları, maliyet  değerlendirmeleri de hazır bulunurluk kapsamında göz önünde bulundurulması  gereken faktörlerdir.

Bakım uygulaması süresince sistem hazır bulunurluğunu etkileyecek 3  farklı durum olabilir:

* Bakım süresi boyunca sistem kullanılabilir olmayabilir, bu       durumda sistemin tekrar kullanılabilir hale gelmesi için bakım ve onarım       faaliyetlerinin tamamlanmış olması gerekir. 
* Bakım süresi boyunca sistemin tam kapasite ile kullanılmaya devam       edilebilmesidir. Bu durumda, arızalı olan kısım daha sonra onarılmak       üzere yenisi ile değiştirilir ve onarılan kısım da tekrar kullanılmak       üzere stoklanır. 
* Bakım süresince sistemin eksik kapasite ile kullanılması       olabilir. Bakım ve onarım faaliyetleri tamamlandıktan sonra tam kapasite       ile kullanılabilecektir.
|-
|Bakım faaliyetlerinin yerine getirilmesi, çevre koşullarına, kullanıcı  değişikliklerine ve buna bağlı olarak kullanım/bakım alanlarının personel,  ekipman ile ilgili ön koşullarındaki değişikliklere, barış ve savaş zamanı  senaryolara bağlı olarak farklılık gösterecektir. Bu durumda görevin kendisi  aynı kalabilir ancak ihtiyaç duyulacak destek ekipmanları, görev süresi vb  değişebilir.
|
|}


Örnek BGA Formu: 
[[Dosya:Bga.jpg|sol|küçükresim|800x800pik]]

== EK-H YAZILIM DESTEK ANALİZİ (YDA) ==
'''<big>1. GENEL</big>'''

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.

Donanım gibi, yazılım da operasyon ve bakım gereksinimlerine göre analiz edilmelidir. Veriler de, aynı yazılımlar gibi hem fiziksel hem işlevsel bir bakış açısıyla ele alınabilirler.

Yazılımın kullanım şartları ile bakım şartları birbirinden net şekilde ayrılmalı ve yazılım modifikasyonu tanımı net bir şekilde koyulmalıdır. Örneğin, operasyonel husular, yazılımın ürüne yüklenmesini içerebilirken; yazılım modifikasyonu bir problemi çözmek için ya da yazılımın performansını iyileştirmek veya prosedürler, veriler ve yazılımın performansını etkileyecek sistemlere adaptasyon için kaynak kodunun değiştirilmesi olabilir.

Yazılım bakım ve idamesinin amacı, teslim edilen yazılıma ‘maliyet etkin’ şekilde destek verebilmektir.

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:

* 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:

* 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.
'''<big>2. FARKLI PROJE SAFHALARINDA YDA</big>'''

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. 

'''Tablo 24 Farklı Proje Safhalarında Yazılım Destek Analizi'''
{| class="wikitable"
|'''Geliştirme'''
|'''Üretim'''
|'''Kullanım ve Destek'''
|'''Envanterden Çıkarma'''
|-
| colspan="2" |·          LDAP’da YDA kapsamının belirlemesi

·          Karşılaştırmalı analiz

·          YDK’nın belirlenmesi

'''Detaylı yazılım analiz görevleri:'''

·          Konfigürasyon değerlendirmesi

·          YDA

·          Yazılım için OSA

·          Yazılım ilişkili görevler için BGA
|·       Periyodik değerlendirme

·       Kullanım safhasındaki teknik modifikasyonların yönetimi

·       Konfigürasyon yönetimi
|·          Verilerin silinmesi

·          Verilerin yer değiştirmesi

·          Verilerin arşivlenmesi
|}
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. 

'''<big>3. YAZILIM KIRILIM KONSEPTİ</big>'''

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.

Fiziksel bir kırılım içerisinde yer alan yazılım kalemleri genellikle, işlevselliğinin doğrudan kullanıcı tarafından gözlemlenebildiği elemanlardır. Yazılım ürün kırılımında farklı hiyerarşik seviyelerde yer alabilir. Fiziksel kırılım içerisinde yazılımı spesifik bir seviyeye atamak, üründeki konfigürasyon kontrolü ihtiyacı ve yazılımın operasyon ve bakım üzerindeki lojistik etkilerini belirtmek içindir. Fiziksel kırılım, bir ürünün kırılımındaki yazılımı belirlemek için operasyonel amaçlar kapsamında kullanılabilir ve donanımın yanında yazılımın da bakıma yönelik işlemlerinin değerlendirilmesini mümkün kılar.

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.

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.

'''<big>4. YAZILIM DESTEK ANALİZİ</big>'''

Ü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.

'''<big>4.1. YDA ADAY KALEM SEÇİMİ</big>'''

Donanım aday kalem  seçimiyle benzer yaklaşım izlenecektir.

'''<big>4.2. YAZILIM BAKIMI</big>'''

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.

'''<big>4.3. YDA KAPSAMINDA HTEKA/HTEA</big>'''

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.

Sistemin kullanım safhasında, yazılım hatalarından kaynaklı sistem hataları, yazılım değişikliğine sebep olmaktadır. LDA HTEA’sının temel prensibi, spesifik bir sistem arızasına sebep olabilecek tüm yazılım hatalarını ve aynı yazılım değişikliğine sebep olacak tüm sistem hatalarını gruplamaktır. Analiz, yazılımın gerçekleştirdiği fonksiyon üzerinden gidecektir fakat genellikle bir kaynak kodundaki spesifik bir hataya kadar değerlendirecek şekilde HTEKA/HTEA yapmak pratik değildir.

Kullanım safhasındaki diğer bir konu ise yazılım mühendislerine spesifik bir hata hakkında bilgi vermek ve yazılım hatalarından kaynaklı gereksiz bakım görevlerini önlemektir. BIT ile tespit edilebilen veya kullanıcı tarafından tanımlanabilen bir yazılım hatası demontaj sayısını ve donanımla ilişkili olmayacak hataları azaltacaktır (ekipmanın değiştirilmesi ile yazılım hatasının ortadan kaldırılamaması gibi).

'''<big>4.4. YAZILIM İÇİN PLANLI BAKIM ANALİZİ (PBA)</big>'''

GMB gibi PBA’lar donanımlar gibi yazılımlara uygulanabilir değildir. Yazılım hataları, yazılım tasarımının istenmeyen etkilerinin sonucu olduğundan PBA kapsamında tanımlanmış bir bakım görevi ile düzeltilemezler. PBA sonuçları yazılım içeren bir donanımda, planlı bakım görevlerini belirleyecek şekilde kullanılabilir ancak bu analiz yine de donanım için olacaktır.

Yazılımlar da küvet eğrisi davranışını izleyerek ilk kullanımda çokça hata yaparlar. Geliştirme safhası boyunca kararlı bir davranışa kadar kod hataları düzeltilerek tekrarlayan bir şekilde yazılım yayımlamaları yapılır. İlerleyen kullanımlarda hata oranları her ne kadar düşse de yazılımda ilk kapsamından farklı olarak modifikasyonlar olacağından hata oranları yine artacaktır.

'''<big>4.5. YAZILIM İÇİN OSA</big>'''

Yazılım için OSA donanımlarda olduğu gibi ya da oldukça benzer olacak şekilde ele alınmalıdır. OSA sonucunda ortaya çıkan görevler yeni yazılım yayını veya operasyonel bir yazılım ihtiyacının doğması veya veri yükleme gibi dışsal nedenlerden kaynaklanabilir. Eğer bu görevler çok sık gerçekleşirse OSA sonuçları donanımlara karşılık gelen görevlerden farklı olabilir.

Yazılım değişikliği için ekipman hakkında detaylı bilgi (donanımla ilintili yazılım geliştirme ortamı ve yazılım geliştirme araçları) ve personel yetkinliği gereklidir.  Ayrıca, sözleşmeye bağlı durumlar, yazılım modifikasyon faaliyetlerinin hangi destek seviyesinde gerçekleştirileceğini etkileyebilir.

'''<big>4.6. YAZILIM İÇİN BGA</big>'''

İlgili yazılım destek başlatıcılarının (olaylar) belirlenmesinden sonra operasyonel/bakım veya modifikasyon görevleri belirlenmelidir. Amaç bunları tanımlamak ve bunlara gerekli kaynakları ve görev karakteristiklerini belirlemektir (süre, insan ihtiyacı, ön koşullar, güvenlik koşulları vb.).

SAE JA1005 referans alınarak farklı olaylar sonucunda hangi yazılım destek görevlerinin gerçekleştirileceğine ulaşılabilir.

'''<big>5. YAZILIM DESTEK KONSEPTİ ÇERÇEVESİ</big>'''

Yazılım destek konsepti yazılım tasarım sürecinin erken safhalarında başlamalıdır. Eğer değişiklik gereksinimleri farklı kaynaklardansa, yazılım değişikliği daha kolay olacaktır. Ayrıca, yükleme ve konfigürasyon prosedürleri de olabildiğince kolay olmalıdır.

Yazılım desteğinin 3 farklı perspektifi vardır;

* İlki; destek profili, seviyeler, aktörler ve aktivitelerden oluşur.
* İkincisi; destek fonksiyonları olan operasyon, yönetim ve modifikasyonlardır.
* Sonuncusu ise destek sınıfları olan süreçler, ürün ve çevredir.

Yazılım desteğinin LDA kapsamında olup olmayacağı proje kapsamında yapılması planlanan faaliyetler ile birlikte değerlendirilmeli ve yapılması gerektiği değerlendirilirse LDAP’a eklenmelidir. Büyük miktarda yazılım içeren büyük ve karmaşık sistemlerde yazılım desteklenebilirliği ayrı bir alan olarak değerlendirilmelidir. Yazılımlar donanımlara fonksiyonellik katmak için tasarlandıklarından donanım ile arasındaki arayüzler kurulana kadar süreçler birlikte işletilmeli, gözden geçirilmeli, pratiğe dökülmeli ve dokümante edilmelidir.

'''<big>5.1. YAZILIM DESTEK PROFİLİ</big>'''

Yazılım destek profili kapsamında, yazılım desteğinin gerçekleştirileceği yer, organizasyon ve ilişkili personelin dikkate alınması gerekmektedir. Yazılım destek seviyeleri aşağıdaki gibi tanımlanabilir;

* Operasyonel seviye (seviye 1); bu destek seviyesi, yazılımın operasyonel kullanımındaki yerini tanımlar. Bu seviyede, operasyonel servis desteği adı altında basit destek görevleri gerçekleştirilir.
* Orta seviye destek (seviye 2); hem operasyonel servis desteğiyle hem de yönetim desteği ile ilgili tüm destek faaliyetlerini içerir.
* Üst seviye destek (seviye 3); yönetim desteğine ek olarak modifikasyon desteği de burada sağlanır. Yapılacak faaliyetler, karışıklık, boyut, modülerlik, programlama teknikleri vs. gibi yazılım paketinin kendisine ve yazılım modifikasyonunu gerçekleştirecek ekipmana (araçlar, personel, tesisler) dayanır.

* Yazılım sağlayıcı ve/veya geliştirici (seviye 4); yazılım sağlayıcı normalde yazılım modifikasyonuyla ilişkili gerekli geliştirme araçları ve personel ile donatılmış en üst yetenekteki destek seviyesidir. Kullanıcılar çoğunlukla bu yetkinliğe sahip olmadıklarından yazılım modifikasyonları için genelde bu seviyede destek sağlanır.

Yazılım destek rollerinin belirlenmesinin ilk aşaması kullanıcı ve yüklenici firma rollerinin tanımlanmasıdır. İkinci aşaması ise, yazılım kullanım ve desteğiyle ilişkili personellerin rollerinin (yetkinlik, erişim, eğitim vb.) tanımlanmasıdır. Aşağıda destek rolleri ve bu kapsamda tanımlanan aktiviteler ve yetkilere ilişkin örnekler verilmiştir;

* Basit düzeyde kullanıcı; yazılım sistemlerinin düzeltilmesi veya modifikasyonuyla ilgili bir yetkisi yoktur. Ana görevleri yazılım içeren sistemi operasyonel olarak çalışır durumda tutmak ve sistem/yazılım hatalarını raporlamaktır.
* Orta düzeyde kullanıcı; yazılım sistemlerinin düzeltilmesi ile ilgili yetenek ve bilgiye sahiptir. Yazılımı çalışır durumda tutmak için operasyonel destek aktivitelerini gerçekleştirirken, yazılım ve veri yükleme vb. yazılım güncelleme aktivitelerine ise destek vermezler.
*  Sistem yöneticileri; üst düzey kullanıcılarıdır. Operasyonel destekle ilgili tüm aktivitelerden ve yönetim desteğinden sorumludurlar. Yazılım modifikasyonu gerçekleştirmeseler de, tipik yönetim görevleri olan performans parametrelerinin değiştirilmesi gibi yazılım konfigürasyon işlerinden, ek yazılım paketi yüklemeleri vb. işlerden sorumludurlar.

* Servis sağlayıcı; kalifiye operasyonel desteğinden ve yardım hattı gibi ek servislerden sorumludurlar. Müşteri veya yüklenici tarafında ikamet ederler ve modifikasyon desteği de sağlarlar.
* Yüklenici/Yazılım geliştirici; en üst seviyeden yazılım modifikasyon desteği sağlarlar.

Farklı destek görevleri ve seviyeleri için farklı bölgelerde farklı kaynaklarla nasıl yapılacağını gösteren kullanım durumlarının tanımlanması gerekmektedir.

'''<big>5.2. DESTEK FONKSİYONLARI</big>'''

Yazılımla ilişkili bakım görevleri aşağıda belirtilen hususlara göre farklı kategorilere ayrılabilir;

* Görev basit bir yükleme/kaldırma görevi mi yoksa yazılımın A cihazından B cihazına taşınma işlemi mi?
* Yazılım yüklemesi ya da kaldırılması için bir donanımı çıkarmak gerekli mi?
* Yazılım modifikasyonu gerekli mi? Yazılım modifikasyonunun özel destek görevleri gerektiren geniş bir alan olması sebebiyle modifikasyonun kapsamı tam olarak belirlenebiliyor mu?
'''<big>5.2.1. OPERASYONEL SERVİS DESTEĞİ</big>'''

Operasyonel servis görevleri sistemin günlük operasyonel görevleriyle ilişkili tüm aktiviteleri tanımlar. Fakat bu görevler sistem kullanımı üzerinde farklı kalite ve derinlikte etkilere sebep olabilir (ör. sistem atıl zamanları, test gereksinimleri vb.). Bu görevler, destek seviyesi 1 ve 2’de kullanıcı tarafından yürütülen basit görevlerdir.

Görevler, yeni bir işlevsellik veya yeteneğin provizyonu için (yazılım yükleme, yazılım kaldırma, yazılım konfigürasyonu, harita vb. veri yükleme) sistemin geri döndürülmesi veya hata durumlarında problem raporlama (yazılımı geri döndürme, geri döndürme problemlerinin raporlaması - hata gerçekleştiğinde yazılım ve donanımların konfigürasyonu, hatanın tipi, geri döndürmenin başarım durumu, hatanın ciddiyeti), operasyon sonrası veri kaldırma ve organizasyonel görevler (yazılımın teslimi, operasyonel konfigürasyon kontrolü) olmak üzere 3 tipte sınıflandırılabilir.

Gömülü yazılımların veya bellenimlerin yükleme görevleri BGA’da belirlenmelidir.

'''<big>5.2.2. YÖNETİM DESTEĞİ</big>'''

Operasyonel destek ile yazılım modifikasyon görevleri arasında bir yerdedir. Her seviyede kullanıcı tarafından gerçekleştirilebileceği gibi destek organizasyonları tarafından da gerçekleştirilebilir. Problem raporlaması, sistem konfigürasyon kontrolü, teslim ve yükleme ile kullanıcı desteği gibi görev tipleri mevcuttur.

'''<big>5.2.3.  YAZILIM MODİFİKASYON DESTEĞİ</big>'''

Yazılım modifikasyonu, düzeltici, adaptif veya tamamlayıcı sebeplerden ötürü olabilir. Genellikle yüklenici tarafında yapılan bir aktivite olsa da kritikliği düşük değişiklikleri karşılayan ekipman ve yetenekli personel varsa kullanıcı da gerçekleştirebilir. Yazılım modifikasyonu, kodlama değişikliğinin uygulanması ve test gibi modifikasyonun direkt kendi aktivitelerini ve problemin araştırılması ve konfigürasyon kontrolü gibi ilişkili görevleri de içerir. Genellikle, yazılım değişikliği için en kritik sebep ürünün operasyonunda kabul edilemez bir duruma sebep olan gerçek bir hata yaşanmasıdır.  Adaptif değişiklikler de kritik bir durumdan kaynaklanabilir ancak daha tahmin edilebilir ve planlanabilir değişikliklerdir. Tamamlayıcı değişiklikler ise işlevselliği ve kullanıcı kolaylığını artırmak için yapılan değişikliklerdir. Genellikle bir sürüm yükseltme ile birlikte yapılırlar. Kullanıcı gereksinimleri bir süre boyunca toplanır ve yeni yazılım paketinin yayınlanmasıyla uygulamaya koyulurlar. Yazılım modifikasyon görevleri, problem araştırması, değişikliğin uygulanması, değişikliğin yayınlanması, konfigürasyon kontrolü faaliyetlerinden oluşur.


'''<big>6. DESTEK SINIFLARI</big>'''

'''<big>6.1. SÜREÇLER</big>'''

Yazılım desteğine ilişkin süreçlerin nasıl uygulamaya konulacağı, girdiler, çıktılar, kontroller ve kaynakları da içerecek şekilde dokümante edilmelidir. Bu kapsamda, akış şemaları, tanımlar, gereksinim ve sorumluluklar verilebilir. Uluslararası veya şirket içi kabul görmüş bir standart ve kullanılabilir ölçülebilir performans parametreleri tanımlanabilir.

'''<big>6.2. ÜRÜN</big>'''

Yazılım ürün karakteristiğinde desteklenebilirlik mümkün olduğunca erken safhalarda adreslenmelidir. Yazılım kalitesi, yazılımın ne kadar iyi ya da kötü tasarlandığına bağlıdır. İyi bir yazılım tasarımı için gereksinimlerin net bir şekilde tanımlanması ve grafiksel kullanıcı arayüzü desteğinin sağlanması gerekmektedir. Modülerlik, değiştirilebilirlik, genişletilebilirlik, basitlik, kolay kullanım, kararlılık, tutarlılık, işlem süresi performansı gibi hususlar tipik yazılım kalite göstergerleri olarak verilebilir.

'''<big>6.3. ÇEVRE</big>'''

Kaliteyi etkileyen çevresel durumlar yazılımı kullanacak ve destekleyecek personel ile başlar. Doğru bir yazılım desteği kapsamında personelin yazılım destek işi için doğru kişi olması, yetenek ve deneyiminin seviyesi, sorunsuz bir yazılım desteğini garanti etmek için kaç kişinin gerekeceği gibi konular önemlidir. Personele ek olarak, tesisler, ofislerin genişliği vb. konular da desteğin kalitesi açısından önemlidir. Bakım görevlerinin belirlenmesi kapsamında bu hususların mutlaka değerlendirilmesi gerekmektedir.

'''<big>7. DESTEKLENEBİLİRLİK FAKTÖRLERİ</big>'''

Yazılım için desteklenebilirlik faktörlerinin bazıları operasyonel destek ile ilişkiliyken, bazıları yazılım modifikasyon desteği ile ilgili olabilirler. Bu nedenle bu faktörlerin proje gereksinimleri dikkate alınarak ele alınması önemlidir. Yazılım desteklenebilirlik faktörleri ile ilgili açıklamalar ilerleyen bölümlerde verilmiştir.  Yazılım desteklenebilirlik faktörlerinin  geliştirme safhasında dikkate alınması (uygulanabilir olanlar için gereksinim tanımlanması, işlevsel akışa dahil edilmesi vb.) gerekmektedir.

'''<big>7.1. UYUMLULUK MATRİSİ</big>'''

Bir sistemde farklı donanımlar üzerindeki farklı yazılımların birlikte çalışabildiği ve yazılım kalemleri içeren fiziksel kırılım içerisinde yazılımların donanımlarla uyumluluğu doğrulanmalıdır. Yazılım paketi taşıyan birbiriyle konuşan ekipmanlarla ilişkili uyumluluk matrisi hazırlanmalıdır.

Tablo 24’de örnek bir uyumluluk matrisi verilmiştir. Tabloda verilen bilgilere göre, donanım 2 üzerinde yer alan ‘A’ ve ‘B’ yazılımlarının birbirileri ile uyumluluğu, benzer şekilde donanım 2 ile hem ‘A’ hem ‘B’ yazılımının uyumlu olduğu ve donanım 1 ile ‘A’ yazılımının uyumluluğu doğrulanmalıdır. 

'''Tablo 25 Uyumluluk Matrisi'''
{| class="wikitable"
|
|Donanım 1
|Donanım 2
|-
|Yazılım A
|x
|x
|-
|Yazılım B
|<nowiki>-</nowiki>
|x
|}
'''<big>7.2. DOKÜMANTASYON</big>'''

Tanımlanmış bakım seviyeleri kapsamında yazılım destek dokümantasyonunun hazırlanması gerekmektedir. Yüklenici tarafında gerekli yazılım destek dokümantasyonu veya kullanıcıya tanımlanan yetkiler dahilinde son kullanıcı el kitabı, yükleme, konfigürasyon gibi amaçları olan yönetim dokümantasyonları olabilir. 

Operasyonel açıdan, orta ve üst düzey kullanıcılar açısından dokümantasyon önemlidir. Dokümantasyon; yükleme, konfigürasyon adımları ve sorun giderme ile ilgili taktikler içermelidir. Ciddi hatalar oluşması durumunda da yüklenici firma iletişime geçilecek kişinin iletişim bilgilerini de içermelidir.

'''<big>7.3. YAZILIM YÜKLEME VE KALDIRMA</big>'''

Yazılımların güvenli bir şekilde sisteme yüklendiği, sistemin problemsiz çalıştığı ve yazılımın kaldırılması test prosedürleri ile doğrulanmış ve dokümante edilmiş olmalıdır.

'''<big>7.4. DONANIMLAR ÜZERİNDE TAŞINMA</big>'''

Eğer yazılımın bir donanım üzerinde taşınması gerekiyorsa yazılımın tipine, boyutuna ve güvenlik gereksinimlerine göre hangi donanımla taşınacağı belirlenir. Çipler veya usb belleklerle taşınıp taşınamayacağı, hard disk ya da DVD ihtiyacı olup olmadığı, donanımda taşımanının güvenli olup olmadığı değerlendirilmelidir.

'''<big>7.5. GENİŞLEME KAPASİTESİ</big>'''

Genişleme kapasitesi sistem tasarımının bir parçasıdır, yazılımla ilişkili olsa da genellikle tüm sistem tasarımı içerisinde ele alınması gereken bir donanım karakteristiğidir. Yazılımın hesaplama kaynakları üzerinde kısıtlamalarda (işlemci performansı, bellek, girdi/çıktı bant genişliği, veritabanı kapasitesi, network performansı vb.) limiti olmadan ne kadar değiştirilebildiği ile ilgilenir.  Genişleme kapasitesi yeterli detayda ele alınmazsa yazılım modifikasyonu limitli olacaktır. Modifikasyon maliyeti ciddi ölçüde artacak ve ek aktiviteler gerekebilecektir. Genişleme kapasitesi, sabit donanım konfigürasyonu olan sistemlerde ve gömülü sistem gerçek zaman uygulamalarında yüksek önem taşır. Bu nedenle tasarım safhasında genişleme kapasitesinin göz önünde bulundurulması önemlidir.

'''<big>7.6. MODÜLER YAZILIM TASARIMI</big>'''

Modülerlik yazılım tasarım yapısının bir özelliğidir. Bir yazılım paketinin içindeki işlevselliğin farklı alanları modüller yardımıyla yapılandırılır. Bir yazılım tasarımına modülerlik kazandırma imkânı tasarım yöntemi, programlama araçları ve programlama dili seçimiyle belirlenir. Optimum modülerliğe, desteklenebilir tasarım karşısında işlevsel ve performans gereksinimlerinin dengelenmesi ile ulaşılır. Yetersiz modülerlik ilave modifikasyon eforuna ve maliyetine sebep olur. Bu nedenle tasarım safhasında modülerliğin göz önünde bulundurulması önemlidir.

'''<big>7.7. MODİFİKASYON FREKANSI (DEĞİŞİKLİK TRAFİĞİ)</big>'''

Yazılımın modifikasyon ihtiyacının oranıdır. Yazılım kullanımından önce modifikasyon frekansı tahminleri benzer uygulamaların (kullanımdaki yazılımlar) yardımı ile yazılımın bazı karakteristikleriyle, test ve deneme fazındaki deneyimlerle yapılabilir. Modifikasyon frekansının kararlılığı yazılım entegrasyonunu ve sistem operasyonunu etkiler. Değişiklik trafiği, yazılım destek aktivitelerinin hacmini etkiler.  Yüksek değişiklik trafiği daha fazla yazılım modifikasyon aktivitesi demektir. Bu nedenle tasarım safhasında modifikasyon frekansının göz önünde bulundurulması önemlidir.

'''<big>7.8. GERİYE DÖNDÜRME</big>'''

Bir yazılım hatasından kaynaklı sistem çalışmadığında, sistemi yeniden başlatmak veya en azından kabul edilebilir bir sürede azalmış ama kabul edilebilir işlevselliğe getirmek gereklidir. Geriye döndürme yazılımın erken tasarım safhalarında, sağlıklı izleme durumu, hataya toleranslı denetimciler, hata ayıklama (debug) özelliği için tasarım gibi konular da değerlendirilmelidir. Erişilebilir ekipmanla operasyonel gerçek zaman güncellemesi gerçekleştirebilecek bir geriye döndürme özelliği olması kritik önem taşımakta olup geliştirme safhasında dikkate alınmalıdır. Gerçek bir acil durum oluşmadan yazılımın geriye döndürülmesi test edilmiş olmalıdır.

'''<big>7.9. EMNİYET ENTEGRASYONU</big>'''

Sistemin emniyet analizi yazılımlar da dikkate alınarak yapıldıktan sonra, sistem tasarımı kritik fonksiyonları olan yazılım kalemlerinin minimize edilmiş olduğunu ya da en azından kritik fonksiyonların yazılımın diğer kısımlarından ayrıştırıldığını garanti etmelidir. Emniyet entegrasyonu yalnızca yazılım tasarımıyla ilgili değildir. Yazılımın taşıma, yükleme ve kullanımında da (ör. yazılımlara kullanıcı erişimleri) belirli bir emniyet seviyesine ulaştığı garanti edilmelidir.

'''<big>7.10. GÜVENLİK</big>'''

Yazılımın kendisi ile ilgili olup; dijital imza, aktivasyon veya lisans anahtarları, kriptolama, çevrimsel hata denetimi gibi güvenlik metotları mevcuttur. Yazılımın güvenlik sınıflandırması, çalıştırılabilir kodu ve dokümantasyonu yazılım destek aktivitelerini kısıtlayabilir. Yazılıma erişim kısıtlanabilir ve spesifik yazılım test görevleri ve ekipmanlarının önemini artıracak gereksinimler tanımlanabilir. Yazılımın güvenlik sınıflandırması, uygulamaya ve ekipmanın tasarımına bağlıdır. Mümkün olduğu ölçüde güvenlik seviyesi yüksek yazılımlar, sistemdeki diğer yazılımlardan ayrı olmalıdır. Güvenlik gereksinimleri sınıflandırmada kullanılacak ve sınıflandırmaya uygun olarak modifikasyon ve yazılımın ele alma kısıtlarını belirleyecektir.

Güvenliğin diğer bir boyutu operasyonel karakteristiktir. Yazılım paketinin hem uygun kullanıcı erişimi gibi iç güvenlik hem de dış güvenlik açısından güvenli bir ortamda çalıştığı garanti edilmelidir. Bu anlamda ağ ve güvenlik duvarı yönetim aktiviteleri, virüs tespiti ve savunma aktiviteleri gerçekleştirilir.

Savunma ve güvenlik sistemlerindeki yazılımlar üçüncü tarafın eline geçmemesi için kullanımdan sonra silinebilir. Bu konuya ilişkin tedbirlerin alınmış olması gerekir.

'''<big>7.11. BOYUT</big>'''

Yazılım paketinin boyutu, beklenen değişiklik trafiği seviyesi ve modifikasyonları uygulamak için gereken kaynaklar açısından desteklenebilirlik parametrelerini etkiler. Yazılımın boyutu, uygulamaya ve tasarım çözümüne bağlıdır. Sistem tasarımında boyutla ilgili bir kısıt varsa yazılım gereksinimlerinde belirtmelidir. Birçok yazılım desteği yazılımın boyutuna ve karmaşıklığına bağlıdır.

'''<big>7.12. YETKİNLİKLER</big>'''

Yetkinlik gereksinimleri, sistem tasarımı, yazılım tasarımı ve uygulanabilir yazılım destek politikası tarafından belirlenir. Personelin yetkinlik seviyesi, birden fazla açıdan değerlendirilmelidir. Sırasıyla basit düzeyde kullanıcı, yönetim sorumluluğu olan operatörler ve en yetkin olması gereken yazılım modifikasyonu yapacak kişilerdir.

'''<big>7.13. YAZILIM DAĞITIMI</big>'''

Yazılım LAN, WAN gibi ağlar üzerinden veya bir donanım aracılığıyla farklı medya tipleri ile dağıtılabilir.

'''<big>7.14. TEKNOLOJİ</big>'''

Yazılım tasarım yöntemleri ve destek araçları, işleten sistemler, programlama dilleri, derleyiciler, hata ayıklayıcılar, yazılım test metot ve test ortamı, projeye özgü ekipman ve teknikler gibi yazılım mühendisliği metotları ve yazılım geliştirme-uygulamada kullanılan araçlar da dikkate alınmalıdır. Teknolojinin ağ üzerinden yapılacak destek bakım konseptini kolaylaştırması gibi operasyonel olarak da etkileri vardır.

== EK-I ÖRNEK LDA PLANI ==
'''<big>1.  GENEL</big>''' 
* Programın hem yüklenici hem de müşteri tarafındaki yönetim yapıları
* LDA faaliyetlerinin proje takvimi ile entegrasyonu
* Sorumluluklar
* Değişiklik yönetimi
* Risk yönetimi
* İş paylaşımı anlaşmaları

'''<big>2. SİSTEM TANIMI VE OPERASYONEL KONSEPT TANIMI (BKZ. BÖLÜM 5.1)</big>'''

'''<big>3. LDA SÜRECİNİN VE ANALİZ FAALİYETLERİNİN AMACI</big>'''

LDAK’nın çıktılarından biri olarak, yüklenici ve müşteri LDA faaliyetleri sonucu oluşan verilerin nasıl kullanılacağına dair prensiplerde anlaşmalıdır. Analiz verilerinin bir lojistik veri tabanında dokümante edilmesi gereksinimi, veri toplamanın amacını da ortaya koymalıdır. Bu amaçla, hangi veri elemanlarının lojistik veri tabanında kaydedileceği dikkatle kararlaştırılmalı ve veri elemanları tanımlanan bu amaçlarla ilişkilendirilmelidir. Seçim konusundaki bu hassasiyet analiz faaliyetleri açısından da gösterilmelidir. Özellikle geniş kapsamlı ve detaylı analizler için seçim teknik ve ekonomik hususları dikkate alarak gerçekleştirilmelidir.

Proje kapsamında uygulanmasına karar verilen analiz faaliyetleri;

* EK-A İnsan Faktörü Analizleri ve LDA,
* EK-B HTE(K)A ve Sonuçlarının LDA İçerisine Kullanımı,
* EK-C Hasar ve Özel Olay Analizleri,
* EK-D Lojistik İlişkili Operasyonlar Analizi,
* EK-E Planlı Bakım Programı Geliştirme,
* EK-F Onarım Seviyesi Analizi,
* EK-G Bakım Görev Analizi,
* EK-H Yazılım Destek Analizi,
* İdame Edilebilirlik (Bkz Bölüm 6.2.3) Analizi.

bölümlerinde yer alan yöntemler uygulanarak gerçekleştirilmelidir. Ancak ilgili yöntemlerin proje türü, süreçleri ve gereksinimlerine göre hangi kural ve varsayımlar çerçevesine nasıl uygulanacağı alt başlıklar halinde detaylı bir şekilde uyarlanmalıdır. Hangi faaliyetlerin hangi seviyede yapılacağı bilgisi ile yapılan uyarlamalar ile gerekçeleri LDAP’ın bu bölümünde belirtilmelidir.

'''<big>4. ÜRÜN KIRILIM YÖNTEMİ</big>''' 

Planın bu bölümünde bir ürün kırılım yöntemi oluşturmak üzere kurallar belirlenmelidir. Müşteri ve Yüklenici arasında, kırılım elemanlarının nasıl tanımlanacağı (ör, S1000D Standart Numaralandırma Sistemi, 1388-2B Lojistik Kontrol Numarası sistem veya Müşteri tarafından tercih edilecek diğer sistem) açıklığa kavuşturulmalıdır. Kırılım için hem fiziksel hem de işlevsel yapının birlikte kullanılması gerekli görülüyorsa, bu iki yapının birbiri ile nasıl ilişkilendirileceği tanımlanmalıdır. Yöntem, yazılım kalemlerinin hiyerarşik yapıda nasıl kapsanacağını ve farklı nihai ürün varyantlarının nasıl ele alınacağını da açıklamalıdır.

'''<big>5. ANALİZ EDİLEN KALEM İÇİN KIRILIM DERİNLİĞİNİN BELİRLENMESİ</big>'''

Kırılım türünün yanısıra derinliği de son derece önemli bir niteliktir. Nihai karar verilirken aşağıdaki hususlar dikkate alınmalıdır:

* İlgili bütün yedek parçaları belirlemek için tam detaylı bir kırılım gerekli midir ve bu kırılım uygun ve etkili midir?
* Sadece HDB seviyesine kadar inen bir kırılım uygun ve etkili midir?
* Belirli yetki kademeleri için tanımlanmış tamir konsepti için hangi seviyede kırılım gereklidir?
* Eğer isteniyorsa, işlevsel kırılım hangi amaçla gerekli görülmektedir (ör. planlı bakım analizleri) ve işlevsel kırılım ile fiziksel kırılım arasındaki bağlantı nasıl oluşturulmaktadır?

'''<big>6. LDA ADAY SEÇİM KRİTERLERİ</big>'''

LDA adaylarının seçimi için oluşturulan kriterler LDA Planında dokümante edilmelidir. Bu konuda bir akış şeması da oluşturulabilir.

'''<big>7. ADAY KALEM LİSTESİ (AKL)</big>'''

LDA İş Tanımlama Toplantısı (LDAİTT)’na hazırlık olarak yüklenici tarafından taslak bir AKL hazırlanmalı, toplantıda yüklenici ve müşteri arasında tartışılarak AKL üzerinde mutabakata varılmalıdır. Üzerinde uzlaşılan AKL, LDAİTT’nın resmi bir çıktısıdır.

'''<big>8. ADAY ELEMANLAR İÇİN POTANSİYEL ANALİZ FAALİYETLERİ</big>'''

AKL sadece ürün ağacından analize tabi olmak üzere seçilen elemanları değil aynı zamanda bu elemanlar için gerçekleştirilecek analiz faaliyetlerini de içerebilir. Seçilen analizlerle birlikte, analizlerin gerçekleştirileceği derinlik de tanımlanmalıdır. Örneğin BGA için her bir bakım görevinin hangi derinlikte dokümante edileceği ve personel gereksinimlerinin belirlenmesine gerek olup olmadığı tanımlanmalıdır.

AKL aynı zamanda LDA programı için bütün eforun özetlendiği bir gözden geçirme vasıtası olarak ve çalışmaların ilerlemesinin takip edildiği bir yönetim aracı olarak da kullanılabilir.

'''<big>9. YEDEK PARÇALARIN BELİRLENMESİ VE YEDEK PARÇA SAYILARININ HESAPLAMASI (Bkz. EK-G     BAKIM GÖREV ANALİZİ)     </big>'''

'''<big>10. HİZMET İÇİ KULLANIM VE DESTEK SAFHALARI LDA FAALİYETLERİ (Bkz. BÖLÜM 7)</big>'''

'''<big>11. LDA SÜRECİ-TASARIM SÜRECİ ARAYÜZÜ</big>'''

Yapılan LDA faaliyetleri ile tasarım faaliyetlerinin birbiri ile arayüzünün nasıl tesis edileceği ve izlenebilirliğin nasıl sağlanacağı bu bölüm kapsamında açıklanmalıdır.

'''<big>12. LDA SÜRECİ-ELD SÜRECİ ARAYÜZÜ</big>'''

Yapılan LDA faaliyetleri ile ELD faaliyetlerinin birbiri ile arayüzünün nasıl tesis edileceği ve izlenebilirliğin nasıl sağlanacağı bu bölüm kapsamında açıklanmalıdır.

'''<big>13. LDA FAALİYETLERİNİN PERFORMANSININ ÖLÇÜLMESİ VE DOĞRULANMASI</big>''' 

LDA faaliyetlerinin performansı, örneğin lojistik veri tabanın statü bilgisi vasıtasıyla sürekli olarak değerlendirilmelidir. Bir analiz faaliyetinin tam olarak gerçekleştirilmesi veya bir aday bileşenin bilgilerinin lojistik veri tabanında tam olarak dokümante edilmesine dair kriterler açık bir şekilde belirlenmelidir ve gerektiğinde kabul kriteri olarak tanımlanmalıdır.

'''<big>14. BİLİŞİM HUSUSLARI</big>'''

Farklı bölgelerdeki aynı analiz aktiviteleri için farklı yazılım paketleri kullanılmamalıdır. Kullanılması durumunda entegrasyon ve uyumlandırma süreçleri açısından bir takım riskler oluşabilir. Lisans ile ilişkili hususlar, sözleşmesel kısıtlar, bilişim hususları ile ilişkili türlü faktörlerden birçok proje farklı yazılım paketleri kullanmaktadır. Böyle bir durumda, gerçekleştirilecek görevler için tüm paydaşlar arasında uyumlu olan yazılım paketinin kullanımı tavsiye edilir. Yazılım paketleri ile ilgili kararlar LDA GGT’da dokümante edilmelidir. Bir program esnasındaki yazılım yayımlama değişiklikleri uyumlandırılmalı ve etkilenen tüm paylaşlar arasında mutabakat sağlanmalıdır.



'''<big>DOKÜMANIN HAZIRLANMASINDA GÖREV ALAN KURUM/KURULUŞLAR</big>'''

SAVUNMA SANAYİİ BAŞKANLIĞI

MİLLİ SAVUNMA BAKANLIĞI

         KARA KUVVETLERİ KOMUTANLIĞI

         HAVA KUVVETLERİ KOMUTANLIĞI

        TERSANELER GENEL MÜDÜRLÜĞÜ

ASELSAN A.Ş.

ASFAT A.Ş.

BMC OTOMOTİV SANAYİ VE TİCARET A.Ş.

HAVELSAN A.Ş.

METEKSAN SAVUNMA SANAYİ A.Ş.

MİLSOFT YAZILIM TEKNOLOJİLERİ A.Ş.

NUROL MAKİNA VE SANAYİ A.Ş.

OTOKAR OTOMATİV VE SAVUNMA SANAYİ A.Ş.

ROKETSAN A.Ş

SATURN DANIŞMANLIK EĞİTİM VE MÜH.LTD.ŞTİ.

SDT UZAY VE SAVUNMA TEKNOLOJİLERİ

VİYA LOJİSTİK MÜHENDİSLİK VE BİLİŞİM TEKNOLOJİLERİ LTD.ŞTİ.