2.239
değişiklik
Değişiklikler
Gezinti kısmına atla
Arama kısmına atla
3.686. satır:
3.686. satır: − + + + + − == 1. GİRİŞ == 3.695. satır:
3.697. satır: − == 2. LOJİSTİK DESTEK ANALİZLERİ VE İNSAN FAKTÖRLERİ == − == 2.1. FİZİKSEL KABİLİYETLER VE KISITLAMALAR ==+ + + + − == 2.2. TEHLİKELİ DURUMLARDAN KAYNAKLANAN KISITLAMALAR ==+ + 3.709. satır:
3.714. satır: − == 3. İNSAN FAKTÖRÜ ANALİZLERİ == − == 3.1. TASARIMA ETKİ ==+ + + + 3.718. satır:
3.725. satır: − == 3.2. LDA İÇİN İLKELER ==+ + 3.727. satır:
3.735. satır: − == 4. DİKKATE ALINMASI GEREKEN İNSAN FAKTÖRLERİ ==+ + − == 4.1. ANTROPOMETRİK HUSUSLAR ==+ − 3.739. satır:
3.747. satır: − + − == 4.2. ERGONOMİK HUSUSLAR == − 3.748. satır:
3.754. satır: − + − == 4.3. ÇEVRESEL HUSUSLAR == − 3.759. satır:
3.763. satır: − + + − == 1. GENEL == 3.789. satır:
3.793. satır: − == 2. TASARIM VE GELİŞTİRME FAALİYETLERİNDE HTEKA ==+ + 3.796. satır:
3.801. satır: − == 3. LDA HTEA VE TASARIM YÖNELİMLİ HTEKA ==+ + − == 4. LDA HTEA VE İDAME EDİLEBİLİRLİK, BAKIM VE EMNİYET ANALİZLERİ ==+ + − + + − == 1. GENEL == 3.840. satır:
3.847. satır: + − == 2. ANALİZ SÜRECİ ==+ − == 2.1. ÖZEL OLAYLARIN TANIMLANMASI == 3.913. satır:
3.920. satır: − == 2.1. POTANSİYEL ARIZALARIN TANIMLANMASI ==+ + 4.003. satır:
4.011. satır: + − == 2.2. ÜRÜNÜN ELEMAN YA DA KISIMLARININ TANIMLANMASI == 4.011. satır:
4.019. satır: − == 2.3. KRİTİKLİK ANALİZİ ==+ + 4.017. satır:
4.026. satır: + − == 2.4. BAKIM GÖREV GEREKSİNİMLERİNİN TANIMLANMASI == − + + − == 1. GENEL == − == 2. ÜRÜN KULLANIM DESTEĞİ ==+ + + − == 2.1. KULLANIMA HAZIRLIK == − == 2.2. YÜKLEME VE İNDİRME ==+ + − == 3. PAKETLEME, ELLEÇLEME, DEPOLAMA VE ULAŞTIRMA (PEDU) ==+ + − == 3.1. PAKETLEME ==+ + 4.050. satır:
4.063. satır: + − == 3.2. ELLEÇLEME == 4.060. satır:
4.073. satır: − == 3.3. DEPOLAMA ==+ + 4.071. satır:
4.085. satır: + − == 3.4. İSTİFLEME == − == 3.5. TAŞIMA ==+ + 4.085. satır:
4.100. satır: + − == 3.6. BAĞLAMA == − == 4. ENVANTERDEN ÇIKARMA VE GERİ DÖNÜŞÜM ==+ + − == 5. LOJİSTİK İLİŞKİLİ OPERASYONLAR İÇİN KONTROL LİSTESİ ==+ + − + + − == 1. GENEL == − == 2. ANALİZ YÖNTEMLERİ ==+ + 4.123. satır:
4.141. satır: − == 3. ÖNLEYİCİ BAKIM GÖREV GEREKSİNİMLERİ İÇİN EŞİKLER, ARALIKLAR VE TETİKLEYİCİ OLAYLAR ==+ + 4.144. satır:
4.163. satır: − + − == 4. TANIMLANACAK ÖNLEYİCİ BAKIM GÖREV GEREKSİNİMLERİNİN (PMTR) BELİRLENMESİ İÇİN KULLANILABİLECEK KAYNAKLAR == − 4.157. satır:
4.174. satır: − == 5. KULLANICI BAKIM PROGRAMININ GELİŞTİRİLMESİ ==+ + 4.190. satır:
4.208. satır: + − == 6. GÜVENİLİRLİK MERKEZLİ BAKIM (GMB) ANALİZİ YAKLAŞIMI == 4.234. satır:
4.252. satır: − + + − == 1. GENEL == 4.245. satır:
4.263. satır: − == 2. ANALİZ SÜRECİ ==+ + 4.376. satır:
4.395. satır: − == 2.1. OSA VERİLERİ ==+ + − == 2.2. BAKIM SEVİYELERİNİN BELİRLENMESİ ==+ + 4.436. satır:
4.457. satır: + − == 2.3. BAKIM ÇÖZÜM ÖNERİSİNİN OLUŞTURULMASI == 4.496. satır:
4.517. satır: − + + − == 1. GENEL == 4.513. satır:
4.534. satır: − == 2. ANALİZLER ==+ + + − == 2.1. BAKIM GÖREVLERİNİN BELİRLENMESİ == 4.549. satır:
4.571. satır: − == 2.2. BAKIM GÖREV YAPILARININ OLUŞTURULMASI ==+ + 4.652. satır:
4.675. satır: − == 2.3. GÖREV KAYNAKLARININ BELİRLENMESİ ==+ + 4.834. satır:
4.858. satır: − + + − == 1. GENEL == 4.863. satır:
4.887. satır: + − == 2. FARKLI PROJE SAFHALARINDA YDA == 4.902. satır:
4.926. satır: − == 3. YAZILIM KIRILIM KONSEPTİ ==+ + 4.917. satır:
4.942. satır: − == 4. YAZILIM DESTEK ANALİZİ ==+ + − == 4.1. YDA ADAY KALEM SEÇİMİ ==+ + − == 4.2. YAZILIM BAKIMI ==+ + 4.936. satır:
4.964. satır: − == 4.3. YDA KAPSAMINDA HTEKA/HTEA ==+ + 4.943. satır:
4.972. satır: − == 4.4. YAZILIM İÇİN PLANLI BAKIM ANALİZİ (PBA) ==+ + − == 4.5. YAZILIM İÇİN OSA ==+ + − == 4.6. YAZILIM İÇİN BGA ==+ + − == 5. YAZILIM DESTEK KONSEPTİ ÇERÇEVESİ ==+ + 4.969. satır:
5.002. satır: − == 5.1. YAZILIM DESTEK PROFİLİ ==+ + 4.989. satır:
5.023. satır: − == 5.2. DESTEK FONKSİYONLARI ==+ + 4.995. satır:
5.030. satır: + − === 5.2.1. OPERASYONEL SERVİS DESTEĞİ === 5.003. satır:
5.038. satır: − === 5.2.2. YÖNETİM DESTEĞİ ===+ + − === 5.2.3. YAZILIM MODİFİKASYON DESTEĞİ ===+ + − == 6. DESTEK SINIFLARI == − == 6.1. SÜREÇLER ==+ + + + − == 6.2. ÜRÜN ==+ + − == 6.3. ÇEVRE ==+ + − == 7. DESTEKLENEBİLİRLİK FAKTÖRLERİ ==+ + − == 7.1. UYUMLULUK MATRİSİ ==+ + 5.042. satır:
5.085. satır: + − == 7.2. DOKÜMANTASYON == − == 7.3. YAZILIM YÜKLEME VE KALDIRMA ==+ + − == 7.4. DONANIMLAR ÜZERİNDE TAŞINMA ==+ + − == 7.5. GENİŞLEME KAPASİTESİ ==+ + − == 7.6. MODÜLER YAZILIM TASARIMI ==+ + − == 7.7. MODİFİKASYON FREKANSI (DEĞİŞİKLİK TRAFİĞİ) ==+ + − == 7.8. GERİYE DÖNDÜRME ==+ + − == 7.9. EMNİYET ENTEGRASYONU ==+ + − == 7.10. GÜVENLİK ==+ + 5.076. satır:
5.127. satır: − == 7.11. BOYUT ==+ + − == 7.12. YETKİNLİKLER ==+ + − == 7.13. YAZILIM DAĞITIMI ==+ + − == 7.14. TEKNOLOJİ ==+ + − + − + 5.097. satır:
5.152. satır: − + − + 5.117. satır:
5.172. satır: − + − + 5.130. satır:
5.185. satır: − + − + − + 5.144. satır:
5.199. satır: − + − + − + − + − + − +
Lojistik Destek Analizleri ve Kayıtları Rehberi (kaynağı gör)
10.07, 27 Temmuz 2021 tarihindeki hâli
, 10.07, 27 Temmuz 2021→EK-A İNSAN FAKTÖRÜ ANALİZLERİ VE LDA
= 12. EKLER =
= 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>'''
İ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.
İ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.
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.
Bu EK teknik ve LDA faaliyetleri gerçekleştiren personele yönelik olarak hazırlanmıştır. Bölümde insan faktörleri ve lojistik destek analiz süreci arasındaki ilişkiler ve entegrasyonu tanımlanmaktadır. İnsan faktörü analiz sonuçlarının projenin mümkün olan en erken safhalarında dokümante edilmesi tavsiye edilmektedir. LDA veri tabanı içerisinde insan faktörlerinin etkileri farklı yerlerde görünebilir. Uyarı ve ikazların yanı sıra, belirli bir görev yerine getirmek veya personeli olumsuz çevresel ortamda koruyabilmek için gerekli özel ekipman ihtiyaçları bu konuda örnek teşkil edebilir.
<big>'''2. LOJİSTİK DESTEK ANALİZLERİ VE İNSAN FAKTÖRLERİ'''</big>
'''<big>2.1. FİZİKSEL KABİLİYETLER VE KISITLAMALAR</big>'''
LDA ve insan faktörü entegrasyonu ürünün bütün ömür devri boyunca süreklilik arz eder. Üründe gerçekleştirilen modifikasyonlar veya önerilen tasarım değişiklikleri beraberinde bakım görevlerinde de değişiklik gerektirebilir.
LDA ve insan faktörü 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.
LDA ve insan faktörü analizlerinin ortak hedeflerinin yanı sıra kendilerine özel amaç ve hedefleri de vardır. İnsan faktörleri antropometrik hususlar, ergonomik hususlar ve diğer fizyolojik hususlara ilişkin değişik standartlara odaklanabilir. LDA da bu standartları dikkate almalı ve potansiyel destek çözümlerini değerlendirmelidir. Bu konuya verilebilecek örneklerden biri, ortalama insan önkolunun çapıdır. Bilek hareketinin ötesinde erişim gerektiren bir panelin tasarımında uygun standartlarda verilen minimum ölçü dikkate alınmalıdır. Bu durumda, insan faktörü bütün erişim panelleri için söz konusu ölçü gereksiniminin dikkate alınmasını sağlamak üzere tasarıma etki eder. Buna ilave olarak LDA, kısıtlı hareket imkânları olan bir ortamda gerçekleştirilecek bir görevin tamamlanabilmesi için gerekli destek ekipmanlarını tanımlar. Eğer, analiz faaliyetleri esnasında alternatif tasarım çözümleri belirlenirse, bunlar tasarım sürecinde dikkate alınmak üzere tasarım ekiplerine bildirilir.
'''<big>2.2. TEHLİKELİ DURUMLARDAN KAYNAKLANAN KISITLAMALAR</big>'''
İnsan faktörlerinin dikkate alınması gereken bir başka nokta insan sağlığına karşı tehditlerden dolayı bazı aktivitelerin kısıtlanmasıdır.
İ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.
Ç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.
Çok sıcak veya soğuk, nemli, yeraltı veya sualtı, çok gürültülü vb. aşırı çevresel koşullar altında gerçekleştirilen faaliyetlere ilişkin kısıtlamalar da dikkate alınması gereken hususlardandır. İnsanların bu çevresel koşulların etkisine karşı korunmaları da fiziksel kısıtlamalar gibi LDA süreci içerisinde ele alınmalıdır.
<big>'''3. İNSAN FAKTÖRÜ ANALİZLERİ'''</big>
'''<big>3.1. TASARIMA ETKİ</big>'''
İnsan faktörü tasarım kısıtı ve gereksinimlerini tanımlayan çeşitli standartlar vardır. Bu standartlar, yüklenici/müşteri mutabakatında uygun şekilde referans verilmeli ve sözleşmelere dahil edilmelidir.
İnsan faktö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.
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.
Ekip büyüklüğüne ilişkin personel gereksinimler, uygulanabilir olduğu durumlarda demografik özellikleri de dikkate almalıdır. Örneğin tamamen erkeklerden oluşan bir ekip için tanımlanacak yük kaldırma limiti, kadın erkek karma bir ekibin yük kaldırma limitinden daha yüksek olacaktır. Yani ekipmanın ağırlığı, kaldırılabilmesi için gerekli personel sayısını belirler ancak bu sayı farklı demografik özelliklere göre değişiklik gösterebilir. Ağırlık sınırlamaları, mekanik kaldırma gereksinimleri için de dikkate alınarak destek ekipmanı gereksinimlerini etkilemelidir.
<big>'''3.2. LDA İÇİN İLKELER'''</big>
LDA İş Tanımlama Toplantısı, LDA ve insan faktörü analizlerine uygulanacak kural ve ilkeleri belirlemelidir. Yüklenici ve müşteri arasında uygulanacak spesifik standart üzerinde mutabakata varmalı ve standarda yönelik istisnalar da tanımlanmalıdır.
LDA İş 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.
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.
Analiz süreci yinelemeli bir süreç olup, her tasarım değişikliğinde de tekrarlanmalıdır. LDA süreci içerisinde, detaylı BGA ürün tasarımın onaylanmasından sonra başlar. Her bakım görevi, ilgili insan faktörü standardı ile kıyaslanarak bütün bakım ve operasyon faaliyetlerinin insan faktörü limitleri içerisinde olduğu teyit edilir.
'''<big>4. DİKKATE ALINMASI GEREKEN İNSAN FAKTÖRLERİ</big>'''
Aşağıda sıralanan insan faktörleri, dikkate alınması gereken insan faktörleri açısından sınırlayıcı değildir; ancak ürün tasarımını etkileyecek ve özellikle LDA alanında destek ortamının tasarımında dikkate alınabilecek insan faktörlerine örnek olarak dikkate alınabilir.
Aşağıda sıralanan insan faktörleri, dikkate alınması gereken insan faktörleri açısından sınırlayıcı değildir; ancak ürün tasarımını etkileyecek ve özellikle LDA alanında destek ortamının tasarımında dikkate alınabilecek insan faktörlerine örnek olarak dikkate alınabilir.
<big>'''4.1. ANTROPOMETRİK HUSUSLAR'''</big>
* Görüş hattı (yatay ve dikey görme alanı)
* Görüş hattı (yatay ve dikey görme alanı)
* Ses sinyali gereksinimleri
* Ses sinyali gereksinimleri
* Kaldırılabilecek ünitelerin azami ağırlığı
* Kaldırılabilecek ünitelerin azami ağırlığı
* Destek ekipmanlarının azami ağırlığı
* Destek ekipmanlarının azami ağırlığı
'''<big>4.2. ERGONOMİK HUSUSLAR</big>'''
* Kumandaların tasarımı (ör. Anahtarlar, çevirme kolları, kumanda kolları, el çarkları, pedallar, düğmeler, vs.)
* Kumandaların tasarımı (ör. Anahtarlar, çevirme kolları, kumanda kolları, el çarkları, pedallar, düğmeler, vs.)
* Minimum tutacak ölçüleri
* Minimum tutacak ölçüleri
* Kapı ve erişim paneli ölçüleri
* Kapı ve erişim paneli ölçüleri
* Aydınlatma gereksinimleri
* Aydınlatma gereksinimleri
'''<big>4.3. ÇEVRESEL HUSUSLAR</big>'''
* Etkin sıcaklık
* Etkin sıcaklık
* Aşırı sıcak ve soğuk sıcaklık limitleri
* Aşırı sıcak ve soğuk sıcaklık limitleri
* Toz ve duman gibi kirliliğie maruz kalma
* Toz ve duman gibi kirliliğie maruz kalma
* Gürültü limitleri<br />
* Gürültü limitleri<br />
= 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>
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).
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).
Tasarım, geliştirme ve üretim faaliyetlerine yönelik çeşitli HTEA ve HTEKA türleri söz konusudur.
Tasarım, geliştirme ve üretim faaliyetlerine yönelik çeşitli HTEA ve HTEKA türleri söz konusudur.
'''<big>2. TASARIM VE GELİŞTİRME FAALİYETLERİNDE HTEKA</big>'''
HTEKA, geliştirme safhasında yapılması gereken analiz faaliyetidir. Diğer taraftan ihtiyaç olması halinde (tasarım değişikliği, modifikasyon vb) ilgili safhalarda güncellenebilecek bir analizdir.
HTEKA, geliştirme safhasında yapılması gereken analiz faaliyetidir. Diğer taraftan ihtiyaç olması halinde (tasarım değişikliği, modifikasyon vb) ilgili safhalarda güncellenebilecek bir analizdir.
HTEKA, 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.
HTEKA, tasarım faaliyetlerine yönelik bir güvenilirlik görevi olmasına rağmen başka amaçlarla da kullanılabilir. HTEKA veya ondan türetilmiş başka diğer analizler idame edilebilirlik, emniyet, kullanılabilirlik, LDA için ve bakım konseptinin detaylandırılması, hata tespit ve teşhisi için kullanılabilir. HTEKA’nın bu çok amaçlı kullanımı, aynı proje kapsamında gerçekleştirilen faaliyetlerin kopyalanmasının önlenmesi açısından planlama aşamasında dikkate alınmalıdır.
<big>'''3. LDA HTEA VE TASARIM YÖNELİMLİ HTEKA'''</big>
Tasarım yönelimli HTEKA’nın bir ürünün her bir komponentinin güvenilirliğini ve niceliğini belirlemesi gerekirken bu seviyede bir detay, bakım amaçları için her zaman gerekli değildir, Bakım faaliyetleri bütün komponentlere değil, daha yüksek seviyede bir kırılımda yer alan değiştirilebilir veya onarılabilir komponentlere odaklanmalıdır. Bu nedenle, LDA HTEA tasarım yönelimli HTEA ile genel olarak tutarlı olmakla birlikte birebir aynı değildir. Bu iki faaliyet arasında yeterli uyum, zamanlamanın uygunluğu ve izlenebilirliği sağlamak açısından sıkı ara yüzler tanımlanmalı ve koordinasyon gerçekleştirilmelidir.
Tasarım 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.
Tasarım HTEKA ve LDA HTEA arasındaki temel fark, tasarım açısından farklı olan bazı hata türleri, nihayetinde aynı bakım faaliyetine yol açıyorlarsa LDA HTEA açısından gruplanarak tek bir hata modu gibi ele alınabilir.
<big>'''4. LDA HTEA VE İDAME EDİLEBİLİRLİK, BAKIM VE EMNİYET ANALİZLERİ'''</big>
İdame edilebilirlik, bakım ve emniyet analizleri gibi diğer analizler LDA HTEA’dan veri kullanabilir veya tasarım HTEKA’dan türetilebilir (ör. OSA, GMB ve PBA gibi). Mevcut çalışmalardan azami fayda sağlamak ve tekrarlamaları önlemek için bu analizlerin de HTEKA ve LDA HTEA ile sıkı bir biçimde koordine edilmesi gerekir.
İ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>'''
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.
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.
|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.
|Sistemin ömrü boyunca meydana gelebilecek ve normal kullanım olarak düşünülmemiş olaydır. Dış sebeplerden (meteorolojik olaylar gibi) ya da kullanım dışı durumlardan (bir uçağın aşırı ivmelenmesi) kaynaklı olabilir.
|}
|}
<big>'''2. ANALİZ SÜRECİ'''</big>
<big>'''2.1. ÖZEL OLAYLARIN TANIMLANMASI'''</big>
1. Adım; özel olayların tanımlanması kapsamında, ilk olarak bir olay yaratabilecek farklı sebeplerin listelenmesi gerekir. Olaylar harici veya dahili sebeplerden kaynaklı olabilir ve doğal olaylardan ya da insan hatalarından etkilenebilir. Tablo 12’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.
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.
4. Adım; özel olayların meydana gelme olasılıklarına bağlı olarak, bu olayların bakım gerektiren ya da hiçbir analiz gerektirmeyen şeklinde gruplandırılmaları gerekmektedir.
'''<big>2.1. POTANSİYEL ARIZALARIN TANIMLANMASI</big>'''
Sistem tasarımında kullanılan teknolojinin değerlendirilmesi iki bakış açısı ile yapılabilir;
Sistem tasarımında kullanılan teknolojinin değerlendirilmesi iki bakış açısı ile yapılabilir;
|4
|4
|}
|}
'''<big>2.2. ÜRÜNÜN ELEMAN YA DA KISIMLARININ TANIMLANMASI</big>'''
1. Adım; seçilen her bir özel olay için ürün ağacı üzerinden etkilenen kalemler tanımlanmalıdır.
1. Adım; seçilen her bir özel olay için ürün ağacı üzerinden etkilenen kalemler tanımlanmalıdır.
3. Adım; bir önceki adımlarda tanımlanan ürün ağacı kalemleri için farklı tehditlere maruz kalmaları durumunda tasarımlarının analiz edilip gerekirse sonuçlar tasarım girdisi olarak tanımlanmalıdır.
3. Adım; bir önceki adımlarda tanımlanan ürün ağacı kalemleri için farklı tehditlere maruz kalmaları durumunda tasarımlarının analiz edilip gerekirse sonuçlar tasarım girdisi olarak tanımlanmalıdır.
<big>'''2.3. KRİTİKLİK ANALİZİ'''</big>
Her bir potansiyel hasarlanabilir kalem için, sistemin hizmet ömrüne olan etkisini ifade edecek şekilde kritikliklerinin değerlendirilmesi gerekmektedir. Bunun için aşağıdaki sorulara verilen cevapların herhangi biri ‘evet’ ise kritik olduğu değerlendirilebilecektir.
Her bir potansiyel hasarlanabilir kalem için, sistemin hizmet ömrüne olan etkisini ifade edecek şekilde kritikliklerinin değerlendirilmesi gerekmektedir. Bunun için aşağıdaki sorulara verilen cevapların herhangi biri ‘evet’ ise kritik olduğu değerlendirilebilecektir.
* Hasar kullanılabilirliğin tehdit edilmesi ile mi sonuçlanıyor?
* Hasar kullanılabilirliğin tehdit edilmesi ile mi sonuçlanıyor?
* Hasar önemli mülkiyet kaybı ile mi sonuçlanıyor?
* Hasar önemli mülkiyet kaybı ile mi sonuçlanıyor?
'''<big>2.4. BAKIM GÖREV GEREKSİNİMLERİNİN TANIMLANMASI</big>'''
Tanımlanmış özel olaylar ve hasarlar karşısında gerçekleştirilmesi gereken bakım görevlerinin tanımlanması gerekmektedir.
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.
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>
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.
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.
Lojistik ilişkili operasyonların tanımlanması (personel, destek ekipmanı, sarf malzemeler, yedek parçalar, eğitim vb. gereksinimlerle ilişkili) lojistik analiz faaliyetleri için önemli girdiler oluşturacaktır. Sistemin kullanım konsepti bilgileri ile birlikte, lojistik ilişkili operasyonların bazıları sistem ömür döngüsünün konsept safhasında göz önünde bulundurulurken, bazıları daha sonraki safhalarda (örneğin prototiplerin üretilmesiyle ya da BGA analizinin yapılmasıyla birlikte) ele alınabilir. Diğer taraftan, lojistik ilişkili operasyonlar analizi ihtiyaç olması halinde (tasarım değişikliği, modifikasyon vb) ilgili safhalarda güncellenebilecek bir analizdir.
'''<big>2. ÜRÜN KULLANIM DESTEĞİ</big>'''
'''<big>2.1. KULLANIMA HAZIRLIK</big>'''
Sistemi operasyona hazırlamak için sistemi kullanıma hazırlama kapsamında yapılması gereken bakım faaliyetleri dışında kalan diğer gerekli faaliyetlerin tanımlanması gerekmektedir. Sistemin doğru kullanım için yanal sistemlerin ve/veya parçaların hazırlanması buna örnek olarak verilebilir. Tipik kullanıma hazırlama görevleri servis görevleri olarak sınıflandırılabilir (bir uçağa özel bir ekipman ekleyerek keşif görevine hazırlamak gibi).
Sistemi operasyona hazırlamak için sistemi kullanıma hazırlama kapsamında yapılması gereken bakım faaliyetleri dışında kalan diğer gerekli faaliyetlerin tanımlanması gerekmektedir. Sistemin doğru kullanım için yanal sistemlerin ve/veya parçaların hazırlanması buna örnek olarak verilebilir. Tipik kullanıma hazırlama görevleri servis görevleri olarak sınıflandırılabilir (bir uçağa özel bir ekipman ekleyerek keşif görevine hazırlamak gibi).
<big>'''2.2. YÜKLEME VE İNDİRME'''</big>
Kargo olarak taşıması olan her bir ürün için yükleme ve indirme prosedürleri projenin erken safhalarında analiz edilmelidir. Örnek olarak, ne tarz bir kargo taşımasının planlandığı, hangi boyut ve ağırlık parametrelerinin göz önünde bulundurulduğu, kargonun özel etkilere (ivme, manyetik alan, nem vb.) hassasiyeti olup olmadığı, yanlış kullanım sonucu kargonun kritik ve tehlikeli durumlara sebebiyet verip vermeyeceği, ne tarz bir kargo güvenliği gerektiği verilebilir. Ayrıca yükleme/indirme ve kargo güvenliği için özel bir ekipman gerekip gerekmediği, topraklama ihtiyacının olup olmadığı da değerlendirilmelidir.
Kargo olarak taşıması olan her bir ürün için yükleme ve indirme prosedürleri projenin erken safhalarında analiz edilmelidir. Örnek olarak, ne tarz bir kargo taşımasının planlandığı, hangi boyut ve ağırlık parametrelerinin göz önünde bulundurulduğu, kargonun özel etkilere (ivme, manyetik alan, nem vb.) hassasiyeti olup olmadığı, yanlış kullanım sonucu kargonun kritik ve tehlikeli durumlara sebebiyet verip vermeyeceği, ne tarz bir kargo güvenliği gerektiği verilebilir. Ayrıca yükleme/indirme ve kargo güvenliği için özel bir ekipman gerekip gerekmediği, topraklama ihtiyacının olup olmadığı da değerlendirilmelidir.
'''<big>3. PAKETLEME, ELLEÇLEME, DEPOLAMA VE ULAŞTIRMA (PEDU)</big>'''
Tipik PEDU görevleri, paketleme, koruma, güvenlik önlemleri, depolama, taşıma, ulaştırma, çekme, istifleme, kaldırma olarak tanımlanabilir.
Tipik PEDU görevleri, paketleme, koruma, güvenlik önlemleri, depolama, taşıma, ulaştırma, çekme, istifleme, kaldırma olarak tanımlanabilir.
'''<big>3.1. PAKETLEME</big>'''
Paketleme ve paketten çıkarma için asgari düzeyde aşağıdakiler değerlendirilmelidir:
Paketleme ve paketten çıkarma için asgari düzeyde aşağıdakiler değerlendirilmelidir:
* 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?
* 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ı?
* Paketlemeyi açmak için destek ekipmanı ve tesisi ilgilendiren bir durum var mı?
'''<big>3.2. ELLEÇLEME</big>'''
Elleçleme için asgari düzeyde aşağıdakiler değerlendirilmelidir:
Elleçleme için asgari düzeyde aşağıdakiler değerlendirilmelidir:
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.
Taşıma, yükleme, onarım, bakım vb. için sistemin kaldırma konsepti belirlenmelidir. Ürünün hem kendisinin hem de komponentlerinin kaldırılması söz konusuysa onlar da düşünülmelidir.
'''<big>3.3. DEPOLAMA</big>'''
Ürünün fonksiyonelliğini depolama esnasında ve depolama sonrasında da garanti etmek için depolama prosedürleri analiz edilmeli ve dokümante edilmelidir. Depolama için asgari düzeyde aşağıdakiler değerlendirilmelidir:
Ürünün fonksiyonelliğini depolama esnasında ve depolama sonrasında da garanti etmek için depolama prosedürleri analiz edilmeli ve dokümante edilmelidir. Depolama için asgari düzeyde aşağıdakiler değerlendirilmelidir:
* Depolama periyodu için ne tarz güvenlik önlemleri gerekiyor? (ör. Hareketli parçaları bloklamak, ışığa karşı koruma sağlamak vb.)
* 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ı?
* Depolama zamanı ürünün ömründen sayılacak mı?
<big>'''3.4. İSTİFLEME'''</big>
Depolama ve taşımanın bir parçası olan istifleme kapsamında gerekli güvenlik gereksinimleri tanımlanmalıdır. Depolamada itme vb. durumların gerçekleşme ihtimali varsa bu durumda sistem davraşının ne olacağı değerlendirilmelidir.
Depolama ve taşımanın bir parçası olan istifleme kapsamında gerekli güvenlik gereksinimleri tanımlanmalıdır. Depolamada itme vb. durumların gerçekleşme ihtimali varsa bu durumda sistem davraşının ne olacağı değerlendirilmelidir.
'''<big>3.5. TAŞIMA</big>'''
Taşıma için asgari düzeyde aşağıdakiler değerlendirilmelidir:
Taşıma için asgari düzeyde aşağıdakiler değerlendirilmelidir:
* Taşıma sandığı konsepti olacak mı?
* Taşıma sandığı konsepti olacak mı?
* Taşımada kızak ve palet kullanımı olacak mı?
* Taşımada kızak ve palet kullanımı olacak mı?
'''<big>3.6. BAĞLAMA</big>'''
Bağlama kısa ya da uzun vadeli olarak, ürünü bir yere sabitlemek veya bir taşıma aracının içinde sistemin güvenli olarak bulunmasını sağlamaktır. Özel teknikler (ör. Denge ağırlığı, bağlama noktaları, bağlama esnasında gerekecek ekipman vb.) de değerlendirilmelidir.
Bağlama kısa ya da uzun vadeli olarak, ürünü bir yere sabitlemek veya bir taşıma aracının içinde sistemin güvenli olarak bulunmasını sağlamaktır. Özel teknikler (ör. Denge ağırlığı, bağlama noktaları, bağlama esnasında gerekecek ekipman vb.) de değerlendirilmelidir.
'''<big>4. ENVANTERDEN ÇIKARMA VE GERİ DÖNÜŞÜM</big>'''
Sistemin (mühimmat, silah sistemi, destek ekipmanı vb.) envanterden çıkarma prosedürlerinin tanımlanmış olması gerekmektedir. Ayrıca tek kullanımlık sistemlere ait taşıma saklama kutuları için uygulanabilir olması için geri dönüşüm metotları da tanımlanmalıdır.
Sistemin (mühimmat, silah sistemi, destek ekipmanı vb.) envanterden çıkarma prosedürlerinin tanımlanmış olması gerekmektedir. Ayrıca tek kullanımlık sistemlere ait taşıma saklama kutuları için uygulanabilir olması için geri dönüşüm metotları da tanımlanmalıdır.
'''<big>5. LOJİSTİK İLİŞKİLİ OPERASYONLAR İÇİN KONTROL LİSTESİ</big>'''
Tüm faaliyetler (ayarlama, sızdırma, kalibrasyon, kontrol, temizleme, koruma, taşıma sandığı konsepti, tuzdan arındırma, envanterden çıkarma, kaldırma, yükseltme, kargoya yükleme, paketleme, geri dönüşüm, ikmal, güvenlik önlemleri, istifleme, depolama, taşıma, kargodan indirme, paketlemeyi açma, vinçle kaldırma vb.) ve bu faaliyetlerin sistemin hangi ömür evresinde gerçekleştirileceği/uygulanacağı belirlenmeli ve özel bir destek ekipmanı gerekliliği ile bu faaliyetlerin tasarım üzerinde bir etkisi olup olmadığı kontrol edilmelidir.
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>'''
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.
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.
Önleyici Bakım Görev Gereksinimleri ile ilişkili sistem ya da ekipman/kalemler otomatik olarak LDA adayı kalem olacaktır. LDA adaylarına atanmış tüm Planlı Bakım Görev Gereksinimleri daha sonra BGA’ya (bkz.EK-G BAKIM GÖREV ANALİZİ) tabi tutulacaktır. Planlı bakım programı geliştirme faaliyeti geliştirme safhasından başlar. Diğer taraftan ihtiyaç olması halinde (tasarım değişikliği, modifikasyon vb) ilgili safhalarda güncellenebilecek bir analizdir.
'''<big>2. ANALİZ YÖNTEMLERİ</big>'''
Önleyici Bakım Görev Gereksinimlerinin belirlenmesi kapsamında üç farklı analiz metodu tanımlanmıştır. (Analizler hakkında detaylı bilgi için; bkz. ‘S4000P International specification for developing and continuously improving preventive maintenance’.)
Ö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’.)
Yüksek yoğunluklu radyasyon alanları analizi
Yüksek yoğunluklu radyasyon alanları analizi
'''<big>3. ÖNLEYİCİ BAKIM GÖREV GEREKSİNİMLERİ İÇİN EŞİKLER, ARALIKLAR VE TETİKLEYİCİ OLAYLAR</big>'''
Tek bir Önleyici Bakım Görev Gereksinimi için, planlı eşiklerin, aralıkların ya da tetikleyici olayların farklı tipleri seçilebilir;
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;
* 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.
* 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.
* Fonksiyonel hata etkisi emniyet ile ilgili olan durumlarda aralık uzatılmamalıdır.
'''<big>4. TANIMLANACAK ÖNLEYİCİ BAKIM GÖREV GEREKSİNİMLERİNİN (PMTR) BELİRLENMESİ İÇİN KULLANILABİLECEK KAYNAKLAR</big>'''
* Yasal düzenlemelerden gelen gereksinimler
* Yasal düzenlemelerden gelen gereksinimler
* Emniyet Analizi/hata ağacı analizinden gelen gereksinimler
* Emniyet Analizi/hata ağacı analizinden gelen gereksinimler
İ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.
İlerleyen analiz aşamalarında ortaya çıkan potansiyel bakım problemlerinin tespit edilebilmesi açısından, görev uygulanabilirliği ve etkinliği ile ilgili yapılmış olan varsayımları doğrulayabilmek için geri bildirimlerin sağlanması önemlidir.
'''<big>5. KULLANICI BAKIM PROGRAMININ GELİŞTİRİLMESİ</big>'''
Bir önleyici bakım görev gereksiniminin tip ve değer olarak bir tane ya da tip ve değerin kombinasyonlarından oluşan iki ya da daha fazla aralığı vardır. Eğer birden fazla aralık tanımlanmışsa, kullanım senaryosuna bağlı olarak ilk gelen aralık ile bakım başlatılır.
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.
* Sistemin kullanım veya görevine anlık kısa bir ara verilmesinden sonra
* 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
* Ürünün kullanım veya görevini tamamlanmasından sonra
'''<big>6. GÜVENİLİRLİK MERKEZLİ BAKIM (GMB) ANALİZİ YAKLAŞIMI</big>'''
GMB sistemin doğal güvenilirliğini kaynakların minimum israfı ile sürdürebilmesi için gerekli olan planlı bakım görevlerinin tanımlandığı analiz yöntemidir.
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.
= EK-F ONARIM SEVİYESİ ANALİZİ (OSA) =
== EK-F ONARIM SEVİYESİ ANALİZİ (OSA) ==
'''<big>1. GENEL</big>'''
OSA maliyet, güvenilirlik değerleri, bakım yapılabilirlik/test edilebilirlik kısıtlamaları ya da hazır bulunurluk gibi amaçların da gözetildiği; onarma, yenisi ile değiştirme gibi kararların alındığı ve ilgili görevler için bakım seviyelerinin belirlendiği analiz çalışmasıdır. Analiz sonuçları bakım görevlerini ve bu görevlerle ilişkili ekipman, personel, yedek parça gibi kaynakları doğrudan etkiler. OSA’nın amacı optimum bakım çözümüne karar vermektir.
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.
OSA BGA’yı tamamlayıcı niteliktedir. Saha inceleme rapolarının, mühendislik verilerininin ve proje gereksinimlerinin girdi olarak kullanıldığı OSA, tasarımın netlik kazanması ile geliştirme safhasında bakım görev analizine paralel bir şekilde yürütülür. Diğer taraftan ihtiyaç olması halinde (tasarım değişikliği, modifikasyon vb) ilgili safhalarda güncellenebilecek bir analizdir.
OSA BGA’yı tamamlayıcı niteliktedir. Saha inceleme rapolarının, mühendislik verilerininin ve proje gereksinimlerinin girdi olarak kullanıldığı OSA, tasarımın netlik kazanması ile geliştirme safhasında bakım görev analizine paralel bir şekilde yürütülür. Diğer taraftan ihtiyaç olması halinde (tasarım değişikliği, modifikasyon vb) ilgili safhalarda güncellenebilecek bir analizdir.
'''<big>2. ANALİZ SÜRECİ</big>'''
Sistemler için onarım seviyeleri genellikle ikiye veya üçe ayrılır:
Sistemler için onarım seviyeleri genellikle ikiye veya üçe ayrılır:
Bu örnek kapsamında, elektronik komplenin yenisi ile değiştirilmesi durumunda arızalı elektronik komplenin onarılması ya da elden çıkarılması ve bu faaliyetlerin hangi seviyede yapılacağı ile ilgili karar OSA kapsamında verilecektir. Bu karar verilirken de hem onarım maliyeti (işçilik, eğitim vs.) hem de asıl malzeme maliyeti ile elektronik komplenin güvenilirlik değeri göz önünde bulundurulmalıdır.
Bu örnek kapsamında, elektronik komplenin yenisi ile değiştirilmesi durumunda arızalı elektronik komplenin onarılması ya da elden çıkarılması ve bu faaliyetlerin hangi seviyede yapılacağı ile ilgili karar OSA kapsamında verilecektir. Bu karar verilirken de hem onarım maliyeti (işçilik, eğitim vs.) hem de asıl malzeme maliyeti ile elektronik komplenin güvenilirlik değeri göz önünde bulundurulmalıdır.
'''<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.
OSA kapsamında yapılan değerlendirmelerde kullanılan veriler bakım ilişkili verilerdir. Bunların bir kısmı yedek parça, tesis, destek ekipmanı, personel ve yetenek seviyesi, eğitim ihtiyacı gibi maliyet ilişkili verilerdir. Bir kısmı ise, güvenilirlik bilgisi (MTBF gibi), planlı bakım aralıkları, sistem hazır bulunurluğu, stoktaki yedek parçaların hazır bulunurluğu, bakım için gerekli personelin hazır bulunurluğu gibi doğrudan maliyetle ilişkili olmayan verilerdir.
Toplam maliyet hesaplamaları yapılırken, gerekli kaynakların sadece başlangıçta gereken veya tekrar eden maliyet olarak değerlendirilmesi gerekmektedir. Örneğin, işçilik süresi ya da alt yapı bakımı tekrar eden bir maliyetken, destek ekipmanı tedariki ya da alt yapı kurulumu için sadece başlangıç maliyeti söz konusudur.
Toplam maliyet hesaplamaları yapılırken, gerekli kaynakların sadece başlangıçta gereken veya tekrar eden maliyet olarak değerlendirilmesi gerekmektedir. Örneğin, işçilik süresi ya da alt yapı bakımı tekrar eden bir maliyetken, destek ekipmanı tedariki ya da alt yapı kurulumu için sadece başlangıç maliyeti söz konusudur.
'''<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.
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.
· Yazılım modifikasyonları
· Yazılım modifikasyonları
|}
|}
'''<big>2.3. BAKIM ÇÖZÜM ÖNERİSİNİN OLUŞTURULMASI</big>'''
Hem maliyet hem de teknik kriterlerin birlikte değerlendirilmesi kritiktir. BGA kapsamında belirlenen görevler üzerinden değerlendirme hem teknik hem mali olarak yapılır ve onarım kararı ya da envanterden çıkarma kararı verilir. Her bir görev kapsamında bu kararlar verildikten sonra, bu görevlerin hangi seviyelerde yapılacağı belirlenir. Ayrıca, tanımlanan benzer bakım faaliyetlerinin mümkün olduğunca tek bir bakım yeri için tanımlanmış olması da (onarım yapılacak kalemin bir kısmının bir bakım merkezinde bir kısmının başka bir bakım merkezinde yapılmaması gibi) önemlidir. Yapılan tüm analiz çalışması sonunda sistemin bakım çözüm önerisi oluşturulmuş olacaktır.
Hem maliyet hem de teknik kriterlerin birlikte değerlendirilmesi kritiktir. BGA kapsamında belirlenen görevler üzerinden değerlendirme hem teknik hem mali olarak yapılır ve onarım kararı ya da envanterden çıkarma kararı verilir. Her bir görev kapsamında bu kararlar verildikten sonra, bu görevlerin hangi seviyelerde yapılacağı belirlenir. Ayrıca, tanımlanan benzer bakım faaliyetlerinin mümkün olduğunca tek bir bakım yeri için tanımlanmış olması da (onarım yapılacak kalemin bir kısmının bir bakım merkezinde bir kısmının başka bir bakım merkezinde yapılmaması gibi) önemlidir. Yapılan tüm analiz çalışması sonunda sistemin bakım çözüm önerisi oluşturulmuş olacaktır.
|}
|}
= EK-G BAKIM GÖREV ANALİZİ (BGA) =
== EK-G BAKIM GÖREV ANALİZİ (BGA) ==
'''<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.
Bakım faaliyetleri, sistem konfigürasyonunda bulunan ve görev için kritik olan bütün ekipmanlar için gereksinimlere uygun olarak, görev faaliyetlerini kesintiye uğratmayacak, sorunsuz ve kazasız bir şekilde tamamlanmasına yönelik tedbirlerin alınması ve gerektiğinde müdahale edilmesi esasına dayanır. Bu amaca yönelik her türlü kaynak ihtiyacı (iş gücü, malzeme, tesis vb.) önceden hesaplanmalı ve tahsis edilmelidir.
BGA, geliştirme safhasında yapılması gereken bir analiz faaliyetidir. Diğer taraftan ihtiyaç olması halinde (tasarım değişikliği, modifikasyon vb) ilgili safhalarda güncellenebilecek bir analizdir.
BGA, geliştirme safhasında yapılması gereken bir analiz faaliyetidir. Diğer taraftan ihtiyaç olması halinde (tasarım değişikliği, modifikasyon vb) ilgili safhalarda güncellenebilecek bir analizdir.
'''<big>2. ANALİZLER</big>'''
'''<big>2.1. BAKIM GÖREVLERİNİN BELİRLENMESİ</big>'''
Bakım görevleri belirlenirken ürün kırılımının yapılmış ve LDA adayı kalemlerin listelenmiş olması gerekmektedir. LDA adayı olarak seçilen her bir kalem için bakım görevleri belirlenmelidir.
Bakım görevleri belirlenirken ürün kırılımının yapılmış ve LDA adayı kalemlerin listelenmiş olması gerekmektedir. LDA adayı olarak seçilen her bir kalem için bakım görevleri belirlenmelidir.
Özel olay sonrası gerekli olan muayeneler ve/veya GMB sonrasında; genel, kullanıcı talebine bağlı ve/veya hazırlık için yapılacak faaliyetlerden kaynaklı bakım görevleri ortaya çıkabilir. Bu faaliyetlerin de BGA kapsamında değerlendirilmesi gerekmektedir.
Özel olay sonrası gerekli olan muayeneler ve/veya GMB sonrasında; genel, kullanıcı talebine bağlı ve/veya hazırlık için yapılacak faaliyetlerden kaynaklı bakım görevleri ortaya çıkabilir. Bu faaliyetlerin de BGA kapsamında değerlendirilmesi gerekmektedir.
'''<big>2.2. BAKIM GÖREV YAPILARININ OLUŞTURULMASI</big>'''
Görev yapıları oluşturulurken görevler analiz faaliyetinde kolaylık sağlaması açısından iki sınıfa ayrılır.
Görev yapıları oluşturulurken görevler analiz faaliyetinde kolaylık sağlaması açısından iki sınıfa ayrılır.
Bazı tasarımsal sebeplerden kaynaklı sistem hataları öngörülemeyebilir. Hasar ya da özel olayların meydana gelmesi ile ilgili benzer sistemler ve/veya benzer projeler kapsamında edinilmiş herhangi bir tecrübe varsa, bu tecrübe öngörülemeyen olayların ne kadar sıklıkla meydana gelebileceği ve ilgili bakım faaliyetlerinin sıklığı konusunda fikir verebilir. Bu nedenle, bakım faaliyetleri ile ilgili planlama yapılırken uygulanabilir olduğu ölçüde öngörülemeyen bu tarz olayların da dikkate alınması önemlidir.
Bazı tasarımsal sebeplerden kaynaklı sistem hataları öngörülemeyebilir. Hasar ya da özel olayların meydana gelmesi ile ilgili benzer sistemler ve/veya benzer projeler kapsamında edinilmiş herhangi bir tecrübe varsa, bu tecrübe öngörülemeyen olayların ne kadar sıklıkla meydana gelebileceği ve ilgili bakım faaliyetlerinin sıklığı konusunda fikir verebilir. Bu nedenle, bakım faaliyetleri ile ilgili planlama yapılırken uygulanabilir olduğu ölçüde öngörülemeyen bu tarz olayların da dikkate alınması önemlidir.
'''<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.
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.
= EK-H YAZILIM DESTEK ANALİZİ (YDA) =
== EK-H YAZILIM DESTEK ANALİZİ (YDA) ==
'''<big>1. GENEL</big>'''
Sistemin desteklenebilirliğini sağlayabilmek için LDA süreci kapsamında yazılımlar için de YDA süreci yürütülür. YDA, maliyet etkin bir yazılım destek konseptinin kurulması için donanıma benzer şekilde yazılım açısından da sistemi desteklemeyi amaçlar. Yazılım Destek Konsepti (YDK) belirlenirken, bir ürün içerisindeki yazılımın kullanımının devamlılığını sağlamak için gerekli tüm aktivitelerin dikkate alınması gerekir. YDA’da, yeterli bir YDK geliştirmek için ekipman, araç, personel, dokümantasyon, altyapı, gerekli yetkinlik ve eğitim gibi hususlar analiz edilir.
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.
* Kapsamı (yazılımdaki değişikliğin büyüklüğü, işlemlerin maliyeti, bakım süresi);
* 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.
* Kritikliği (performans, emniyet, bilgi güvenliği hususları) değerlendirilir.
'''<big>2. FARKLI PROJE SAFHALARINDA YDA</big>'''
YDA’nın yazılım içeren bir ürün için tüm ömür devri boyunca uygulanması gerekmektedir. Yapılacak faaliyetler, proje safhaları dikkate alınarak gerçekleştirilmelidir. Örneğin, geliştirme safhasında, YDA’nın uygulaması önemlidir çünkü yazılımın gelecekteki yükleme, servis ve modifikasyonları için desteklenebilirlik gereksinimleri açısından yazılım mimarisi ve tasarımı etkilenebilir.
YDA’nın yazılım içeren bir ürün için tüm ömür devri boyunca uygulanması gerekmektedir. Yapılacak faaliyetler, proje safhaları dikkate alınarak gerçekleştirilmelidir. Örneğin, geliştirme safhasında, YDA’nın uygulaması önemlidir çünkü yazılımın gelecekteki yükleme, servis ve modifikasyonları için desteklenebilirlik gereksinimleri açısından yazılım mimarisi ve tasarımı etkilenebilir.
Erken fazlarda, YDA temel yazılım destek gereksinimlerinin belirlenmesine yardımcı olur. Envanterden çıkarma safhasında, donanımlar için olduğu gibi yazılımlar için de envanterden çıkarma prosedürlerinin tanımlanması gerekmektedir. Eğer yazılım verisi yeni geliştirilecek sistemler veya ilerleyen operasyonlarda kullanılacaksa, verilerin yer değiştirilmesi hususu kapsamında uygulanması gereken prosedürlerin de göz önünde bulundurulması ve tanımlanması gerekmektedir.
Erken fazlarda, YDA temel yazılım destek gereksinimlerinin belirlenmesine yardımcı olur. Envanterden çıkarma safhasında, donanımlar için olduğu gibi yazılımlar için de envanterden çıkarma prosedürlerinin tanımlanması gerekmektedir. Eğer yazılım verisi yeni geliştirilecek sistemler veya ilerleyen operasyonlarda kullanılacaksa, verilerin yer değiştirilmesi hususu kapsamında uygulanması gereken prosedürlerin de göz önünde bulundurulması ve tanımlanması gerekmektedir.
'''<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.
Yazılımlar için de donanımlara benzer olarak fiziksel veya işlevsel konsept değerlendirilerek bir kırılım gerçekleştirilebilir. Yazılımın yüklendiği üst donanımlarından birisinin elemanı olması, yazılımın kendisini çalıştıran donanımın bir elemanı olması veya yazılımın fiziksel olarak üzerinde bulunduğu donanımın bir elemanı olması örnek olarak verilebilir.
Yazılım modifikasyonuna yönelik olarak işlevsel yazılım kırılımı yazılım tasarım gereksinimlerini takip eder. Klasik yazılım konfigürasyon kalem seviyesi yaklaşımına ek olarak daha üst seviyede (altsistem ve sistem seviyesi) yazılımın sisteme entegrasyonunun da değerlendirilmesi gerekmektedir.
Yazılım modifikasyonuna yönelik olarak işlevsel yazılım kırılımı yazılım tasarım gereksinimlerini takip eder. Klasik yazılım konfigürasyon kalem seviyesi yaklaşımına ek olarak daha üst seviyede (altsistem ve sistem seviyesi) yazılımın sisteme entegrasyonunun da değerlendirilmesi gerekmektedir.
'''<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.
Ürün kullanım safhasına girmeden gerekli destek altyapısının sağlandığından emin olmak önemlidir. YDA’nın amacı, yazılım desteklenebilirlik gereksinimlerini erken safhalarda belirlemek ve sistem operasyonu ve sonraki değişikliklerin desteklenebilirliği için yazılım tasarımını etkilemektir.
'''<big>4.1. YDA ADAY KALEM SEÇİMİ</big>'''
Donanım aday kalem seçimiyle benzer yaklaşım izlenecektir.
Donanım aday kalem seçimiyle benzer yaklaşım izlenecektir.
'''<big>4.2. YAZILIM BAKIMI</big>'''
Bakım faaliyeti gerektirecek tüm olaylar, yazılım desteğinin başlangıcı olarak değerlendirilebilir. Bu olaylar, operasyonel, teknik, yazılım geliştirme gereksinimleri ve yazılım hataları olarak gruplanabilir.
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.
Yazılım hataları donanım hataları gibi belirli onarım değişim prosedürleriyle ele alınamaz. Bu yüzden bir yazılım hatasında alınması gerekli olan aksiyon hemen bilinemeyeceğinden alınamayabilir. Örneğin bir yazılım hatasında sistemi kapatıp açmak hatayı düzeltebilirken, diğer bir hatada sistemi kapattıktan sonra sistemin daha fazla zarar görmemesi için tekrar açılmaması gerekebilecektir. Ya da bir donanımdaki bozulma sebebiyle de yazılım çalışmayabilir. Bu durumda yazılım kaynak kodunda gerçek bir doğal hata bulunmamakta olup bu durum dış hasar olarak ele alınır.
Yazılım hataları donanım hataları gibi belirli onarım değişim prosedürleriyle ele alınamaz. Bu yüzden bir yazılım hatasında alınması gerekli olan aksiyon hemen bilinemeyeceğinden alınamayabilir. Örneğin bir yazılım hatasında sistemi kapatıp açmak hatayı düzeltebilirken, diğer bir hatada sistemi kapattıktan sonra sistemin daha fazla zarar görmemesi için tekrar açılmaması gerekebilecektir. Ya da bir donanımdaki bozulma sebebiyle de yazılım çalışmayabilir. Bu durumda yazılım kaynak kodunda gerçek bir doğal hata bulunmamakta olup bu durum dış hasar olarak ele alınır.
'''<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.
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.
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).
Kullanım safhasındaki diğer bir konu ise yazılım mühendislerine spesifik bir hata hakkında bilgi vermek ve yazılım hatalarından kaynaklı gereksiz bakım görevlerini önlemektir. BIT ile tespit edilebilen veya kullanıcı tarafından tanımlanabilen bir yazılım hatası demontaj sayısını ve donanımla ilişkili olmayacak hataları azaltacaktır (ekipmanın değiştirilmesi ile yazılım hatasının ortadan kaldırılamaması gibi).
'''<big>4.4. YAZILIM İÇİN PLANLI BAKIM ANALİZİ (PBA)</big>'''
GMB gibi PBA’lar donanımlar gibi yazılımlara uygulanabilir değildir. Yazılım hataları, yazılım tasarımının istenmeyen etkilerinin sonucu olduğundan PBA kapsamında tanımlanmış bir bakım görevi ile düzeltilemezler. PBA sonuçları yazılım içeren bir donanımda, planlı bakım görevlerini belirleyecek şekilde kullanılabilir ancak bu analiz yine de donanım için olacaktır.
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.
Yazılımlar da küvet eğrisi davranışını izleyerek ilk kullanımda çokça hata yaparlar. Geliştirme safhası boyunca kararlı bir davranışa kadar kod hataları düzeltilerek tekrarlayan bir şekilde yazılım yayımlamaları yapılır. İlerleyen kullanımlarda hata oranları her ne kadar düşse de yazılımda ilk kapsamından farklı olarak modifikasyonlar olacağından hata oranları yine artacaktır.
'''<big>4.5. YAZILIM İÇİN OSA</big>'''
Yazılım için OSA donanımlarda olduğu gibi ya da oldukça benzer olacak şekilde ele alınmalıdır. OSA sonucunda ortaya çıkan görevler yeni yazılım yayını veya operasyonel bir yazılım ihtiyacının doğması veya veri yükleme gibi dışsal nedenlerden kaynaklanabilir. Eğer bu görevler çok sık gerçekleşirse OSA sonuçları donanımlara karşılık gelen görevlerden farklı olabilir.
Yazılım 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.
Yazılım değişikliği için ekipman hakkında detaylı bilgi (donanımla ilintili yazılım geliştirme ortamı ve yazılım geliştirme araçları) ve personel yetkinliği gereklidir. Ayrıca, sözleşmeye bağlı durumlar, yazılım modifikasyon faaliyetlerinin hangi destek seviyesinde gerçekleştirileceğini etkileyebilir.
'''<big>4.6. YAZILIM İÇİN BGA</big>'''
İlgili yazılım destek başlatıcılarının (olaylar) belirlenmesinden sonra operasyonel/bakım veya modifikasyon görevleri belirlenmelidir. Amaç bunları tanımlamak ve bunlara gerekli kaynakları ve görev karakteristiklerini belirlemektir (süre, insan ihtiyacı, ön koşullar, güvenlik koşulları vb.).
İ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.
SAE JA1005 referans alınarak farklı olaylar sonucunda hangi yazılım destek görevlerinin gerçekleştirileceğine ulaşılabilir.
'''<big>5. YAZILIM DESTEK KONSEPTİ ÇERÇEVESİ</big>'''
Yazılım destek konsepti yazılım tasarım sürecinin erken safhalarında başlamalıdır. Eğer değişiklik gereksinimleri farklı kaynaklardansa, yazılım değişikliği daha kolay olacaktır. Ayrıca, yükleme ve konfigürasyon prosedürleri de olabildiğince kolay olmalıdır.
Yazılım destek konsepti yazılım tasarım sürecinin erken safhalarında başlamalıdır. Eğer değişiklik gereksinimleri farklı kaynaklardansa, yazılım değişikliği daha kolay olacaktır. Ayrıca, yükleme ve konfigürasyon prosedürleri de olabildiğince kolay olmalıdır.
Yazılım desteğinin 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.
Yazılım desteğinin LDA kapsamında olup olmayacağı proje kapsamında yapılması planlanan faaliyetler ile birlikte değerlendirilmeli ve yapılması gerektiği değerlendirilirse LDAP’a eklenmelidir. Büyük miktarda yazılım içeren büyük ve karmaşık sistemlerde yazılım desteklenebilirliği ayrı bir alan olarak değerlendirilmelidir. Yazılımlar donanımlara fonksiyonellik katmak için tasarlandıklarından donanım ile arasındaki arayüzler kurulana kadar süreçler birlikte işletilmeli, gözden geçirilmeli, pratiğe dökülmeli ve dokümante edilmelidir.
'''<big>5.1. YAZILIM DESTEK PROFİLİ</big>'''
Yazılım destek profili kapsamında, yazılım desteğinin gerçekleştirileceği yer, organizasyon ve ilişkili personelin dikkate alınması gerekmektedir. Yazılım destek seviyeleri aşağıdaki gibi tanımlanabilir;
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;
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.
Farklı destek görevleri ve seviyeleri için farklı bölgelerde farklı kaynaklarla nasıl yapılacağını gösteren kullanım durumlarının tanımlanması gerekmektedir.
'''<big>5.2. DESTEK FONKSİYONLARI</big>'''
Yazılımla ilişkili bakım görevleri aşağıda belirtilen hususlara göre farklı kategorilere ayrılabilir;
Yazılımla ilişkili bakım görevleri aşağıda belirtilen hususlara göre farklı kategorilere ayrılabilir;
* Yazılım yüklemesi ya da kaldırılması için bir donanımı çıkarmak gerekli mi?
* Yazılım yüklemesi ya da kaldırılması için bir donanımı çıkarmak gerekli mi?
* Yazılım modifikasyonu gerekli mi? Yazılım modifikasyonunun özel destek görevleri gerektiren geniş bir alan olması sebebiyle modifikasyonun kapsamı tam olarak belirlenebiliyor mu?
* Yazılım modifikasyonu gerekli mi? Yazılım modifikasyonunun özel destek görevleri gerektiren geniş bir alan olması sebebiyle modifikasyonun kapsamı tam olarak belirlenebiliyor mu?
'''<big>5.2.1. OPERASYONEL SERVİS DESTEĞİ</big>'''
Operasyonel servis görevleri sistemin günlük operasyonel görevleriyle ilişkili tüm aktiviteleri tanımlar. Fakat bu görevler sistem kullanımı üzerinde farklı kalite ve derinlikte etkilere sebep olabilir (ör. sistem atıl zamanları, test gereksinimleri vb.). Bu görevler, destek seviyesi 1 ve 2’de kullanıcı tarafından yürütülen basit görevlerdir.
Operasyonel servis görevleri sistemin günlük operasyonel görevleriyle ilişkili tüm aktiviteleri tanımlar. Fakat bu görevler sistem kullanımı üzerinde farklı kalite ve derinlikte etkilere sebep olabilir (ör. sistem atıl zamanları, test gereksinimleri vb.). Bu görevler, destek seviyesi 1 ve 2’de kullanıcı tarafından yürütülen basit görevlerdir.
Gömülü yazılımların veya bellenimlerin yükleme görevleri BGA’da belirlenmelidir.
Gömülü yazılımların veya bellenimlerin yükleme görevleri BGA’da belirlenmelidir.
'''<big>5.2.2. YÖNETİM DESTEĞİ</big>'''
Operasyonel destek ile yazılım modifikasyon görevleri arasında bir yerdedir. Her seviyede kullanıcı tarafından gerçekleştirilebileceği gibi destek organizasyonları tarafından da gerçekleştirilebilir. Problem raporlaması, sistem konfigürasyon kontrolü, teslim ve yükleme ile kullanıcı desteği gibi görev tipleri mevcuttur.
Operasyonel destek ile yazılım modifikasyon görevleri arasında bir yerdedir. Her seviyede kullanıcı tarafından gerçekleştirilebileceği gibi destek organizasyonları tarafından da gerçekleştirilebilir. Problem raporlaması, sistem konfigürasyon kontrolü, teslim ve yükleme ile kullanıcı desteği gibi görev tipleri mevcuttur.
'''<big>5.2.3. YAZILIM MODİFİKASYON DESTEĞİ</big>'''
Yazılım modifikasyonu, düzeltici, adaptif veya tamamlayıcı sebeplerden ötürü olabilir. Genellikle yüklenici tarafında yapılan bir aktivite olsa da kritikliği düşük değişiklikleri karşılayan ekipman ve yetenekli personel varsa kullanıcı da gerçekleştirebilir. Yazılım modifikasyonu, kodlama değişikliğinin uygulanması ve test gibi modifikasyonun direkt kendi aktivitelerini ve problemin araştırılması ve konfigürasyon kontrolü gibi ilişkili görevleri de içerir. Genellikle, yazılım değişikliği için en kritik sebep ürünün operasyonunda kabul edilemez bir duruma sebep olan gerçek bir hata yaşanmasıdır. Adaptif değişiklikler de kritik bir durumdan kaynaklanabilir ancak daha tahmin edilebilir ve planlanabilir değişikliklerdir. Tamamlayıcı değişiklikler ise işlevselliği ve kullanıcı kolaylığını artırmak için yapılan değişikliklerdir. Genellikle bir sürüm yükseltme ile birlikte yapılırlar. Kullanıcı gereksinimleri bir süre boyunca toplanır ve yeni yazılım paketinin yayınlanmasıyla uygulamaya koyulurlar. Yazılım modifikasyon görevleri, problem araştırması, değişikliğin uygulanması, değişikliğin yayınlanması, konfigürasyon kontrolü faaliyetlerinden oluşur.
Yazılım modifikasyonu, düzeltici, adaptif veya tamamlayıcı sebeplerden ötürü olabilir. Genellikle yüklenici tarafında yapılan bir aktivite olsa da kritikliği düşük değişiklikleri karşılayan ekipman ve yetenekli personel varsa kullanıcı da gerçekleştirebilir. Yazılım modifikasyonu, kodlama değişikliğinin uygulanması ve test gibi modifikasyonun direkt kendi aktivitelerini ve problemin araştırılması ve konfigürasyon kontrolü gibi ilişkili görevleri de içerir. Genellikle, yazılım değişikliği için en kritik sebep ürünün operasyonunda kabul edilemez bir duruma sebep olan gerçek bir hata yaşanmasıdır. Adaptif değişiklikler de kritik bir durumdan kaynaklanabilir ancak daha tahmin edilebilir ve planlanabilir değişikliklerdir. Tamamlayıcı değişiklikler ise işlevselliği ve kullanıcı kolaylığını artırmak için yapılan değişikliklerdir. Genellikle bir sürüm yükseltme ile birlikte yapılırlar. Kullanıcı gereksinimleri bir süre boyunca toplanır ve yeni yazılım paketinin yayınlanmasıyla uygulamaya koyulurlar. Yazılım modifikasyon görevleri, problem araştırması, değişikliğin uygulanması, değişikliğin yayınlanması, konfigürasyon kontrolü faaliyetlerinden oluşur.
'''<big>6. DESTEK SINIFLARI</big>'''
'''<big>6.1. SÜREÇLER</big>'''
Yazılım desteğine ilişkin süreçlerin nasıl uygulamaya konulacağı, girdiler, çıktılar, kontroller ve kaynakları da içerecek şekilde dokümante edilmelidir. Bu kapsamda, akış şemaları, tanımlar, gereksinim ve sorumluluklar verilebilir. Uluslararası veya şirket içi kabul görmüş bir standart ve kullanılabilir ölçülebilir performans parametreleri tanımlanabilir.
Yazılım desteğine ilişkin süreçlerin nasıl uygulamaya konulacağı, girdiler, çıktılar, kontroller ve kaynakları da içerecek şekilde dokümante edilmelidir. Bu kapsamda, akış şemaları, tanımlar, gereksinim ve sorumluluklar verilebilir. Uluslararası veya şirket içi kabul görmüş bir standart ve kullanılabilir ölçülebilir performans parametreleri tanımlanabilir.
'''<big>6.2. ÜRÜN</big>'''
Yazılım ürün karakteristiğinde desteklenebilirlik mümkün olduğunca erken safhalarda adreslenmelidir. Yazılım kalitesi, yazılımın ne kadar iyi ya da kötü tasarlandığına bağlıdır. İyi bir yazılım tasarımı için gereksinimlerin net bir şekilde tanımlanması ve grafiksel kullanıcı arayüzü desteğinin sağlanması gerekmektedir. Modülerlik, değiştirilebilirlik, genişletilebilirlik, basitlik, kolay kullanım, kararlılık, tutarlılık, işlem süresi performansı gibi hususlar tipik yazılım kalite göstergerleri olarak verilebilir.
Yazılım ürün karakteristiğinde desteklenebilirlik mümkün olduğunca erken safhalarda adreslenmelidir. Yazılım kalitesi, yazılımın ne kadar iyi ya da kötü tasarlandığına bağlıdır. İyi bir yazılım tasarımı için gereksinimlerin net bir şekilde tanımlanması ve grafiksel kullanıcı arayüzü desteğinin sağlanması gerekmektedir. Modülerlik, değiştirilebilirlik, genişletilebilirlik, basitlik, kolay kullanım, kararlılık, tutarlılık, işlem süresi performansı gibi hususlar tipik yazılım kalite göstergerleri olarak verilebilir.
'''<big>6.3. ÇEVRE</big>'''
Kaliteyi etkileyen çevresel durumlar yazılımı kullanacak ve destekleyecek personel ile başlar. Doğru bir yazılım desteği kapsamında personelin yazılım destek işi için doğru kişi olması, yetenek ve deneyiminin seviyesi, sorunsuz bir yazılım desteğini garanti etmek için kaç kişinin gerekeceği gibi konular önemlidir. Personele ek olarak, tesisler, ofislerin genişliği vb. konular da desteğin kalitesi açısından önemlidir. Bakım görevlerinin belirlenmesi kapsamında bu hususların mutlaka değerlendirilmesi gerekmektedir.
Kaliteyi etkileyen çevresel durumlar yazılımı kullanacak ve destekleyecek personel ile başlar. Doğru bir yazılım desteği kapsamında personelin yazılım destek işi için doğru kişi olması, yetenek ve deneyiminin seviyesi, sorunsuz bir yazılım desteğini garanti etmek için kaç kişinin gerekeceği gibi konular önemlidir. Personele ek olarak, tesisler, ofislerin genişliği vb. konular da desteğin kalitesi açısından önemlidir. Bakım görevlerinin belirlenmesi kapsamında bu hususların mutlaka değerlendirilmesi gerekmektedir.
'''<big>7. DESTEKLENEBİLİRLİK FAKTÖRLERİ</big>'''
Yazılım için desteklenebilirlik faktörlerinin bazıları operasyonel destek ile ilişkiliyken, bazıları yazılım modifikasyon desteği ile ilgili olabilirler. Bu nedenle bu faktörlerin proje gereksinimleri dikkate alınarak ele alınması önemlidir. Yazılım desteklenebilirlik faktörleri ile ilgili açıklamalar ilerleyen bölümlerde verilmiştir. Yazılım desteklenebilirlik faktörlerinin geliştirme safhasında dikkate alınması (uygulanabilir olanlar için gereksinim tanımlanması, işlevsel akışa dahil edilmesi vb.) gerekmektedir.
Yazılım için desteklenebilirlik faktörlerinin bazıları operasyonel destek ile ilişkiliyken, bazıları yazılım modifikasyon desteği ile ilgili olabilirler. Bu nedenle bu faktörlerin proje gereksinimleri dikkate alınarak ele alınması önemlidir. Yazılım desteklenebilirlik faktörleri ile ilgili açıklamalar ilerleyen bölümlerde verilmiştir. Yazılım desteklenebilirlik faktörlerinin geliştirme safhasında dikkate alınması (uygulanabilir olanlar için gereksinim tanımlanması, işlevsel akışa dahil edilmesi vb.) gerekmektedir.
'''<big>7.1. UYUMLULUK MATRİSİ</big>'''
Bir sistemde farklı donanımlar üzerindeki farklı yazılımların birlikte çalışabildiği ve yazılım kalemleri içeren fiziksel kırılım içerisinde yazılımların donanımlarla uyumluluğu doğrulanmalıdır. Yazılım paketi taşıyan birbiriyle konuşan ekipmanlarla ilişkili uyumluluk matrisi hazırlanmalıdır.
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.
|x
|x
|}
|}
'''<big>7.2. DOKÜMANTASYON</big>'''
Tanımlanmış bakım seviyeleri kapsamında yazılım destek dokümantasyonunun hazırlanması gerekmektedir. Yüklenici tarafında gerekli yazılım destek dokümantasyonu veya kullanıcıya tanımlanan yetkiler dahilinde son kullanıcı el kitabı, yükleme, konfigürasyon gibi amaçları olan yönetim dokümantasyonları olabilir.
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.
Operasyonel açıdan, orta ve üst düzey kullanıcılar açısından dokümantasyon önemlidir. Dokümantasyon; yükleme, konfigürasyon adımları ve sorun giderme ile ilgili taktikler içermelidir. Ciddi hatalar oluşması durumunda da yüklenici firma iletişime geçilecek kişinin iletişim bilgilerini de içermelidir.
'''<big>7.3. YAZILIM YÜKLEME VE KALDIRMA</big>'''
Yazılımların güvenli bir şekilde sisteme yüklendiği, sistemin problemsiz çalıştığı ve yazılımın kaldırılması test prosedürleri ile doğrulanmış ve dokümante edilmiş olmalıdır.
Yazılımların güvenli bir şekilde sisteme yüklendiği, sistemin problemsiz çalıştığı ve yazılımın kaldırılması test prosedürleri ile doğrulanmış ve dokümante edilmiş olmalıdır.
'''<big>7.4. DONANIMLAR ÜZERİNDE TAŞINMA</big>'''
Eğer yazılımın bir donanım üzerinde taşınması gerekiyorsa yazılımın tipine, boyutuna ve güvenlik gereksinimlerine göre hangi donanımla taşınacağı belirlenir. Çipler veya usb belleklerle taşınıp taşınamayacağı, hard disk ya da DVD ihtiyacı olup olmadığı, donanımda taşımanının güvenli olup olmadığı değerlendirilmelidir.
Eğer yazılımın bir donanım üzerinde taşınması gerekiyorsa yazılımın tipine, boyutuna ve güvenlik gereksinimlerine göre hangi donanımla taşınacağı belirlenir. Çipler veya usb belleklerle taşınıp taşınamayacağı, hard disk ya da DVD ihtiyacı olup olmadığı, donanımda taşımanının güvenli olup olmadığı değerlendirilmelidir.
'''<big>7.5. GENİŞLEME KAPASİTESİ</big>'''
Genişleme kapasitesi sistem tasarımının bir parçasıdır, yazılımla ilişkili olsa da genellikle tüm sistem tasarımı içerisinde ele alınması gereken bir donanım karakteristiğidir. Yazılımın hesaplama kaynakları üzerinde kısıtlamalarda (işlemci performansı, bellek, girdi/çıktı bant genişliği, veritabanı kapasitesi, network performansı vb.) limiti olmadan ne kadar değiştirilebildiği ile ilgilenir. Genişleme kapasitesi yeterli detayda ele alınmazsa yazılım modifikasyonu limitli olacaktır. Modifikasyon maliyeti ciddi ölçüde artacak ve ek aktiviteler gerekebilecektir. Genişleme kapasitesi, sabit donanım konfigürasyonu olan sistemlerde ve gömülü sistem gerçek zaman uygulamalarında yüksek önem taşır. Bu nedenle tasarım safhasında genişleme kapasitesinin göz önünde bulundurulması önemlidir.
Genişleme kapasitesi sistem tasarımının bir parçasıdır, yazılımla ilişkili olsa da genellikle tüm sistem tasarımı içerisinde ele alınması gereken bir donanım karakteristiğidir. Yazılımın hesaplama kaynakları üzerinde kısıtlamalarda (işlemci performansı, bellek, girdi/çıktı bant genişliği, veritabanı kapasitesi, network performansı vb.) limiti olmadan ne kadar değiştirilebildiği ile ilgilenir. Genişleme kapasitesi yeterli detayda ele alınmazsa yazılım modifikasyonu limitli olacaktır. Modifikasyon maliyeti ciddi ölçüde artacak ve ek aktiviteler gerekebilecektir. Genişleme kapasitesi, sabit donanım konfigürasyonu olan sistemlerde ve gömülü sistem gerçek zaman uygulamalarında yüksek önem taşır. Bu nedenle tasarım safhasında genişleme kapasitesinin göz önünde bulundurulması önemlidir.
'''<big>7.6. MODÜLER YAZILIM TASARIMI</big>'''
Modülerlik yazılım tasarım yapısının bir özelliğidir. Bir yazılım paketinin içindeki işlevselliğin farklı alanları modüller yardımıyla yapılandırılır. Bir yazılım tasarımına modülerlik kazandırma imkânı tasarım yöntemi, programlama araçları ve programlama dili seçimiyle belirlenir. Optimum modülerliğe, desteklenebilir tasarım karşısında işlevsel ve performans gereksinimlerinin dengelenmesi ile ulaşılır. Yetersiz modülerlik ilave modifikasyon eforuna ve maliyetine sebep olur. Bu nedenle tasarım safhasında modülerliğin göz önünde bulundurulması önemlidir.
Modülerlik yazılım tasarım yapısının bir özelliğidir. Bir yazılım paketinin içindeki işlevselliğin farklı alanları modüller yardımıyla yapılandırılır. Bir yazılım tasarımına modülerlik kazandırma imkânı tasarım yöntemi, programlama araçları ve programlama dili seçimiyle belirlenir. Optimum modülerliğe, desteklenebilir tasarım karşısında işlevsel ve performans gereksinimlerinin dengelenmesi ile ulaşılır. Yetersiz modülerlik ilave modifikasyon eforuna ve maliyetine sebep olur. Bu nedenle tasarım safhasında modülerliğin göz önünde bulundurulması önemlidir.
'''<big>7.7. MODİFİKASYON FREKANSI (DEĞİŞİKLİK TRAFİĞİ)</big>'''
Yazılımın modifikasyon ihtiyacının oranıdır. Yazılım kullanımından önce modifikasyon frekansı tahminleri benzer uygulamaların (kullanımdaki yazılımlar) yardımı ile yazılımın bazı karakteristikleriyle, test ve deneme fazındaki deneyimlerle yapılabilir. Modifikasyon frekansının kararlılığı yazılım entegrasyonunu ve sistem operasyonunu etkiler. Değişiklik trafiği, yazılım destek aktivitelerinin hacmini etkiler. Yüksek değişiklik trafiği daha fazla yazılım modifikasyon aktivitesi demektir. Bu nedenle tasarım safhasında modifikasyon frekansının göz önünde bulundurulması önemlidir.
Yazılımın modifikasyon ihtiyacının oranıdır. Yazılım kullanımından önce modifikasyon frekansı tahminleri benzer uygulamaların (kullanımdaki yazılımlar) yardımı ile yazılımın bazı karakteristikleriyle, test ve deneme fazındaki deneyimlerle yapılabilir. Modifikasyon frekansının kararlılığı yazılım entegrasyonunu ve sistem operasyonunu etkiler. Değişiklik trafiği, yazılım destek aktivitelerinin hacmini etkiler. Yüksek değişiklik trafiği daha fazla yazılım modifikasyon aktivitesi demektir. Bu nedenle tasarım safhasında modifikasyon frekansının göz önünde bulundurulması önemlidir.
'''<big>7.8. GERİYE DÖNDÜRME</big>'''
Bir yazılım hatasından kaynaklı sistem çalışmadığında, sistemi yeniden başlatmak veya en azından kabul edilebilir bir sürede azalmış ama kabul edilebilir işlevselliğe getirmek gereklidir. Geriye döndürme yazılımın erken tasarım safhalarında, sağlıklı izleme durumu, hataya toleranslı denetimciler, hata ayıklama (debug) özelliği için tasarım gibi konular da değerlendirilmelidir. Erişilebilir ekipmanla operasyonel gerçek zaman güncellemesi gerçekleştirebilecek bir geriye döndürme özelliği olması kritik önem taşımakta olup geliştirme safhasında dikkate alınmalıdır. Gerçek bir acil durum oluşmadan yazılımın geriye döndürülmesi test edilmiş olmalıdır.
Bir yazılım hatasından kaynaklı sistem çalışmadığında, sistemi yeniden başlatmak veya en azından kabul edilebilir bir sürede azalmış ama kabul edilebilir işlevselliğe getirmek gereklidir. Geriye döndürme yazılımın erken tasarım safhalarında, sağlıklı izleme durumu, hataya toleranslı denetimciler, hata ayıklama (debug) özelliği için tasarım gibi konular da değerlendirilmelidir. Erişilebilir ekipmanla operasyonel gerçek zaman güncellemesi gerçekleştirebilecek bir geriye döndürme özelliği olması kritik önem taşımakta olup geliştirme safhasında dikkate alınmalıdır. Gerçek bir acil durum oluşmadan yazılımın geriye döndürülmesi test edilmiş olmalıdır.
'''<big>7.9. EMNİYET ENTEGRASYONU</big>'''
Sistemin emniyet analizi yazılımlar da dikkate alınarak yapıldıktan sonra, sistem tasarımı kritik fonksiyonları olan yazılım kalemlerinin minimize edilmiş olduğunu ya da en azından kritik fonksiyonların yazılımın diğer kısımlarından ayrıştırıldığını garanti etmelidir. Emniyet entegrasyonu yalnızca yazılım tasarımıyla ilgili değildir. Yazılımın taşıma, yükleme ve kullanımında da (ör. yazılımlara kullanıcı erişimleri) belirli bir emniyet seviyesine ulaştığı garanti edilmelidir.
Sistemin emniyet analizi yazılımlar da dikkate alınarak yapıldıktan sonra, sistem tasarımı kritik fonksiyonları olan yazılım kalemlerinin minimize edilmiş olduğunu ya da en azından kritik fonksiyonların yazılımın diğer kısımlarından ayrıştırıldığını garanti etmelidir. Emniyet entegrasyonu yalnızca yazılım tasarımıyla ilgili değildir. Yazılımın taşıma, yükleme ve kullanımında da (ör. yazılımlara kullanıcı erişimleri) belirli bir emniyet seviyesine ulaştığı garanti edilmelidir.
'''<big>7.10. GÜVENLİK</big>'''
Yazılımın kendisi ile ilgili olup; dijital imza, aktivasyon veya lisans anahtarları, kriptolama, çevrimsel hata denetimi gibi güvenlik metotları mevcuttur. Yazılımın güvenlik sınıflandırması, çalıştırılabilir kodu ve dokümantasyonu yazılım destek aktivitelerini kısıtlayabilir. Yazılıma erişim kısıtlanabilir ve spesifik yazılım test görevleri ve ekipmanlarının önemini artıracak gereksinimler tanımlanabilir. Yazılımın güvenlik sınıflandırması, uygulamaya ve ekipmanın tasarımına bağlıdır. Mümkün olduğu ölçüde güvenlik seviyesi yüksek yazılımlar, sistemdeki diğer yazılımlardan ayrı olmalıdır. Güvenlik gereksinimleri sınıflandırmada kullanılacak ve sınıflandırmaya uygun olarak modifikasyon ve yazılımın ele alma kısıtlarını belirleyecektir.
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.
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.
Savunma ve güvenlik sistemlerindeki yazılımlar üçüncü tarafın eline geçmemesi için kullanımdan sonra silinebilir. Bu konuya ilişkin tedbirlerin alınmış olması gerekir.
'''<big>7.11. BOYUT</big>'''
Yazılım paketinin boyutu, beklenen değişiklik trafiği seviyesi ve modifikasyonları uygulamak için gereken kaynaklar açısından desteklenebilirlik parametrelerini etkiler. Yazılımın boyutu, uygulamaya ve tasarım çözümüne bağlıdır. Sistem tasarımında boyutla ilgili bir kısıt varsa yazılım gereksinimlerinde belirtmelidir. Birçok yazılım desteği yazılımın boyutuna ve karmaşıklığına bağlıdır.
Yazılım paketinin boyutu, beklenen değişiklik trafiği seviyesi ve modifikasyonları uygulamak için gereken kaynaklar açısından desteklenebilirlik parametrelerini etkiler. Yazılımın boyutu, uygulamaya ve tasarım çözümüne bağlıdır. Sistem tasarımında boyutla ilgili bir kısıt varsa yazılım gereksinimlerinde belirtmelidir. Birçok yazılım desteği yazılımın boyutuna ve karmaşıklığına bağlıdır.
'''<big>7.12. YETKİNLİKLER</big>'''
Yetkinlik gereksinimleri, sistem tasarımı, yazılım tasarımı ve uygulanabilir yazılım destek politikası tarafından belirlenir. Personelin yetkinlik seviyesi, birden fazla açıdan değerlendirilmelidir. Sırasıyla basit düzeyde kullanıcı, yönetim sorumluluğu olan operatörler ve en yetkin olması gereken yazılım modifikasyonu yapacak kişilerdir.
Yetkinlik gereksinimleri, sistem tasarımı, yazılım tasarımı ve uygulanabilir yazılım destek politikası tarafından belirlenir. Personelin yetkinlik seviyesi, birden fazla açıdan değerlendirilmelidir. Sırasıyla basit düzeyde kullanıcı, yönetim sorumluluğu olan operatörler ve en yetkin olması gereken yazılım modifikasyonu yapacak kişilerdir.
'''<big>7.13. YAZILIM DAĞITIMI</big>'''
Yazılım LAN, WAN gibi ağlar üzerinden veya bir donanım aracılığıyla farklı medya tipleri ile dağıtılabilir.
Yazılım LAN, WAN gibi ağlar üzerinden veya bir donanım aracılığıyla farklı medya tipleri ile dağıtılabilir.
'''<big>7.14. TEKNOLOJİ</big>'''
Yazılım tasarım yöntemleri ve destek araçları, işleten sistemler, programlama dilleri, derleyiciler, hata ayıklayıcılar, yazılım test metot ve test ortamı, projeye özgü ekipman ve teknikler gibi yazılım mühendisliği metotları ve yazılım geliştirme-uygulamada kullanılan araçlar da dikkate alınmalıdır. Teknolojinin ağ üzerinden yapılacak destek bakım konseptini kolaylaştırması gibi operasyonel olarak da etkileri vardır.
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ı
* Programın hem yüklenici hem de müşteri tarafındaki yönetim yapıları
* LDA faaliyetlerinin proje takvimi ile entegrasyonu
* LDA faaliyetlerinin proje takvimi ile entegrasyonu
* İş paylaşımı anlaşmaları
* İş 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.
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.
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.
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.
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:
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:
* 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?
* 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.
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.
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.
AKL sadece ürün ağacından analize tabi olmak üzere seçilen elemanları değil aynı zamanda bu elemanlar için gerçekleştirilecek analiz faaliyetlerini de içerebilir. Seçilen analizlerle birlikte, analizlerin gerçekleştirileceği derinlik de tanımlanmalıdır. Örneğin BGA için her bir bakım görevinin hangi derinlikte dokümante edileceği ve personel gereksinimlerinin belirlenmesine gerek olup olmadığı tanımlanmalıdır.
AKL aynı zamanda LDA programı için bütün eforun özetlendiği bir gözden geçirme vasıtası olarak ve çalışmaların ilerlemesinin takip edildiği bir yönetim aracı olarak da kullanılabilir.
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.
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.
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.
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.
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.