Değişiklikler

2.718 bayt eklendi , 16.02, 25 Ağustos 2022

→‎EK-G BAKIM GÖREV ANALİZİ (BGA)

1. satır: 1. satır: −

[[Dosya:~~BAŞKANFOTO~~.jpg|sol|küçükresim|~~400x400pik~~]]

+

'''[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]]

+

48. satır: 59. satır: −

= ÖZET =

+

+

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.

99. satır: 112. satı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.~~'''TÜRK SAVUNMA SANAYİİ'''~~

+

* 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

+

'''Tablo 1 Değişiklik İzleme Tablosu'''

{| class="wikitable"

|'''Revizyon No'''

208. satır: 221. satır:

=== 1.7.1. TANIMLAR ===

−

Tablo 2 Tanımlar Tablosu

+

'''Tablo 2 Tanımlar Tablosu'''

{| class="wikitable"

|'''Terim'''

250. satır: 263. satır:

|LDA Kılavuz Konferansı Belgesi

|-

−

|LDA İş ~~Tanımlama~~ Toplantısı

+

|LDA İş Tanımı Toplantısı

LSA Guidance Conference

293. satır: 306. satır:

|}

=== 1.7.2. KISALTMALAR ===

−

Tablo 3 Kısaltmalar Tablosu

+

'''Tablo 3 Kısaltmalar Tablosu'''

{| class="wikitable"

|'''Kısaltma'''

577. satır: 590. satır:

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

−

Tablo 25 Uyumluluk Matrisi ~~195~~

+

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şı ~~İşletme~~ ve ~~İdame Dönemi maliyetleri~~

+

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

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

598. satır: 611. satır:

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

−

Şekil 10 Kullanım safhası ~~ELD~~ süreci

+

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

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

667. satır: 680. satır:

* Ürün Destek Yönetimi

−

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

+

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:~~Şekil 1~~ ELD Elemanları ile LDA ~~arasındaki ilişki~~.~~png~~|sol|küçükresim|600x600pik|Şekil 1 ELD Elemanları ile LDA ~~arasındaki ilişki~~]]

+

762. satır: 775. satır:

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:~~Şekil 3~~ ÖDM ve LDA Arasındaki Etkileşim.~~png~~|sol|küçükresim|~~800x800pik~~|Şekil 3 ÖDM ve LDA Arasındaki Etkileşim]]

+

929. satır: 942. satır:

=== 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:Şekil 10 Temel ~~.png~~|sol|küçükresim|~~700x700pik~~|Şekil 4 Temel LDA Süreci]]

+

−

1.031. satır: 1.037. satır:

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

−

=== 4.1.5. PROGRAM VE TASARIM GÖZDEN GEÇİRMELERİNE KATILIM ===

+

=== 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.

1.038. satır: 1.044. satı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:~~LDA Süreci~~.jpg|sol|küçükresim|~~800x800pik~~]]

+

[[Dosya:TSSODYP06.LDASURECI.jpg|alt=|sol|küçükresim|758x758pik]]

1.120. satır: 1.126. satır:

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.

−

=== 5.1.2.1. GENEL KULLANIM SENARYOSU ===

+

==== <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:

+

==== 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,

1.130. satır: 1.136. satır:

* Hareket kabiliyeti gereksinimleri,

−

=== 5.1.2.2. PLANLANAN MEVKİLERİN COĞRAFİ KONUMLARI VE ÖZEL KOŞULLARI ===

+

==== <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:

1.143. satır: 1.149. satır:

* Farklı alanlar arasında etkileşimler (örneğin, bir alandan diğer bir alana bakım desteği verilmesi).

−

=== 5.1.2.3. KONUŞLANMA VE ÜRÜN DESTEĞİ ===

+

==== <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:

1.150. satır: 1.156. satır:

* Farklı alanlar arasında kullanımdan kaynaklanan etkileşimler gibi bilgilerin toplanması gerekir.

−

=== 5.1.2.4. KULLANIMA GENEL BAKIŞ ===

+

==== <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:

1.166. satır: 1.172. satır:

Ü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.

−

=== 5.1.3.1. İKMAL KONSEPTİ ===

+

==== <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.

−

=== 5.1.3.2. DESTEK EKİPMANI KONSEPTİ ===

+

==== <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.

−

=== 5.1.3.3. PERSONEL ENTEGRASYONU VE EĞİTİM ===

+

==== <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.

−

=== 5.1.3.4. TESİSLER ===

+

==== <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.

−

=== 5.1.3.5. BİLİŞİM VE HABERLEŞME KAYNAKLARI ===

+

==== <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:

1.194. satır: 1.200. satı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

+

'''Tablo 4 Örnek Soru Seti'''

{| class="wikitable"

| colspan="2" |'''Örnek Soru Seti'''

1.391. satır: 1.397. satır:

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:

−

=== 5.2.1.1. Sözleşme Dokümanlarından Türetilen LDA Bilgi ve Verilerinin Seçimi ===

+

==== <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.

1.420. satır: 1.426. satır:

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

−

=== 5.2.1.2. Ürün Kullanım Verilerinden Türetilen LDA Bilgi ve Verilerinin Seçimi ===

+

==== <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.

1.431. satır: 1.437. satır:

* Her tesiste mevcut bakım personeli (branş ve beceriye göre kişi sayısı)

−

=== 5.2.1.3. Ürün Şartnamelerinden Gelen LDA Bilgi ve Verilerinin Seçimi ===

+

==== <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.

1.503. satır: 1.509. satır:

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.

−

=== 5.2.3.1. Ölçüm Değerleri Kategorisi ===

+

==== <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:

1.510. satır: 1.516. satır:

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

−

=== 5.2.3.2. Toleransların Belirlenmesi ===

+

==== <big>5.2.3.2. Toleransların Belirlenmesi</big> ====

Tanımlanan her bir ölçüm değeri için ilgili toleranslar ifade edilmelidir.

1.516. satır: 1.522. satır:

* 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).

−

=== 5.2.3.3. Kabul Kriterlerinin Oluşturulması ===

+

==== <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.

1.525. satır: 1.531. satır:

* Belgelenen şeklin şartlı kabul edildiğini belirten AAK'nin durumu (Örneğin; genel olarak kabul edilebilir ancak yeniden çalışma gerektiren).

−

=== 5.2.3.4. Özel Kuralların Oluşturulması ===

+

==== <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:

1.534. satır: 1.540. satır:

Son olarak, doğrulamaya tabi olan verilerin ve/veya diğer bilgilerin doğrulanması için kriterler oluşturulmalıdır.

−

=== 5.2.4.1. Ölçülebilir Hedef Değerlerin Belirlenmesi ===

+

==== <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.

−

=== 5.2.4.2. Öngörülen Değerlerin Doğrulanması ===

+

==== <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.

−

=== 5.2.4.3. Doğrulama Yöntemi ===

+

==== <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:

1.550. satır: 1.556. satır:

* Uzun süreli denemeler sırasında doğrulama (Örneğin; belirli bir “olgunluk aşaması” sırasında).

−

=== 5.2.4.4. Özel Amaçlar için Doğrulama ===

+

==== <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.

−

=== 5.2.4.5. Durum Kodlarının Güncellenmesi ===

+

==== <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.

1.563. satır: 1.569. satır:

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]]

−

[[Dosya:~~Ekran Alıntısı 1~~.jpg|sol|küçükresim|~~700x700pik~~]]

−

1.649. satır: 1.650. satır:

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.

−

=== 5.3.2.1. LDA Aday Kalem Listesi ===

+

==== <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.

1.658. satır: 1.659. satı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.

−

=== 5.3.2.2. LDA Adaylarının Sınıflandırılması ===

+

==== <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:

1.669. satır: 1.670. satır:

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

−

~~===~~ 5.3.2.2.1. LDA Adayları Seçim Süreci ve Kriterleri ~~===~~

+

'''<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.

−

~~===~~ 5.3.2.2.2. LDA Adaylarının Seçilmesi, Tanımlanması ve Sınıflandırılması ~~===~~

+

'''<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:~~Şekil 5 LDA adayı belirlenmesinde kullanılabilecek örnek akış diyagramı (Yapısal Olmayan Malzeme için) (S3000L)~~.jpg|sol|küçükresim|~~779x779pik~~|Şekil 5 LDA ~~adayı belirlenmesinde kullanılabilecek örnek akış diyagramı~~ (Yapısal Olmayan Malzeme için) (S3000L)]]

+

−

1.711. satır: 1.706. satır: −

[[Dosya:Şekil 6 LDA adayı belirlenmesinde kullanılabilecek örnek akış diyagramı (Yapısal Malzeme için).jpg|sol|küçükresim|693x693pik|Şekil 6 LDA adayı belirlenmesinde kullanılabilecek örnek akış diyagramı (Yapısal Malzeme için)]]

1.720. satır: 1.714. satır: +

1.869. satır: 1.864. satır:

* Bakım/onarım görevleri aynı veya benzer olan malzemeleri gruplamak mümkün mü?

−

=== 5.3.2.3. LDA İş Tanı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.

1.901. satır: 1.896. satır:

** Hazır alım konseptine ilişkin değerlendirme

−

=== 5.3.2.4. LDA Planı ===

+

==== <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.

1.962. satır: 1.957. satır:

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.

−

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

+

==== <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.

1.972. satır: 1.967. satır:

* 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.).

−

=== 5.4.1.2. Karşılaştırmalı Analiz ===

+

==== <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 .

1.993. satır: 1.988. satır:

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

+

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.

−

=== 5.4.1.3. İnsan Faktörü (Ergonomi) Analizi ===

+

==== <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.

2.013. satır: 2.008. satır:

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

−

=== 5.4.1.4. Konfigürasyon Değerlendirme ===

+

==== <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.

−

=== 5.4.1.5. Güvenilirlik Analizlerinin Değerlendirilmesi ===

+

==== <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.

−

=== 5.4.1.6. İdame Edilebilirlik Analizi ===

+

==== <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.

2.041. satır: 2.036. satır: −

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

+

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

{| class="wikitable"

|'''Analiz Edilen Kalemler'''

2.069. satır: 2.064. satı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.

−

=== 5.4.1.7. Test Edilebilirlik Analizi ===

+

==== <big>5.4.1.7. Test Edilebilirlik Analizi</big> ====

Test edilebilirlik analizi için gerekli olan girdiler;

2.087. satır: 2.082. satır:

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.

−

=== 5.4.1.8. Olaya Dayalı Bakıma İlişkin Analiz Faaliyetleri ===

+

==== <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>'''

−

~~=== 5.4.1.8.1. Hata Türleri Etkileri ve Kritiklik Analizi/Hata Türleri Etkileri Analizi (HTEKA/HTEA) ===~~

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.

2.104. satır: 2.099. satır:

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.

−

~~===~~ 5.4.1.8.2. Hasar Analizi ~~===~~

+

'''<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.

−

~~===~~ 5.4.1.8.3. Özel Olay Analizi ~~===~~

+

<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.

2.122. satır: 2.119. satır:

* Sert İniş (Hava Araçları)

−

=== 5.4.1.9. Planlı Bakım Analizi ===

+

==== <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.

−

=== 5.4.1.10. Onarım Seviyesi Analizi (OSA) ===

+

==== <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ı

+

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

{| class="wikitable"

|'''OSA Sınıflandırması'''

2.144. satır: 2.141. satır:

Her durumda, uygulanabilir olduğu ölçüde OSA yapılması zorunlu bir analizdir.

−

=== 5.4.1.11. Bakım Görev Analizi (BGA) ===

+

==== <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.

2.153. satır: 2.150. satır:

* Tanımlanmış görevden önce ve sonra yapılması gerekli olan görevler.

−

=== 5.4.1.12. Yazılım Destek Analizi ===

+

==== <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.

2.162. satır: 2.159. satır:

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.

−

=== 5.4.1.13. Lojistik İlişkili Operasyonlar Analizi ===

+

==== <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.

−

=== 5.4.1.14. Eğitim İhtiyaçları Analizi (EİA) ===

+

==== <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.

−

=== 5.4.1.15. Envanterden Çıkarma Analizi ===

+

==== <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.

2.187. satır: 2.184. satır:

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.

−

=== 5.5.1.1. LDA Süreci Değerlendirme Kurallarının Konulması ===

+

==== <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:

+

==== 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.

2.208. satır: 2.205. satır:

Ü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 ~~4’de~~ ise zaman aralıkları hakkında açıklamalar verilmiştir.

+

Ş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:~~Şekil 7 Müşteri ile yüklenici~~ .jpg|sol|küçükresim|~~700x700pik~~|Şekil 7 Müşteri ~~ile yüklenici arasındaki veri alışverişi süreci~~ (~~örnek~~)]]

+

2.242. satır: 2.239. satır: −

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

+

'''Tablo 7 Yorumlama Sürecinin ZamanTakvimi ile Açıklanması'''

{| class="wikitable"

|'''Zaman'''

2.276. satır: 2.273. satır:

* Anlaşılmayan yorumlarla ilişkili yüklenici cevaplarının dağıtılması (bkz: 5.5.1.7)

−

=== 5.5.1.2. Veri ve doküman değişimi için uygun kuralların koyulması ===

+

==== <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:

2.285. satır: 2.282. satır:

* Dağıtım paydaşları ve uyulması gereken akış.

−

=== 5.5.1.3. Yüklenici tarafından LDA veri ve dokümanlarının toplanması ===

+

==== <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:

2.292. satır: 2.289. satır:

* Endüstri içi kalite kontroller, harmonizasyon ve teslimat anlaşması performansları.

−

=== 5.5.1.4. Yüklenici tarafından LDA veri/dokümanlarının teslimatı ===

+

==== <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:

2.298. satır: 2.295. satır:

* Yüklenici iç dokümantasyonu ve resmi LDA teslimatlarının dağıtımı.

−

=== 5.5.1.5. Müşteri değerlendirmesi ve değerlendirme sonuçları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:

2.305. satır: 2.302. satır:

* Müşteri yanıtının yükleniciye dağıtımı.

−

=== 5.5.1.6. Yüklenici tarafından müşteri cevaplarının 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:

2.314. satır: 2.311. satır:

* Genel yorum ve anlaşmazlıklara yüklenici cevabının uyumlandırılarak hazırlanması.

−

=== 5.5.1.7. Anlaşılmayan yorumlarla ilişkili yüklenici cevaplarının dağıtılması ===

+

==== <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.

2.357. satır: 2.354. satır:

* LDA gözden geçirme basamağı-4. Bakım Görev Analizi (bkz: 5.6.3.4).

−

=== 5.6.3.1. Aday Kalem Listesi ve Bakım Analizi Ataması ===

+

==== <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:

2.366. satır: 2.363. satır:

* Aday kalem seviyesindeki her tasarım konfigürasyonundaki değişikliklerin LDA veri tabanında yönetilmesi.

−

=== 5.6.3.2. Onarım Seviyesi Analizi ve Bakım Konsepti Bilgisi ===

+

==== <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:

2.374. satır: 2.371. satır:

* Red veya alternatif çözüm olabilecek bakım konsepti üzerindeki müşteri kararı.

−

=== 5.6.3.3. HTEA ve Planlı Bakım Analizi sonuçları ===

+

==== <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.

−

=== 5.6.3.4. Bakım Görev ~~Analizi~~ ===

+

==== <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.

2.384. satır: 2.381. satır:

* 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)

−

=== 5.6.4. DURUM KODU ÖRNEKLERİ ===

+

==== <big>5.6.4. DURUM KODU ÖRNEKLERİ</big> ====

Durum kodları aşağıdaki ifadeleri yansıtacak şekilde düzenlenir:

2.392. satır: 2.389. satır:

* Gözden geçirme aşaması göstergesi

−

Tablo 7, 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, 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 7 Durum ~~kodu örnekleri~~

+

'''Tablo 8 Durum Kodu Örnekleri'''

{| class="wikitable"

|'''Kod'''

2.463. satır: 2.460. satır:

Güvenilirlik, idame edilebilirlik ve desteklenebilirlik ürünün kullanıma hazır olmasına etki eden faktörlerdir (Şekil 8).

−

[[Dosya:~~Şekil 8~~ Kullanıma Hazır Olma Kırılımı.jpg|sol|küçükresim|~~650x650pik~~|Şekil 8 Kullanıma Hazır Olma Kırılımı]]

+

2.488. satır: 2.485. satır:

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İ= 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:

−

~~Aa = Ulaşılabilir Kullanıma Hazır Olma~~

−

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

−

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

+

Aİ= 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]]

+

Aa = 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]]

+

AO= Operasyonel Kullanıma Hazır Olma

2.703. satır: 2.727. satı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. [~~http~~://~~ssbwiki~~.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]).

+

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 ===

2.778. satır: 2.802. satır:

Kullanım safhası LDA süreci genel hatlarıyla Şekil 10‘da verilmiştir.

−

[[Dosya:~~Şekil 10~~ Kullanım ~~safhası~~ LDA ~~süreci~~.jpg|sol|küçükresim|600x600pik|Şekil 10 Kullanım ~~safhası~~ LDA ~~süreci~~]]

+

+

2.835. satır: 2.861. satır:

Ş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|sol|küçükresim|~~650x650pik~~|Şekil 11 Kullanım ve ~~destek safhası~~* ~~bakım gözden geçirme süreci~~ ]]

+

2.872. satır: 2.898. satır: −

~~<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:Şekil 12 Modifikasyon ve değişiklik uygulaması için kullanım safhası LDA.jpg|sol|küçükresim|750x750pik|Şekil 12 Modifikasyon ve değişiklik uygulaması için kullanım safhası LDA]]

2.885. satır: 2.906. satır: +

<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.

+

2.923. satır: 2.951. satır:

=== 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öntebilmesi~~ 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ünellenmesi~~ gerekmektedir.

+

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:~~Şekil 13~~ Kullanım ve Destek Safhaları Malzeme Yönetimi Süreci.jpg|sol|küçükresim|700x700pik|Şekil 13 Kullanım ve Destek Safhaları Malzeme Yönetimi Süreci]]

+

−

2.974. satır: 2.997. satı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. [~~http~~://~~ssbwiki~~.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]).

+

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İ =

3.061. satır: 3.084. satı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:~~Şekil 14 Lojistik Destek Analizleri ile~~ Teknik Dokümantasyon ~~Arasındaki İlişki~~.jpg|sol|küçükresim|550x550pik|Şekil 14 Lojistik Destek Analizleri ile Teknik Dokümantasyon Arasındaki İlişki]]

+

3.103. satır: 3.126. satır:

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 8 farklı türdeki yedek parçalara genel bir bakış ve bunların tanımlama sürecinde dikkate alınması gerekenleri göstermektedir.

+

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 8 LDA Tarafından Belirlenen Farklı Yedek Parça Türleri Listesi

+

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

{| class="wikitable"

|'''Yedek Parça Tipi'''

3.132. satır: 3.155. satır:

|}

LDA ile malzeme desteği drasındaki ilişki Şekil 15’de gösterilmektedir.

−

[[Dosya:~~Şekil 15 Lojistik~~ Destek Analizleri ile Malzeme Desteği Arasındaki İlişki.jpg|sol|küçükresim|550x550pik|Şekil 15 Lojistik Destek Analizleri ile Malzeme Desteği Arasındaki İlişki]]

+

3.172. satır: 3.195. satır:

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:~~Şekil 16 LDA~~ ve Test Ekipmanları Arasındaki İlişki.jpg|sol|küçükresim|~~450x450pik~~|Şekil 16 LDA ve Test Ekipmanları Arasındaki İlişki]]

+

3.200. satır: 3.223. satır:

== 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:~~Şekil 17 LDA~~ ve Eğitim ~~Arasındaki İlişki~~.jpg|sol|küçükresim|550x550pik|Şekil 17 LDA ve Eğitim Arasındaki İlişki]]

+

3.306. satır: 3.329. satı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 9 Analiz Faaliyetleri Seçim Kriterleri

+

'''Tablo 10 Analiz Faaliyetleri Seçim Kriterleri'''

{| class="wikitable"

|'''Kriter Grubu'''

3.385. satır: 3.408. satır:

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’de~~ verilmiştir.

+

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

−

Tablo 10 Analiz Faaliyetleri Öneri Matrisi

+

'''Tablo 11 Analiz Faaliyetleri Öneri Matrisi'''

{| class="wikitable"

|Seviye

3.522. satır: 3.545. satı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.[~~http~~://~~ssbwiki~~.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.

+

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:~~Şekil~~ 18 ~~Ömür devri safhalarına göre analiz akış süreci~~ .jpg|sol|küçükresim|~~700x700pik~~|Şekil 18 Ömür ~~devri safhalarına göre analiz akış süreci~~]]

+

−

3.573. satır: 3.594. satır:

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.

−

=== 11.2.1.1. Erken Dönem Analiz Faaliyetleri ===

+

==== <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.

−

=== 11.2.1.2. Tasarım ve Geliştirme Dönemi Analiz Faaliyetleri ===

+

==== <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:

3.600. satır: 3.621. satır:

* Eğitim ihtiyaçları analizi

−

=== 11.2.1.3. Kullanım Dönemi Analiz Faaliyetleri ===

+

==== <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.

−

=== 11.2.1.4. Sistem Ömür Devri Safhalarındaki Aktivitelerin Özeti ===

+

==== <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 11 Sistem Ömür Devri Safhalarındaki Aktivitelerin Özeti

+

'''Tablo 12 Sistem Ömür Devri Safhalarındaki Aktivitelerin Özeti'''

{| class="wikitable"

| rowspan="2" |'''Ön Konsept & Konsept Safhası'''

3.681. satır: 3.702. satır:

= 12. EKLER =

−

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

+

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

+

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

−

~~== 1. GİRİŞ ==~~

İ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.

3.690. satır: 3.713. satır:

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.

−

~~== 2. LOJİSTİK DESTEK ANALİZLERİ VE İNSAN FAKTÖRLERİ ==~~

−

== 2.1. FİZİKSEL KABİLİYETLER VE KISITLAMALAR ==

+

<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.

−

== 2.2. TEHLİKELİ DURUMLARDAN KAYNAKLANAN KISITLAMALAR ==

+

'''<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.

3.704. satır: 3.730. satır:

Ç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.

−

~~== 3. İNSAN FAKTÖRÜ ANALİZLERİ ==~~

−

== 3.1. TASARIMA ETKİ ==

+

<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.

3.713. satır: 3.741. satır:

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.

−

== 3.2. LDA İÇİN İLKELER ==

+

<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.

3.722. satır: 3.751. satır:

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.

−

== 4. DİKKATE ALINMASI GEREKEN İNSAN FAKTÖRLERİ ==

+

'''<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.

−

== 4.1. ANTROPOMETRİK HUSUSLAR ==

+

<big>'''4.1. ANTROPOMETRİK HUSUSLAR'''</big>

−

* Görüş hattı (yatay ve dikey görme alanı)

* Ses sinyali gereksinimleri

3.734. satır: 3.763. satır:

* Kaldırılabilecek ünitelerin azami ağırlığı

* Destek ekipmanlarının azami ağırlığı

−

+

'''<big>4.2. ERGONOMİK HUSUSLAR</big>'''

−

== 4.2. ERGONOMİK HUSUSLAR ==

−

* Kumandaların tasarımı (ör. Anahtarlar, çevirme kolları, kumanda kolları, el çarkları, pedallar, düğmeler, vs.)

* Minimum tutacak ölçüleri

3.743. satır: 3.770. satır:

* Kapı ve erişim paneli ölçüleri

* Aydınlatma gereksinimleri

−

+

'''<big>4.3. ÇEVRESEL HUSUSLAR</big>'''

−

== 4.3. ÇEVRESEL HUSUSLAR ==

−

* Etkin sıcaklık

* Aşırı sıcak ve soğuk sıcaklık limitleri

3.754. satır: 3.779. satır:

* Toz ve duman gibi kirliliğie maruz kalma

* Gürültü limitleri

−

= EK-B HTE(K)A ve SONUÇLARININ LDA İÇERİSİNDE KULLANIMI =

+

== EK-B HTE(K)A ve SONUÇLARININ LDA İÇERİSİNDE KULLANIMI ==

+

<big>'''1. GENEL'''</big>

−

~~== 1. GENEL ==~~

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).

3.784. satır: 3.809. satır:

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

−

== 2. TASARIM VE GELİŞTİRME FAALİYETLERİNDE HTEKA ==

+

'''<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.

3.791. satır: 3.817. satır:

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.

−

== 3. LDA HTEA VE TASARIM YÖNELİMLİ HTEKA ==

+

<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.

−

== 4. LDA HTEA VE İDAME EDİLEBİLİRLİK, BAKIM VE EMNİYET ANALİZLERİ ==

+

<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İ =

+

== EK-C HASAR VE ÖZEL OLAY ANALİZLERİ ==

+

'''<big>1. GENEL</big>'''

−

~~== 1. GENEL ==~~

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.

3.835. satır: 3.863. satır:

|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>

−

== 2. ~~ANALİZ SÜRECİ ==~~

+

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

−

~~== 2.1. ÖZEL OLAYLARIN TANIMLANMASI ==~~

+

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.

−

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 ~~12’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 12 Olayların Sebep Tiplerine ~~ilişkin~~ Örnekler

+

'''Tablo 13 Olayların Sebep Tiplerine İlişkin Örnekler'''

{| class="wikitable"

| colspan="2" |'''Sebep Tipleri'''

3.880. satır: 3.908. satır:

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

−

Tablo 13 Olayların ~~meydana gelme olasılıkları~~

+

'''Tablo 14 Olayların Meydana Gelme Olasılıkları'''

{| class="wikitable"

|'''Puanlama'''

3.908. satır: 3.936. satır:

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.

−

== 2.1. POTANSİYEL ARIZALARIN TANIMLANMASI ==

+

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

+

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

3.914. satır: 3.943. satır:

* 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’de~~ teknoloji seviyeleri ve açıklamaları ile bunların puanlama bilgileri verilmiştir.

+

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 14 Teknoloji Seviyeleri

+

'''Tablo 15 Teknoloji Seviyeleri'''

{| class="wikitable"

|'''Puanlama'''

3.935. satır: 3.964. satır:

|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’da~~ verilmiştir.

+

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 15 Teknoloji ~~hassasiyetinin değerlendirilmesi~~

+

'''Tablo 16 Teknoloji Hassasiyetinin Değerlendirilmesi'''

{| class="wikitable"

|'''Puanlama'''

3.963. satır: 3.992. satır:

|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’de~~ verilmiştir.

+

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 16 Teknoloji-Hassasiyet Değerlendirmesi

+

'''Tablo 17 Teknoloji-Hassasiyet Değerlendirmesi'''

{| class="wikitable"

| colspan="2" rowspan="2" |

3.998. satır: 4.027. satır:

|4

|}

+

'''<big>2.2. ÜRÜNÜN ELEMAN YA DA KISIMLARININ TANIMLANMASI</big>'''

−

~~== 2.2. ÜRÜNÜN ELEMAN YA DA KISIMLARININ TANIMLANMASI ==~~

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

4.006. satır: 4.035. satı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.

−

== 2.3. KRİTİKLİK ANALİZİ ==

+

<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.

4.012. satır: 4.042. satır:

* 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>'''

−

~~== 2.4. BAKIM GÖREV GEREKSİNİMLERİNİN TANIMLANMASI ==~~

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İ =

+

== EK-D LOJİSTİK İLİŞKİLİ OPERASYONLAR ANALİZİ ==

+

<big>'''1. GENEL'''</big>

−

~~== 1. GENEL ==~~

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.

−

== 2. ÜRÜN KULLANIM DESTEĞİ ==

+

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

+

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

−

~~== 2.1. KULLANIMA HAZIRLIK ==~~

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).

−

== 2.2. YÜKLEME VE İNDİRME ==

+

<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.

−

== 3. PAKETLEME, ELLEÇLEME, DEPOLAMA VE ULAŞTIRMA (PEDU) ==

+

'''<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.

−

== 3.1. PAKETLEME ==

+

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

+

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

4.045. satır: 4.079. satır:

* 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>'''

−

~~== 3.2. ELLEÇLEME ==~~

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

4.055. satır: 4.089. satır:

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.

−

== 3.3. DEPOLAMA ==

+

'''<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:

4.066. satır: 4.101. satır:

* 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>

−

~~== 3.4. İSTİFLEME ==~~

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.

−

== 3.5. TAŞIMA ==

+

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

+

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

4.080. satır: 4.116. satır:

* Taşıma sandığı konsepti olacak mı?

* Taşımada kızak ve palet kullanımı olacak mı?

+

'''<big>3.6. BAĞLAMA</big>'''

−

~~== 3.6. BAĞLAMA ==~~

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.

−

== 4. ENVANTERDEN ÇIKARMA VE GERİ DÖNÜŞÜM ==

+

'''<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.

−

== 5. LOJİSTİK İLİŞKİLİ OPERASYONLAR İÇİN KONTROL LİSTESİ ==

+

'''<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 =

+

== EK-E PLANLI BAKIM PROGRAMI GELİŞTİRME ==

+

'''<big>1. GENEL</big>'''

−

~~== 1. GENEL ==~~

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.

−

== 2. ANALİZ YÖNTEMLERİ ==

+

'''<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’.)

4.118. satır: 4.157. satır:

Yüksek yoğunluklu radyasyon alanları analizi

−

== 3. ÖNLEYİCİ BAKIM GÖREV GEREKSİNİMLERİ İÇİN EŞİKLER, ARALIKLAR VE TETİKLEYİCİ OLAYLAR ==

+

'''<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;

4.139. satır: 4.179. satı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>'''

−

== 4. TANIMLANACAK ÖNLEYİCİ BAKIM GÖREV GEREKSİNİMLERİNİN (PMTR) BELİRLENMESİ İÇİN KULLANILABİLECEK KAYNAKLAR ==

−

* Yasal düzenlemelerden gelen gereksinimler

* Emniyet Analizi/hata ağacı analizinden gelen gereksinimler

4.152. satır: 4.190. satır:

İ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.

−

== 5. KULLANICI BAKIM PROGRAMININ GELİŞTİRİLMESİ ==

+

'''<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.

4.185. satır: 4.224. satır:

* 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>'''

−

~~== 6. GÜVENİLİRLİK MERKEZLİ BAKIM (GMB) ANALİZİ YAKLAŞIMI ==~~

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.

4.192. satır: 4.231. satır:

Ş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:~~Şekil 19 GMB~~ – BGA Arayüzü.jpg|sol|küçükresim|650x650pik|Şekil 19 GMB – BGA Arayüzü]]

+

4.229. satır: 4.268. satır: −

= EK-F ONARIM SEVİYESİ ANALİZİ (OSA) =

+

== EK-F ONARIM SEVİYESİ ANALİZİ (OSA) ==

+

'''<big>1. GENEL</big>'''

−

~~== 1. GENEL ==~~

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.

4.240. satır: 4.279. satır:

OSA BGA’yı tamamlayıcı niteliktedir. Saha inceleme rapolarının, mühendislik verilerininin ve proje gereksinimlerinin girdi olarak kullanıldığı OSA, tasarımın netlik kazanması ile geliştirme safhasında bakım görev analizine paralel bir şekilde yürütülür. Diğer taraftan ihtiyaç olması halinde (tasarım değişikliği, modifikasyon vb) ilgili safhalarda güncellenebilecek bir analizdir.

−

== 2. ANALİZ SÜRECİ ==

+

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

+

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

4.253. satır: 4.293. satır:

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 17 Onarım Seviyesi Analizi Süreç Adımları

+

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

{| class="wikitable"

|'''İŞLEM ADIMI'''

4.371. satır: 4.411. satır:

Bu örnek kapsamında, elektronik komplenin yenisi ile değiştirilmesi durumunda arızalı elektronik komplenin onarılması ya da elden çıkarılması ve bu faaliyetlerin hangi seviyede yapılacağı ile ilgili karar OSA kapsamında verilecektir. Bu karar verilirken de hem onarım maliyeti (işçilik, eğitim vs.) hem de asıl malzeme maliyeti ile elektronik komplenin güvenilirlik değeri göz önünde bulundurulmalıdır.

−

== 2.1. OSA ~~VERİLERİ ==~~

+

'''<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.

−

== 2.2. BAKIM SEVİYELERİNİN BELİRLENMESİ ==

+

'''<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 ~~18’da~~ 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’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 18 Bakım Seviyeleri ve Tanımlı Görevlere İlişkin Örnekler

+

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

{| class="wikitable"

|'''Seviye Adı'''

4.431. satır: 4.473. satır:

· Yazılım modifikasyonları

|}

+

'''<big>2.3. BAKIM ÇÖZÜM ÖNERİSİNİN OLUŞTURULMASI</big>'''

−

~~== 2.3. BAKIM ÇÖZÜM ÖNERİSİNİN OLUŞTURULMASI ==~~

Hem maliyet hem de teknik kriterlerin birlikte değerlendirilmesi kritiktir. BGA kapsamında belirlenen görevler üzerinden değerlendirme hem teknik hem mali olarak yapılır ve onarım kararı ya da envanterden çıkarma kararı verilir. Her bir görev kapsamında bu kararlar verildikten sonra, bu görevlerin hangi seviyelerde yapılacağı belirlenir. Ayrıca, tanımlanan benzer bakım faaliyetlerinin mümkün olduğunca tek bir bakım yeri için tanımlanmış olması da (onarım yapılacak kalemin bir kısmının bir bakım merkezinde bir kısmının başka bir bakım merkezinde yapılmaması gibi) önemlidir. Yapılan tüm analiz çalışması sonunda sistemin bakım çözüm önerisi oluşturulmuş olacaktır.

Örnek OSA tablosu:

−

[[Dosya:~~Osa~~.~~png~~|sol|küçükresim|~~990x990pik~~]]

+

[[Dosya:TSSÖDYP06.ÖRNEK OSA.jpg|alt=|sol|küçükresim|772x772pik]]

+

4.491. satır: 4.534. satır:

|}

−

~~= EK-G BAKIM GÖREV ANALİZİ (BGA) =~~

−

== 1. GENEL ==

+

== 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.

4.508. satır: 4.556. satı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.

−

== 2. ANALİZLER ==

+

'''<big>2. ANALİZLER</big>'''

+

'''<big>2.1. BAKIM GÖREVLERİNİN BELİRLENMESİ</big>'''

−

~~== 2.1. BAKIM GÖREVLERİNİN BELİRLENMESİ ==~~

Bakım görevleri belirlenirken ürün kırılımının yapılmış ve LDA adayı kalemlerin listelenmiş olması gerekmektedir. LDA adayı olarak seçilen her bir kalem için bakım görevleri belirlenmelidir.

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:~~Şekil~~ 20 ~~Bakım Görevlerinin Belirlenmesi~~.jpg|sol|küçükresim|450x450pik|Şekil 20 Bakım Görevlerinin Belirlenmesi]]

+

4.540. satır: 4.589. satır: +

Ö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>'''

−

Özel olay sonrası gerekli olan muayeneler ve/veya GMB sonrasında; genel, kullanıcı talebine bağlı ve/veya hazırlık için yapılacak faaliyetlerden kaynaklı bakım görevleri ortaya çıkabilir. Bu faaliyetlerin de BGA kapsamında değerlendirilmesi gerekmektedir.

−

~~== 2.2. BAKIM GÖREV YAPILARININ OLUŞTURULMASI ==~~

Görev yapıları oluşturulurken görevler analiz faaliyetinde kolaylık sağlaması açısından iki sınıfa ayrılır.

4.566. satır: 4.613. satır:

'''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 ~~19’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.

+

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;

4.574. satır: 4.621. satır:

2. durum; elektronik komplenin onarılabilir bir kalem olarak tanımlanmış olması

−

Tablo 19 Görev Gereksinimleri Örneği

+

'''Tablo 20 Görev Gereksinimleri Örneği'''

{| class="wikitable"

|'''Olay (Event)'''

4.601. satır: 4.648. satı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örevler’den~~ ö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.

+

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:~~Şekil 21 Görev~~ Yapılarının Oluşturulması.jpg|sol|küçükresim|~~343x343pik~~|Şekil 21 Görev Yapılarının Oluşturulması]]

+

+

4.648. satır: 4.702. satır:

Bazı tasarımsal sebeplerden kaynaklı sistem hataları öngörülemeyebilir. Hasar ya da özel olayların meydana gelmesi ile ilgili benzer sistemler ve/veya benzer projeler kapsamında edinilmiş herhangi bir tecrübe varsa, bu tecrübe öngörülemeyen olayların ne kadar sıklıkla meydana gelebileceği ve ilgili bakım faaliyetlerinin sıklığı konusunda fikir verebilir. Bu nedenle, bakım faaliyetleri ile ilgili planlama yapılırken uygulanabilir olduğu ölçüde öngörülemeyen bu tarz olayların da dikkate alınması önemlidir.

−

== 2.3. GÖREV KAYNAKLARININ BELİRLENMESİ ==

+

'''<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 20’de verilmiştir.

−

~~Tablo 20~~ Görev kaynaklarına örnekler

+

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'''

4.680. satır: 4.735. satır:

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 21 Montaj Prosedürü için Gerekli Görev Kaynakları Örneği

+

'''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ı'''

4.724. satır: 4.779. satır:

|3 dk

|}

−

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

+

'''Tablo 23 Elektronik Komple İçin Montaj Prosedürü-Görev Kaynakları Özeti'''

{| class="wikitable"

|'''Kaynak tipi'''

4.789. satır: 4.844. satır:

Örnek BGA Formu:

[[Dosya:Bga.jpg|sol|küçükresim|800x800pik]]

−

+

== EK-H YAZILIM DESTEK ANALİZİ (YDA) ==

+

'''<big>1. GENEL</big>'''

−

~~= EK-H YAZILIM DESTEK ANALİZİ (YDA) =~~

−

~~== 1. GENEL ==~~

Sistemin desteklenebilirliğini sağlayabilmek için LDA süreci kapsamında yazılımlar için de YDA süreci yürütülür. YDA, maliyet etkin bir yazılım destek konseptinin kurulması için donanıma benzer şekilde yazılım açısından da sistemi desteklemeyi amaçlar. Yazılım Destek Konsepti (YDK) belirlenirken, bir ürün içerisindeki yazılımın kullanımının devamlılığını sağlamak için gerekli tüm aktivitelerin dikkate alınması gerekir. YDA’da, yeterli bir YDK geliştirmek için ekipman, araç, personel, dokümantasyon, altyapı, gerekli yetkinlik ve eğitim gibi hususlar analiz edilir.

4.859. satır: 4.874. satır:

* 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>'''

−

~~== 2. FARKLI PROJE SAFHALARINDA YDA ==~~

YDA’nın yazılım içeren bir ürün için tüm ömür devri boyunca uygulanması gerekmektedir. Yapılacak faaliyetler, proje safhaları dikkate alınarak gerçekleştirilmelidir. Örneğin, geliştirme safhasında, YDA’nın uygulaması önemlidir çünkü yazılımın gelecekteki yükleme, servis ve modifikasyonları için desteklenebilirlik gereksinimleri açısından yazılım mimarisi ve tasarımı etkilenebilir.

−

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

+

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

{| class="wikitable"

|'''Geliştirme'''

4.898. satır: 4.913. satır:

Erken fazlarda, YDA temel yazılım destek gereksinimlerinin belirlenmesine yardımcı olur. Envanterden çıkarma safhasında, donanımlar için olduğu gibi yazılımlar için de envanterden çıkarma prosedürlerinin tanımlanması gerekmektedir. Eğer yazılım verisi yeni geliştirilecek sistemler veya ilerleyen operasyonlarda kullanılacaksa, verilerin yer değiştirilmesi hususu kapsamında uygulanması gereken prosedürlerin de göz önünde bulundurulması ve tanımlanması gerekmektedir.

−

== 3. YAZILIM KIRILIM KONSEPTİ ==

+

'''<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.

4.913. satır: 4.929. satır:

Yazılım modifikasyonuna yönelik olarak işlevsel yazılım kırılımı yazılım tasarım gereksinimlerini takip eder. Klasik yazılım konfigürasyon kalem seviyesi yaklaşımına ek olarak daha üst seviyede (altsistem ve sistem seviyesi) yazılımın sisteme entegrasyonunun da değerlendirilmesi gerekmektedir.

−

== 4. YAZILIM DESTEK ANALİZİ ==

+

'''<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.

−

== 4.1. YDA ADAY KALEM SEÇİMİ ==

+

'''<big>4.1. YDA ADAY KALEM SEÇİMİ</big>'''

+

Donanım aday kalem seçimiyle benzer yaklaşım izlenecektir.

−

== 4.2. YAZILIM BAKIMI ==

+

'''<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.

4.932. satır: 4.951. satır:

Yazılım hataları donanım hataları gibi belirli onarım değişim prosedürleriyle ele alınamaz. Bu yüzden bir yazılım hatasında alınması gerekli olan aksiyon hemen bilinemeyeceğinden alınamayabilir. Örneğin bir yazılım hatasında sistemi kapatıp açmak hatayı düzeltebilirken, diğer bir hatada sistemi kapattıktan sonra sistemin daha fazla zarar görmemesi için tekrar açılmaması gerekebilecektir. Ya da bir donanımdaki bozulma sebebiyle de yazılım çalışmayabilir. Bu durumda yazılım kaynak kodunda gerçek bir doğal hata bulunmamakta olup bu durum dış hasar olarak ele alınır.

−

== 4.3. YDA KAPSAMINDA HTEKA/HTEA ==

+

'''<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.

4.939. satır: 4.959. satır:

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).

−

== 4.4. YAZILIM İÇİN PLANLI BAKIM ANALİZİ (PBA) ==

+

'''<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.

−

== 4.5. YAZILIM İÇİN OSA ==

+

'''<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.

−

== 4.6. YAZILIM İÇİN BGA ==

+

'''<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.

−

== 5. YAZILIM DESTEK KONSEPTİ ÇERÇEVESİ ==

+

'''<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.

4.965. satır: 4.989. satır:

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.

−

== 5.1. YAZILIM DESTEK PROFİLİ ==

+

'''<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;

4.985. satır: 5.010. satır:

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.

−

== 5.2. DESTEK FONKSİYONLARI ==

+

'''<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;

4.991. satır: 5.017. satır:

* 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>'''

−

~~=== 5.2.1. OPERASYONEL SERVİS DESTEĞİ ===~~

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.

4.999. satır: 5.025. satır:

Gömülü yazılımların veya bellenimlerin yükleme görevleri BGA’da belirlenmelidir.

−

~~===~~ 5.2.2. YÖNETİM DESTEĞİ ~~===~~

+

'''<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.

−

~~===~~ 5.2.3. YAZILIM MODİFİKASYON DESTEĞİ ~~===~~

+

'''<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.

−

~~== 6. DESTEK SINIFLARI ==~~

−

== 6.1. SÜREÇLER ==

+

'''<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.

−

== 6.2. ÜRÜN ==

+

'''<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.

−

== 6.3. ÇEVRE ==

+

'''<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.

−

== 7. DESTEKLENEBİLİRLİK FAKTÖRLERİ ==

+

'''<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.

−

== 7.1. UYUMLULUK MATRİSİ ==

+

'''<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 ~~25’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 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 24 Uyumluluk Matrisi

+

'''Tablo 25 Uyumluluk Matrisi'''

{| class="wikitable"

|

5.038. satır: 5.072. satır:

|x

|}

+

'''<big>7.2. DOKÜMANTASYON</big>'''

−

~~== 7.2. DOKÜMANTASYON ==~~

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.

−

== 7.3. YAZILIM YÜKLEME VE KALDIRMA ==

+

'''<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.

−

== 7.4. DONANIMLAR ÜZERİNDE TAŞINMA ==

+

'''<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.

−

== 7.5. GENİŞLEME KAPASİTESİ ==

+

'''<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.

−

== 7.6. MODÜLER YAZILIM TASARIMI ==

+

'''<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.

−

== 7.7. MODİFİKASYON FREKANSI (DEĞİŞİKLİK TRAFİĞİ) ==

+

'''<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.

−

== 7.8. GERİYE DÖNDÜRME ==

+

'''<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.

−

== 7.9. EMNİYET ENTEGRASYONU ==

+

'''<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.

−

== 7.10. GÜVENLİK ==

+

'''<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.

5.072. satır: 5.114. satır:

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.

−

== 7.11. BOYUT ==

+

'''<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.

−

== 7.12. YETKİNLİKLER ==

+

'''<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.

−

== 7.13. YAZILIM DAĞITIMI ==

+

'''<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.

−

== 7.14. TEKNOLOJİ ==

+

'''<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 =

+

== EK-I ÖRNEK LDA PLANI ==

−

'''1 GENEL'''

+

'''<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

5.093. satır: 5.139. satır:

* İş paylaşımı anlaşmaları

−

'''2. SİSTEM TANIMI VE OPERASYONEL KONSEPT TANIMI (BKZ. BÖLÜM 5.1)'''

+

'''<big>2. SİSTEM TANIMI VE OPERASYONEL KONSEPT TANIMI (BKZ. BÖLÜM 5.1)</big>'''

−

'''3. LDA SÜRECİNİN VE ANALİZ FAALİYETLERİNİN AMACI'''

+

'''<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.

5.113. satır: 5.159. satır:

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.

−

'''4. ÜRÜN KIRILIM YÖNTEMİ'''

+

'''<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.

−

'''5. ANALİZ EDİLEN KALEM İÇİN KIRILIM DERİNLİĞİNİN BELİRLENMESİ'''

+

'''<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:

5.126. satır: 5.172. satır:

* 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?

−

'''6. LDA ADAY SEÇİM KRİTERLERİ'''

+

'''<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.

−

'''7. ADAY KALEM LİSTESİ (AKL)'''

+

'''<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.

−

'''8. ADAY ELEMANLAR İÇİN POTANSİYEL ANALİZ FAALİYETLERİ'''

+

'''<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.

5.140. satır: 5.186. satı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.

−

'''9. YEDEK PARÇALARIN BELİRLENMESİ VE YEDEK PARÇA SAYILARININ HESAPLAMASI (Bkz. EK-G BAKIM GÖREV ANALİZİ) '''

+

'''<big>9. YEDEK PARÇALARIN BELİRLENMESİ VE YEDEK PARÇA SAYILARININ HESAPLAMASI (Bkz. EK-G BAKIM GÖREV ANALİZİ) </big>'''

−

'''10. HİZMET İÇİ KULLANIM VE DESTEK SAFHALARI LDA FAALİYETLERİ (Bkz. BÖLÜM 7)'''

+

'''<big>10. HİZMET İÇİ KULLANIM VE DESTEK SAFHALARI LDA FAALİYETLERİ (Bkz. BÖLÜM 7)</big>'''

−

'''11. LDA SÜRECİ-TASARIM SÜRECİ ARAYÜZÜ'''

+

'''<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.

−

'''12. LDA SÜRECİ-ELD SÜRECİ ARAYÜZÜ'''

+

'''<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.

−

'''13. LDA FAALİYETLERİNİN PERFORMANSININ ÖLÇÜLMESİ VE DOĞRULANMASI'''

+

'''<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.

−

'''14. BİLİŞİM HUSUSLARI'''

+

'''<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.

5.162. satır: 5.208. satır: −

'''DOKÜMANIN HAZIRLANMASINDA GÖREV ALAN KURUM/KURULUŞLAR'''

+

'''<big>DOKÜMANIN HAZIRLANMASINDA GÖREV ALAN KURUM/KURULUŞLAR</big>'''

+

SAVUNMA SANAYİİ BAŞKANLIĞI

−

~~SSB~~

+

MİLLİ SAVUNMA BAKANLIĞI

−

~~MSB KKK~~

+

KARA KUVVETLERİ KOMUTANLIĞI

−

~~MSB HvKK~~

+

HAVA KUVVETLERİ KOMUTANLIĞI

−

~~MSB TGM~~

+

TERSANELER GENEL MÜDÜRLÜĞÜ

ASELSAN A.Ş.

Oozdemir

2.239

değişiklik

Değişiklikler

Lojistik Destek Analizleri ve Kayıtları Rehberi (kaynağı gör)

16.02, 25 Ağustos 2022 tarihindeki hâli