ADA633324 (1)

Machine Translated by Google SMC Standardı SMC-S-21 15 Eylül 2009 KOMUTANIN EMRİYLE ------------ yerine geçer: Yeni baskı Hava Kuvvetleri Uzay Komutanlığı UZAY VE FÜZE SİSTEMLERİ MERKEZİ STANDART TEKNİK İNCELEMELER VE DENETİMLER SİSTEMLER İÇİN, EKİPMAN VE BİLGİSAYAR YAZILIMI SES SEVİYESİ 1 KAMUYA AÇIKLAMA İÇİN ONAYLANMIŞTIR; DAĞITIM SINIRSIZDIR Machine Translated by Google Form Onaylı OMB No. 0704-0188 Rapor Dokümantasyon Sayfası Talimatların gözden geçirilmesi, mevcut veri kaynaklarının aranması, ihtiyaç duyulan verilerin toplanması ve sürdürülmesi ve bilgilerin toplanmasının tamamlanması ve gözden geçirilmesi dahil olmak üzere, bilgi toplama için kamuya açık raporlama yükünün yanıt başına ortalama 1 saat olduğu tahmin edilmektedir. Bu yükün azaltılmasına yönelik öneriler de dahil olmak üzere, bu yük tahmini veya bu bilgi derlemesinin diğer herhangi bir yönü ile ilgili yorumlarınızı Washington Genel Merkez Hizmetleri, Bilgi İşlemleri ve Raporlar Müdürlüğü, 1215 Jefferson Davis Highway, Suite 1204, Arlington VA 22202-4302 adresine gönderin. Yanıt verenler, başka herhangi bir yasa hükmüne bakılmaksızın, şu anda geçerli bir OMB kontrol numarası göstermiyorsa, hiç kimsenin bir bilgi toplamaya uymadığı için cezaya tabi tutulamayacağını bilmelidir. 1. RAPOR TARİHİ 2. RAPOR TÜRÜ 15 EYLÜL 2009 Yok 3. KAPSAMINDAKİ TARİHLER - 4. BAŞLIK VE ALT BAŞLIK 5a. SÖZLEŞME NUMARASI SMC-S-021 (2009) Sistemler, Ekipman ve Bilgisayar Yazılımı için Teknik İncelemeler ve Denetimler 5b. HİBE SAYISI 5c. PROGRAM ELEMAN SAYISI 5d. PROJE NUMARASI 6. YAZAR(LAR) 5e. GÖREV NUMARASI 5f. İŞ BİRİMİ SAYISI 7. İFADE EDEN KURULUŞUN İSİM(LER)İ VE ADRES(LER)İ 8. İFADE EDEN ORGANİZASYON USAF Uzay ve Füze Sistemleri Merkezi NUMARAYI BİLDİR 9. SPONSORLUK/İZLEME KURUMUNUN İSİM(LER)İ VE ADRES(LER)İ 10. SPONSOR/İZLEYİCİNİN KISALTMALARI 11. SPONSOR/İZLEME RAPOR NUMARALARI 12. DAĞITIM/MEVCUT BEYANI Herkese açık sürüm için onaylandı, dağıtım sınırsız 13. İLAVE NOTLAR 14. ÖZET 15. KONU ŞARTLARI 17. ÖZETİN 16. GÜVENLİK SINIFLANDIRMASI: SINIRLANDIRILMASI A. RAPOR sınıflandırılmamış B. SOYUT sınıflandırılmamış C. BU SAYFA sınıflandırılmamış UÜ 18. SAYI SAYFA SAYISI 19a. ADINA SORUMLULUK SAHİBİ KİŞİ 177 Standart Form 298 (Rev. 8-98) ANSI Std Z39-18 tarafından öngörülmüştür Machine Translated by Google Machine Translated by Google ÖNSÖZ Bu standart, Hükümetin yüklenici için gerekliliklerini ve beklentilerini tanımlar. 1. savunma sistemi alımları ve teknoloji geliştirme performansı. 2. Bu yeni yayın SMC standardı, Aerospace Corporation rapor numarası TOR-2007(8583)-6414, Cilt 1, Rev. A, Sistemler , Ekipman ve Bilgisayar Yazılımı için Teknik İncelemeler ve Denetimler başlıklı metnini içerir . 3. Bu standardın iyileştirilmesinde kullanılabilecek faydalı yorumlar (tavsiyeler, değişiklikler, eklemeler, çıkarmalar vb.) ve ilgili veriler, bu belgenin sonunda yer alan Standardizasyon Belgesi İyileştirme Önerisi kullanılarak veya mektupla aşağıdaki muhataba iletilmelidir. : Bölüm Şefi, SMC/EAE UZAY VE FÜZE SİSTEMLERİ MERKEZİ Hava Kuvvetleri Uzay Komutanlığı 483 N. Aviation Blvd. El Segundo, CA 90245 4. Bu standart , tüm Uzay ve Füze Sistemleri Merkezi/Hava Kuvvetleri Programı İdari Ofis- Uzay geliştirme , satın alma ve idame sözleşmelerinde kullanılmak üzere onaylanmıştır . ~--.,- DAVID E. SWANSON, COL, USAF SMC Baş Mühendisi Machine Translated by Google Machine Translated by Google İçindekiler Paragraf Sayfa Önsöz................................................. ................................................... ................................................... .iii Teşekkür ................................................... ................................................... ................................................ iv 1. Kapsam ................................................. ................................................... ................................................ 1 1.1 Amaç ...... ................................................... ................................................... ................................ 2 1.2 Teknik İncelemelerin Amaçları ................ ................................................... ................................. 2 Uygulama ................................ Sınıflandırma ................ ................................................... ................................................... ................................................................ ................................................... ................ 3 1.5 Teknik 1.3 3İncelemelerin 1.4 Planlanması ................................................... ................................................... .4 2. Belgeler................................................... ................................................... ................................ 7 3. Teknik Gözden Geçirme ve Denetimlerin Tanımları ................................................ ................................. 9 Sistem 3,1 Gereksinimlerinin Gözden Geçirilmesi (SRR)............. ................................................... ................................ 9 Sistem 3,2 3,3 3,4 3,5 3,6 3,7 3,8 3,9 3,10 3,11 4. 4.1 Fonksiyonel İncelemesi (SFR) ........... ................................................... ................................... 9 Yazılım Gereksinimi ve Mimari İncelemesi (SAR) ...... ................................................... .... 10 Ön Tasarım Gözden Geçirme (PDR) ...................................... ................................................... ... 10 Eleştirel Tasarım İncelemesi (CDR)............................................ ................................................... ......... 11 Teste Hazırlık Gözden Geçirmesi (TRR)................................... ................................................... ................ 11 Fonksiyonel Konfigürasyon Denetimi (FCA) ............................ ................................................... ......... 12 Fiziksel Konfigürasyon Denetimi (PCA)................................... ................................................... ...... 12 Sistem Doğrulama İncelemesi (SVR)................................................. ................................................... ..... 13 Üretime Hazırlık Gözden Geçirmesi (MRR)................................................... ................................................ 13 Üretime Hazırlık Gözden Geçirmesi (PRR ) ................................................ ................................................ 13 Teknik Gözden Geçirme Hedefleri ................................................ ................................................... .... 15 Yorum 4.2 Belirtildi ...................................... ................................................... ...................... 15 Teknik Gözden Geçirme Kriteri .................... ................................................... ................................... 15 Teknik Gözden Geçirme 4.3 Başarısı.................... ................................................... ................................................ 16 5. Roller, Sorumluluklar ve Yetki ................................................ ................................................ 19 Yüklenici Katılımı ve 5.1 5.1.1 5.1.2 5.1.3 5.2 5.2.1 5.2.2 5.3 Sorumlulukları .. ................................................... ...................... 19 Alt Yükleniciler ve Tedarikçiler ...................... ................................................... ................................ 19 Başkan.................... ................................................... ................................................... .......... 19 Yüklenici Gereksinimleri................................... ................................................... ................ 19 Satın Alma Sözleşme Görevlisi (PCO) Katılımı ve Sorumluluğu ............................ ........... 21 Satın Alma Sözleşme Görevlisi (PCO) Rolü ................................ ................................................ 21 Gözden Geçirme Paneli ve Katılımcı Seçimi ................................................... ........................................ 21 Resmi Teşekkür ....... ................................................... ................................................... 23 Veri Gereksinimleri Listesi ve Çapraz 5.4 Referans ...................................... ................................ 23 6. İlgili Teknik Gözden Geçirme ve Denetim Öğeleri ................................................ ................................. 25 Kaynak Otorite ve 6.1 6.2 6.3 6.4 6.5 Materyal ............ ................................................... ................................................. 25 ACAT Programları ve Sözleşme Yönergesi ....... ................................................... ................................... 25 “Kabul Kriterleri”................................ ................................................... ................................................ 26 Sistem Mühendisliği Süreç Hedefleri ...... ................................................... ............................ 26 Teknoloji Hazırlık Değerlendirmesi (TRA)................ ................................................... .......... 27 Machine Translated by Google Ek A - Sistem Gereksinimlerinin İncelenmesi (SRR) 10. Sistem Gereksinimlerini Gözden Geçirme (SRR)............................................ ................................................ 31 10.1 Genel.. ................................................... ................................................... ................................... 31 10.2 Amaç .......... ................................................... ................................................... ...................... 31 10.3 Amaç ...................... ................................................... ................................................... ........ 32 SRR “Kabul ve MimarisiKriterleri” Geliştirme................................... ...................... ................................................ ................................................... 35 10.4.2 ................. Sistem (Sistemi 10.4 34Sistemler, 10.4.1 Sistem Sistem Mühendisliği Ailesi), Segment ve Alt Sistem Tasarımı ................ 37 10.4.3 Sistem, Segment ve Alt Sistem Doğrulama ve Validasyon ...................... ................................................ 40 10.4.4 Mühendislik Disiplinleri ve Uzmanlık Mühendisliği ................................................... ................. 41 10.4.5 Entegre Teknik Risk Yönetimi ve Azaltma ...................... ................................................ 47 Ek B - Sistem İşlevsel İncelemesi (SFR) 20. Sistem İşlevsel İncelemesi (SFR) ............................................ ................................................... 49 20.1 Genel................................................... ................................................... ................................................ 49 20.2 Amaç ........ ................................................... ................................................... ................................ 50 20.3 Amaç................................... ................................................... ................................................... .......... 50 20.4 SFR “Kabul Kriterleri” ............................ ................................................... ................................ 51 20.4.1 Sistem Mühendisliği ve Mimarisi Geliştirme ................. ................................................ 52 20.4 .2 Sistem, Segment ve Alt Sistem Tasarımı ...................................... ................................................ 54 20.4.3 Sistem, Segment ve Alt Sistem Doğrulama ve Validasyon................................................... .... 57 20.4.4 Mühendislik Disiplinleri ve Uzmanlık Mühendisliği................................................... ................................ 58 20.4.5 Entegre Teknik Risk Yönetimi ve Azaltma .......................... ................................................... .65 Ek C - Yazılım Gereksinimi ve Mimari İncelemesi (SAR) 30. Yazılım Gereksinimi ve Mimari İncelemesi (SAR) .......................................... ................. 67 30.1 Genel .......................... ................................................... ................................................... ....... 67 30.2 Amaç .......................................... ................................................... ................................................ 69 İncelenecek Madde.. ................................................... ................................................... .......... 70 30.3 30.4 SAR “Kabul Kriterleri” ................................ ................................................... ...................... 72 30.5 İnceleme Sonrası İşlem ................................ ................................................... ................................................ 76 Ek D - Ön Tasarım İncelemesi (PDR) 40. Ön Tasarım İncelemesi (PDR) ............................................ ................................................ 77 40.1 Genel................................................. ................................................... ................................................ 77 40.2 Amaç .......... ................................................... ................................................... ............................ 78 Amaç ...................... ................................................... ................................................... .......... 79 40.3 40.4 PDR “Kabul Kriterleri” ................................ ................................................... ...................... 79 40.4.1 Sistem Mühendisliği ve Mimarisi Geliştirme ................... ................................................ 80 40.4.2 Sistem , Segment ve Alt Sistem Tasarımı ................................................ ................................................ 83 40.4.3 Sistem, Segment ve Alt Sistem Doğrulaması ve Doğrulama................................................... 85 40.4.4 Mühendislik Disiplinleri ve Uzmanlık Mühendisliği................................................... ................................ 86 40.4.5 Entegre Teknik Risk Yönetimi ve Azaltma................................ ................................................ 90 Machine Translated by Google Ek E - Kritik Tasarım İncelemesi (CDR) 50. Kritik Tasarım İncelemesi (CDR)............................................ ................................................... ..... 93 50.1 Genel............................................ ................................................... ................................................ 93 50.2 Amaç ... ................................................... ................................................... ................................ 94 50.3 Amaç................. ................................................... ................................................... ................. 94 50.4 CDR “Kabul Kriterleri” ................................ ................................................... ................................ 95 50.4.1 Sistem Mühendisliği ve Mimarisi Geliştirme ............ ................................................... .. 97 50.4.2 Sistem, Segment ve Alt Sistem Tasarımı ................................................... ................................................ 99 50.4.3 Sistem , Segment ve Alt Sistem Doğrulama ve Validasyon............................................ ...... 101 50.4.4 Mühendislik Disiplinleri/Uzmanlık Mühendisliği ................................... ................................... 102 Entegre Teknik Risk Yönetimi ve Azaltma...... ................................................... .. 111 50.4.5 Ek F - Teste Hazırlık İncelemesi (TRR) Teste Hazırlık İncelemesi (TRR)............................................ ................................................... .... 113 60. 60.1 Genel ...................................... ................................................... ................................................ 113 60.2 Amaçlar .... ................................................... ................................................... ...................... 113 60.3 İncelenecek Öğeler................................ ................................................... ................................................ 113 60.4 TRR “Kabul Kriterleri” .. ................................................... ................................................... 115 Ek G - İşlevsel Yapılandırma Denetimi (FCA) 70. 70.1 70.2 70.3 70.4 70.5 İşlevsel Yapılandırma Denetimi (FCA) ................................................ ........................................ 117 Genel........ ................................................... ................................................... ...................... 117 Sözleşme Gereksinimleri ................................ ................................................... ................................................ 117 Yüklenicinin Sorumluluğu ....... ................................................... ................................................ 117 Prosedürler ve Gereksinimler ................................................... ................................................ 118 Denetim Sonrası Aksiyonlar ................................................ ................................................... ................... 119 Ek H - Fiziksel Yapılandırma Denetimi (PCA) 80. Fiziksel Yapılandırma Denetimi (PCA)............................................ ................................................ 120 80.1 Genel... ................................................... ................................................... ................................ 120 80.2 Sözleşme Gereksinimleri ................ ................................................... ................................................ 120 80.3 Yüklenicinin Sorumluluğu .. ................................................... ................................................... ... 120 80.4 PCA Prosedürleri ve Gereksinimleri................................................... ................................................ 122 80.5 Denetim Sonrası Aksiyonlar................................................... ................................................... ................... 124 Ek I - Sistem Doğrulama İncelemesi (SVR) 90. 90.1 90.2 90.3 Sistem Doğrulama İncelemesi (SVR)............................................ ................................................ 126 Genel.. ................................................... ................................................... ................................ 126 Gereksinimler ................ ................................................... ................................................... ........ 126 İnceleme Sonrası Eylem ...................................... ................................................... ...................... 126 Ek J - İmalata Hazırlık Gözden Geçirmesi (MRR) ve Üretime Hazırlık Gözden Geçirmesi (PRR) 100. 100.1 100.2 100.3 Üretime Hazırlık Gözden Geçirmesi (MRR) ve Üretime Hazırlık Gözden Geçirmesi (PRR)................... 128 Genel...................... ................................................... ................................................... ............ 128 Üretime Hazırlık Gözden Geçirmesi (MRR)................................... ................................................................ 129 Üretime Hazırlık Gözden Geçirmesi (PRR) ............................................ ................................................ 131 Ek K - MIL-STD-1521'i Uyarlamak için Uygulama Kılavuzu Machine Translated by Google 110. MIL-STD-1521 Terziliği için Uygulama Kılavuzu................................................... ................................ 136 110.1 Kapsam ................... ................................................... ................................................... ................. 136 110.2 Amaç ................................ ................................................... ................................................... ... 136 110.3 Amaç............................................ ................................................... ................................................. 136 110.4 Terzilik için Dikkat Edilecek Hususlar........ ................................................... ................................................... 136 110.4.1 Çalışma Bildirimi ................................................ ................................................ 136 110.4.2 Fazlalığın ve Belirsizliğin Ortadan Kaldırılması ... ................................................... ................................ 137 110.4.3 Terzilik İşlerine Yüklenici Katılımı................... ................................................... ................................. 137 110.4.4 Karmaşıklık ............................ ................................................... ................................................... .. 137 110.5 Teknik Gözden Geçirme ve Denetimlerin Planlanması ................................................... ................................. 137 Mühendislik Veri İncelemeleri için Uyarlama Kılavuzu .................. ................................................... ....... 140 110.6 Sözlük Bölüm I – Tanımlar................................................... ................................................... .................................... 144 Kısım II – Kısaltmalar....... ................................................... ................................................... ...................... 162 Rakamlar Şekil 1. Genel Teknik İnceleme Süreç Haritası................................................... ................................................ 18 Şekil 2. TRA'nın Sistem Edinim Kapılarıyla İlişkisi , Kilometre Taşları ve Olaylar................................ 28 Şekil 3. Waterfall Yazılım Geliştirme Yaşam Döngüsü Modeli..... ................................................... ................. 68 Şekil 4. Artımlı Yazılım Geliştirme Yaşam Döngüsü Modeli................................... ................................ 68 Şekil 5. Evrimsel Yazılım Geliştirme Yaşam Döngüsü Modeli....... ................................................ 69 Şekil 6 .Mühendislik Verileri Uyuşmazlık Tablosu ................................................ ................................................ 144 Şekil 7. TRL'nin Sistem Geliştirme Olgunluğuyla İlişkisi ................................................... ......... 160 Tablolar Tablo 1. Özel Teknik Gözden Geçirme ve Denetim Amaçlarına İlişkin Satın Alma Politikası Örnekleri................... 4 Tablo 2. Örnek Eylem Kalemi Formu...................... ................................................... ................................................ 22 Tablo 3. Programlama Gözden Geçirme ve Denetimler ................................................ ................................................ 138 Tablo 4. Savunma Bakanlığı MRL Tanımları................................................... ................................................... ........... 151 Tablo 5. DoD MRL Açıklamaları ................................ ................................................... ...................... 151 Tablo 6. DoD TRL Tanımları................................... ................................................... ................................................ 159 Tablo 7. DoD Donanım ve Yazılım TRL Açıklamaları .. ................................................... ............ 161 Machine Translated by Google 1. Kapsam Bu belge, bir sistem, ekipman, dağıtılmış ve yerleşik Yazılım Konfigürasyon Öğesi (SWCI), Donanım Yapılandırma Öğesi (HWCI) ve/veya bunların bir kombinasyonu gibi son öğeler (EI'ler) üzerinde Teknik İncelemeler ve Denetimlerin yürütülmesine yönelik nesnel gereksinimleri açıklamaktadır. . Bu belge, Sistemler, Ekipmanlar ve Bilgisayar Yazılımı için MIL-STD-1521B (USAF) Teknik İncelemeleri ve Denetimleri için bir güncellemedir ve planlama ve yürütme için USAF Uzay ve Füze Sistemleri Merkezi (SMC) standardı (STD) olarak yayınlanacaktır. anahtar sistem mühendisliği incelemeleri. Bu güncelleme aynı zamanda teknik gözden geçirmeler ve denetimler için istenen bir süreci ve ilgili kriterleri belgelemektedir. Bu belge iki ciltten oluşmaktadır: Cilt 1 – sistemler, ekipman ve bilgisayar yazılımı EI'leri için genel bir teknik inceleme ve denetim seti ve bu standardın Ek A'dan K'ye kadar açıklanan incelemeler için uygun maliyetli uygulama ve uyarlamaya yönelik kılavuzu tanımlar: Ek A Sistem Gereksinimleri İncelemeleri (SRR) Ek B Sistem İşlevsel İncelemeleri (SFR) Ek C Yazılım Gereksinimleri ve Mimari İncelemesi (SAR) Ek D Ön Tasarım İncelemeleri (PDR) Ek E Kritik Tasarım İncelemeleri (CDR) Ek F Teste Hazırlık İncelemesi (TRR) Ek G İşlevsel Yapılandırma Denetimi (FCA) Ek H Fiziksel Yapılandırma Denetimi (PCA) Ek I Sistem Doğrulama İncelemesi (SVR) Ek J Üretim ve Üretime Hazırlık İncelemesi (P/MRR) Ek K MIL-STD-1521 Terziliği için Uygulama Kılavuzu 2. Cilt - Sözleşmeye göre uygulanacak Uzay Sistemlerine özgü ekipman ve bilgisayar yazılımı son öğeleri (EI'ler) için 1. Ciltteki temel teknik incelemeler (SRR, SFR, SAR, PDR ve CDR) için özel ve benzersiz ek kriter içeriği sağlar Çalışma Bildirimi (SOW). Bu kriterler ayrıca parçaları, malzemeleri, yapıları içerir; sistem mühendisliği, testler ve süreçler. Bu güncelleme, Hükümetin aşağıdaki beş ana kategoride belirtilen, ölçüt tabanlı teknik incelemelere yönelik gereksinimlerini sağlar: 1. Sistem mühendisliği ve mimari geliştirme 2. Sistem, segment ve alt sistem tasarımı 3. Sistem doğrulama ve doğrulama 4. Mühendislik disiplinleri ve uzmanlık mühendisliği 5. Entegre teknik risk ve hafifletme Son öğe (EI) geliştirme olgunluğu ve operasyonel kullanım hedeflerinin aşağıdaki temel incelemelerde daha ayrıntılı olarak açıklanması: Ek A Sistem Gereksinimleri İncelemesi (SRR) Ek B Sistem İşlevsel İncelemesi (SFR) Ek C Yazılım Gereksinimleri ve Mimari İncelemesi (SAR) Ek D Ön Tasarım İncelemesi (PDR) Ek E Kritik Tasarım İncelemesi (CDR) 1/168 Machine Translated by Google Güncelleme ayrıca seçilen disiplinler ve uzmanlık alanları için kriterleri ve tüm DoD sistemleri geliştirmelerinde genel gereksinimler kriter örnekleri açısından yukarıdaki temel incelemeleri desteklemek için gerçekleştirilecek ve belgelenecek ilgili işi değişen ayrıntılarla tanımlar ve tasvir eder. Ayrıca bu güncelleme, yüklenicinin başarılarının özel kanıtı olarak sunulmak üzere mühendislik disiplinleri ve uzmanlık süreçleriyle birlikte yüklenicinin belgelenmiş başarılarının gerekli kalite niteliklerini, yeterliliğini ve ilerlemesini de tanımlar. Genel teknik incelemelerle ilgili terim ve tanımlar bu belgenin 3. Bölümünde açıklanmıştır. Tüm incelemeler için gereken genel teknik kriterler Bölüm 4'te verilmektedir. Bölüm 5, her bir teknik incelemenin hazırlanmasında ve kapanışında atılabilecek süreç adımlarını kapsayan yüklenici ve sözleşme acenteleri arasındaki tipik çalışma ilişkilerini ve rolleri ve sorumlulukları açıklamaktadır. Bölüm 5'in içeriği, sözleşme yapan kurumlar arasındaki teknik incelemelerin yürütülmesi için planlama ve müzakereler için kaynak materyal olarak tasarlanmıştır. 1.1 Amaç Teknik gözden geçirmeler ve denetimler, bir program içindeki teknik ilerlemeyi, sözleşme gereksinimlerine ve gelişimsel olgunluğa göre değerlendirmek için gerçekleştirilen gerekli sistem mühendisliği (SE) faaliyetleridir. Program ilerlemesinin teknik incelemeleri, olay odaklı olacak ve geliştirilmekte olan sistem, Sistem Mühendisliği Planında (SEP) belgelenen inceleme giriş kriterlerini karşıladığında yürütülecektir. Teknik incelemeler ve denetimler, PKP'de belgelendiği şekilde PKP onay yetkilisi tarafından özellikle feragat edilmediği sürece, programdan bağımsız olan konu uzmanlarının katılımını (yani emsal değerlendirmesi) içerecektir. Teknik incelemeler, bir EI'nin gelişiminin çeşitli aşamalarında idealleştirilmiş bir EI için geliştirme ve tasarım çabalarındaki mantıksal geçiş noktalarında birincil ve ikincil olarak da adlandırılan yükleniciler ve taşeronlar tarafından yürütülür: 1. Yüklenicinin elde ettiği teknik ilerlemeyi belirlemek bugüne kadar 2. EI'lerin performansını gereksinimlerle karşılaştırın 3. Her bir EI'nin tasarım yürütmesinin önündeki potansiyel engelleri ve riskleri belirleyin 4. Program çizelgesi gecikmelerini ve planlanmamış kaynakları önlemek için azaltma planlarını belirleyin harcamalar. Sözleşme makamı, bu belgenin ilk uyarlamasını (IAW) uyarınca gerçekleştirecektir. Ek K MIL-STD-1521'i Uyarlamaya Yönelik Uygulama Kılavuzu, yalnızca her bir edinim için gerekenleri gerektirir ve edinim yaşam döngüsü içinde uygun program kapsamını, program boyutunu ve teknik ilerlemeyi ele alır. Burada tanımlanan Teknik Gözden Geçirme ve Denetimler, Sözleşme maddeleri, Çalışma Bildirimi (SOW), Uyum Standartları Listesi ve Devletin teknik veri ihtiyacına dayalı Sözleşme Veri Gereksinimleri Listesi'nde belirtilen ölçüde bu standarda uygun olarak yapılacaktır. edinme ve yaşam döngüsü destek stratejilerini desteklemek için gereklidir. Bu standardın uygulanmasına ilişkin rehberlik Bölüm 4 ve 5'te verilmektedir. Bu teknik incelemeler, geliştirme aşamasındaki son kalemin durumunun ve destekleyici belgelerin sözleşme gerekliliklerini ve beklentilerini uygun bir olgunluk düzeyiyle karşılayıp karşılamadığını değerlendirmek için prime ve subs ve sözleşme kurumu için bir yöntem ve forum sağlar. yönetilebilir risk ile programın bir sonraki aşaması. 1.2 Teknik İncelemelerin Amaçları DoDI 5000.02 Savunma Edinme Sisteminin İşletilmesi (Aralık 2008) talimatı, sözleşme yapan kurumun zamanında ve kritik öngörü, değerlendirme sağlayan araçlar, yöntemler ve forum sağlamak amacıyla teknik incelemeler ve denetimler (Tablo 1) planlamasını ve yürütmesini gerektirir. ve gelişen bir sistem tasarımı için yüklenicinin teknik ilerlemesinin değerlendirilmesi. Özellikle, şunlardan emin olun: 1. Teknik çabanın ürünü ve EI'si: 2/168 Machine Translated by Google A. Amaçlanan sistemin performans gereksinimlerini ve görev hedeflerini karşılayacaktır b. Güvenlik, çevre güvenliği ve iş sağlığı (ES&OH) ile uyumludur hedefler C. Üretilebilir, test edilebilir, konuşlandırılabilir, işletilebilir, desteklenebilir, bakımı yapılabilir ve güvenilirdir 2. Yüklenici(ler)in tasarım ve geliştirme süreci, artımlı, gerçekçi, sözleşmeden doğan teslimatlar için ölçülebilir ve ulaşılabilir kilometre taşları 3. Potansiyel sorunları veya başarısızlıkları, program kaynaklarıyla ilişkili riskleri (yani, maliyet, program ve teknik) ve bunların önlenmesini veya hafifletilmesini belirlemek için metodolojiler mevcuttur. Bu standart, yükleniciye/yüklenicilere, yüklenicinin beklentilerini ve amacını karşılayan bir teknik gözden geçirme süreci oluşturma ve sürdürme içeriği sağlar. 1.3 sınıflandırma Aşağıdaki teknik incelemeler ve denetimler, program geliştirmenin uygun aşamasında program yöneticisi tarafından seçilmelidir. Her gözden geçirme ve/veya denetim Ek A ila J'de tanımlanmıştır: SRR - Ek A Sistem Gereksinimleri İncelemesi SFR - Ek B Sistem İşlevsel İncelemesi SAR - Ek C Yazılım Gereksinimleri ve Mimari İncelemesi PDR - Ek D Ön Tasarım İncelemesi CDR - Ek E Kritik Tasarım İncelemesi TRR - Ek F Teste Hazırlık İncelemesi FCA - Ek G İşlevsel Yapılandırma Denetimi PCA - Ek H Fiziksel Yapılandırma Denetimi SVR - Ek I Sistem Doğrulama İncelemesi M/PRR - Ek J İmalat ve Üretime Hazırlık Gözden Geçirme Bölüm 4.0'da özetlenen jenerik teknik inceleme hedeflerine ulaşmak için, inceleme sürecini oluşturan prosedürler, planlama ve diğer tüm belgeler ve veriler tanımlanacak ve karşılıklı olarak inceleme, değerlendirme ve mutabakat için sözleşme makamına sunulacaktır. her EI incelemesinin yürütülmesinden önce üzerinde anlaşmaya varılan süre. Her incelemenin hazırlanması, yürütülmesi ve kabulüne yönelik roller ve sorumluluklar Bölüm 5'te daha ayrıntılı olarak açıklanmaktadır. 1.4 Başvuru Burada tanımlanan ve sözleşmeye dayalı anlaşmalarda çağrıldığı üzere sözleşme makamı tarafından belirlenen teknik incelemeler ve denetimler, sözleşme maddelerinde, Çalışma Bildiriminde (SOW) ve Sözleşme Veri Gereksinimleri Listesinde belirtilen ölçüde bu standarda uygun olarak yapılacaktır. (CDRL), program geliştirmenin uygun aşamalarında gerekli olan ilişkili teknik veri paketi (TDP) tipini, öğelerini ve veri yönetimi ürünlerini tanımlar. Bir EI teknik incelemesinin programlanması ve inceleme faaliyetlerinin gerçek zamanlaması, Bölüm 4 ve Ek K'de sağlanan edinme stratejisi ve uyarlama kılavuzu kullanılarak her program için uyarlanacaktır. 3/168 Machine Translated by Google Tablo 1. Belirli Teknik İnceleme ve Denetim Hedeflerine İlişkin Satın Alma Politikası Örnekleri Teknik İnceleme veya Denetim Alternatiflerin Analizi (AoA) Sistem Gereksinimlerini İnceleme (SRR) Sistem İşlevsel İncelemesi (SFR) Yazılım Gereksinimleri ve Mimari İnceleme (SAR) Ön Tasarım İncelemesi (PDR) Kritik Tasarım İncelemesi (CDR) Test Hazırlığı İncelemesi (TR) Amaç Konsept Seçimi, Sistem KONOPLARI SE Program Vakfı'nı inceleyin ve İlk Gereksinimlerin Onaylanması temel Sistemin İncelenmesi ve Onaylanması Mimari ve İşlevsel Gereksinimler Temeli Yazılımın İncelenmesi ve Onaylanması Mimari ve İşlevsel Gereksinimler Temeli (PCA) Üretim Hazırlığı teknoloji Gelişim teknoloji Gelişim teknoloji Gelişim Üretme Gelişim Mühendislik ve Tasarım Esasının Onayı Üretme Gelişim Yüklenicinin Doğrulanması Mühendislik ve Bir Resmi Başlatmaya Hazır Olma Üretme Doğrulama Testi Gelişim Tasarımın Niteliği (FCA) Fiziksel Yapılandırma Denetimi Malzeme Çözümü Analiz Mühendislik ve Tahsis Edilen Temelin Onayı İşlevsel Yapılandırma Denetim DoDI 5000.02 Aşaması Ürün Yapılandırmasının Onayı temel Üretime Hazırlık, Eğitim, Gözden geçirmek Dağıtım, İşlemler, Destek ve (MRR) İmha etmek Üretim ve dağıtım Üretim ve dağıtım Üretme, dağıtım, Operasyonlar ve Destek Devam Tedarikine Yetki Verilmesi Üretime Hazırlık İncelemesi (PRR) 1.5 Ek sistem EI'leri Üretme, dağıtım, Başlangıç Küçük Miktarını Tamamla / Operasyonlar ve Büyük Miktarda Üretim Odaklı Tedarik Destek Teknik İncelemelerin Planlanması Spesifik bir teknik incelemenin programlanması son derece önemlidir. Çok erken yapılırsa, inceleme için nihai öğe yeterince tanımlanmayacaktır. Tersine, gözden geçirme çok geç olursa, program taahhütleri hatalı bir şekilde verilmiş olabilir ve düzeltme hem zor hem de maliyetli olacaktır. Çizelgeleme ve planlama, program yönetimi işlevleridir ve uygun SE gereklilikleri sözleşmeli programın türüne uygun hale getirildikten sonra müzakere edilmiş Entegre Yönetim Planı (IMP) ve Entegre Ana Çizelgede (EYS) ayrıntılı olarak ele alınmalıdır, örneğin: a. Teknoloji Geliştirme ve/veya Teknoloji Gösterimi (TD) Sayfa 4 / 168 Machine Translated by Google B. Sistem Geliştirme ve Gösterim (SDD) c. Mühendislik Geliştirme (ED) d. Risk Azaltma ve Tasarım Geliştirme (RRDD), vb. İyi sistem mühendisliği ilkelerinin uygulanmasına uygun olarak, SRR ve SFR, gereksinimlerin belirlendiği ve gözden geçirilen sistemin alt öğelerine uygun şekilde tahsis edildiği "yukarıdan aşağıya" gözden geçirmeler olarak yürütülecektir. Tersine, PDR ve CDR, en alt unsurlardan başlayarak, genel bir sistem incelemesiyle sonuçlanan "aşağıdan yukarıya" gözden geçirmeler olarak yürütülecektir. SAR tipik olarak, ayrı bir Yazılım Yapılandırma Öğesi (SWCI) veya bir SWCI koleksiyonu için yapı bazında SFR'yi takip eder. Teknik gözden geçirmeleri planlamak için iyi bir yöntem, bunları dokümantasyon gereklilikleriyle ilişkilendirmektir; örneğin, PDR'nin özü yüklenicinin Bu belgelerin gerekliliklerini karşılama yaklaşımı. Teknik gözden geçirmelerin planlanması, yalnızca belgelerin mevcudiyetine değil, aynı zamanda donanım ve yazılım mevcudiyetine ve kabul yeterlilik testlerinin tamamlanmasına da bağlıdır. DoDI 5000.02 Savunma Tedarik Sisteminin Çalışması (08 Aralık 2008) talimatında incelemeler için bir zaman çerçevesi tanımlanmış olsa da, belirli bir program için inceleme tarihi değişebilir. Her bir EI incelemesinin başlangıç zamanlaması, uygun teklif sahipleri tarafından tekliflerinin veya IMP ve IMS'lerinin veya sistem mühendisliği yönetim planlarının (SEMP) bir parçası olarak sözleşme yapan kuruma sağlanacaktır. Sayfa 5 / 168 Machine Translated by Google Sayfa 6 / 168 Machine Translated by Google 2. Belgeler Şartnameler, standartlar, el kitapları, kılavuzlar, çizimler, CDRL'ler veya Veri Öğesi Açıklamaları (DID'ler) olsun, bu standartta adı geçen veya atıfta bulunulan belgeler, özellikle sözleşme Çalışma Bildirimi (SOW) tarafından belirtilmedikçe uygunluk belgeleri olarak kabul EDİLMEMELİDİR . veya tasarım incelemelerinin hazırlanması ve yürütülmesi için uygunluk belgeleri listesi. Uygulanabilir belgeler için SOW'a başvurulacaktır. (Belirli satın alma işlevleriyle bağlantılı olarak yükleniciler tarafından istenen şartnamelerin, standartların, çizimlerin ve yayınların kopyaları, sözleşmeyi yapan kurumdan veya sözleşme yetkilisinin talimatına göre alınmalıdır). Aşağıdaki belge listesi, bu belgenin hazırlanmasında kaynak materyal olarak kullanılmıştır. 1. AFR 66-14, Ekipman Bakım Politikaları, Hedefleri ve Sorumlulukları 2. AFSPC Kılavuzu 91-710 Range SW Safety STD (1 Mayıs 2004) 3. ANSI/EIA 649A Konfigürasyon Yönetimi için Ulusal Mutabakat Standardı (2006) 4. ASC/EN KILAVUZU – USAF Havacılık Sistemleri Merkezi Havacılık Silah Sistemi Edinimi için Teknik İncelemeler/ Denetimler (19 Temmuz 2006) 5. DoD 5000.4M Maliyet Analizi Kılavuzu ve Prosedürleri (Aralık 1992) 6. DoD Defence Acquisition Guidebook (14 Ekim 2004) 7. DoD-D-1000B - Çizimler, Mühendislik ve İlgili Listeler (28 Ekim 1977) 8. DoD Direktifi 5000.1 "Savunma Tedarik Sistemi" (13 Mayıs 2003) 9. DoDI 5000.02 “Savunma Tedarik Sisteminin Çalışması” (08 Aralık 2008) 10. DoD MIL-STD 498 Yazılım Geliştirme ve Dokümantasyon (Aralık 1994) 11. DoDAF v 1.0 DoD Architecture Framework (AF) Cilt 1 ve 2 (9 Şubat 2004) 12. DoDD 4630.5 “Bilgi Teknolojisi (BT) ve Ulusal Güvenlik Sistemlerinin (NSS) Birlikte Çalışabilirliği ve Desteklenebilirliği” (23 Nisan 2007) 13. DoD MIL-STD-1833 Uzay Araçlarını Destekleyen Kara Ekipmanı ve İlgili Bilgisayar Yazılımı İçin Test Gereksinimleri (13 Kasım 1989) 14. Satın Alma için DoD Risk Yönetimi Kılavuzu, Altıncı Baskı, v 1.0 (Ağu 2006) 15. Savunma Bakanlığı Sistemleri Mühendislik Planı (SEP) Hazırlama Kılavuzu Versiyon 1.02 (10 Şubat 2006) 16. Savunma Bakanlığı Teknoloji Hazırlık Değerlendirmesi (TRA) Masa Kitabı – DUSD(S&T) (Mayıs 2005) 17. IMP & IMS Hazırlama ve Kullanım Kılavuzu Versiyon 0.9 (21 Ekim 2005) 18. ISO/IEC STD 15939 Yazılım mühendisliği - Yazılım ölçüm süreci (11 Temmuz 2002) 19. Sistem Güvenliği için MIL-STD-882D DoD Standart Uygulaması (10 Şubat 2000) 20. MIL-STD-961E Savunma ve Programa Özgü Spesifikasyonlar Format ve İçerik (Ağu 2003) 21. MIL-STD-963B Veri Öğesi Açıklamaları (DID'ler) Uygulaması (31 Ağustos 1997) 22. MIL-STD-1472F DoD Design Criteria STD for Human Engineering (23 Ağustos 1999) 23. MIL-STD-1521B (USAF) Sistemler, Ekipmanlar ve Bilgisayar Yazılımı için Askeri Standart, Teknik İncelemeler ve Denetimler (4 Haziran 1985), Bildirimler 1 ve 2 dahil 24. MIL-DTL-31000C Ayrıntılı Spesifikasyon Teknik Veri Paketleri (9 Temmuz 2004) 25. SMC Systems Engineering Primer and Handbook, 2. Baskı (29 Nisan 2005) 26. SMCS-S-002 Yapılandırma Yönetimi (13 Haziran 2008) 27. Satın Alma Reformundan Beri Sistem ve Yazılım İncelemeleri, Güney Kaliforniya SPIN (2 Nisan 2004) 28. Sistem Mühendisliği Planı (SEP) Hazırlama Kılavuzu, v 1.02 (12 Şubat 2006) 29. TOR-2004(3909)-3537 Rev. B Uzay Sistemleri İçin Yazılım Geliştirme Standardı Sayfa 7 / 168 Machine Translated by Google 30. TOR-2006(8506)-5749, Yazılım için Görev Güvencesi Görevleri (30 Nisan 2007) Sayfa 8 / 168 Machine Translated by Google 3. Teknik Gözden Geçirme ve Denetimlerin Tanımları Bu bölümde tanımlanan terimler, bağlam detaylandırma, açıklama ve tutarlılık sağlayarak bu belgede yer alan diyalog ve söylemin anlaşılmasını artırmak için dahil edilmiştir. 3.1 Sistem Gereksinimleri İncelemesi (SRR) SRR, tüm sistem ve performans gereksinimlerinin İlk Yetenekler Belgesinden (ICD) veya taslak Yetenek Geliştirme Belgesinden (CDD) türetildiğini ve tanımlanmış ve maliyetle tutarlı olmasını sağlamak için yapılacak çok işlevli bir teknik inceleme veya bir dizi incelemedir ( program bütçesi), program (program çizelgesi), risk ve diğer sistem kısıtlamaları. SRR, sistem spesifikasyonunda belirtilen sistem gereksinimlerini değerlendirir ve sistem gereksinimleri ile tercih edilen sistem çözümü ve mevcut teknolojiler arasındaki tutarlılığı sağlar. SRR, genellikle, sorun çözümü ve süreç ve sonuçlar üzerinde yönetici düzeyinde uygun mutabakat için zaman tanımak amacıyla, Milestone B'den oldukça önce yapılır. SRR, programın başlatılmasından önce veya teknoloji geliştirme sırasında toplanabilir ve tipik olarak sistem fonksiyonel gereksinimlerinin önemli bir kısmı oluşturulduğunda, sistem geliştirme ve gösterim sırasında toplanır. 3.2 Sistem İşlevsel İncelemesi (SFR) SFR, incelenmekte olan sistemin ön tasarıma geçebilmesini ve Yetenek Geliştirme Belgesinden türetilen tüm sistem gereksinimlerinin ve işlevsel performans gereksinimlerinin tanımlanmış ve tutarlı olmasını sağlamak için gerçekleştirilecek çok disiplinli bir teknik inceleme veya bir dizi incelemedir. maliyet (program bütçesi), program (program çizelgesi), risk ve diğer sistem kısıtlamaları ile. Genel olarak bu gözden geçirme, sistem spesifikasyonlarında (işlevsel temel) yakalandığı şekliyle sistem işlevsel gereksinimlerini değerlendirir ve gerekli tüm sistem performansının tamamen ayrıştırılmasını ve işlevsel temelde tanımlanmasını sağlar. Sistem performansı, donanım ve yazılım gereksinimlerini tanımlayabilen alt düzey alt sistem işlevselliğine ayrıştırılabilir ve izlenebilir. SFR, sistemin fonksiyonel tanımının tamamen düşük bir seviyeye ayrıştırılıp ayrıştırılmadığını ve Entegre Ürün Ekibinin (IPT) ön tasarıma başlamak için hazır olup olmadığını belirler. SFR'nin tamamlanması şunları sağlayacaktır: 1. Yerleşik bir sistem işlevsel temel çizgisi 2. Sistem Geliştirme ve Gösterim aşaması için güncellenmiş bir risk değerlendirmesi 3. Maliyet Analizi Gereksinimleri Açıklaması (CARD) belgesini güncellemek için mevcut veriler; yüklenicinin önerilen sistem işlevsel temel çizgisinde 4. Sistem ve yazılım kritik yolunu içeren güncellenmiş bir program geliştirme çizelgesi sürücüler 5. Bu aşama için geçerli güncellemeleri olan onaylı bir SWCI SFR, sistemin alt düzey performans gereksinimlerinin tam olarak tanımlanıp tanımlanmadığını ve olgun sistem konseptiyle tutarlı olup olmadığını ve alt düzey sistem gereksinimlerinin üst düzey sistem performansına ve Yetenek Geliştirme Belgesine bağlı olup olmadığını belirler. Başarılı bir SFR, IPT'lerin sistem performans gereksinimlerinin, alt düzey performans gereksinimlerinin ve tasarım ve geliştirme planlarının ön tasarıma ilerlemek için tatmin edici bir temel oluşturduğunu belirlemesine bağlıdır. Program yöneticisi incelemeyi sistemin teknik kapsamına ve riskine göre uyarlamalı ve SFR'yi Sistem Mühendisliği Planında ele almalıdır. SFR, daha fazla teknik tasarım çalışması başlamadan önce sistemin güvenilir ve uygulanabilir olmasını sağlayan son gözden geçirmedir. Tipik SFR başarı kriterleri, aşağıdaki çıkış sorularına verilen olumlu yanıtları içerir: 1. Açıklandığı şekliyle sistem işlevsel gereksinimleri, Yetenek Geliştirmeyi karşılayabilir mi? Belge? Sayfa 9 / 168 Machine Translated by Google 2. Sistemin işlevsel gereksinimleri, sistemin etkinleştirilmesi için yeterince ayrıntılı ve anlaşılır mı? devam etmek için tasarım? 3. Programın başarılı olması için yeterli süreçler ve ölçümler mevcut mu? 4. Geliştirme için riskler biliniyor ve yönetilebilir mi? 5. Program çizelgesi yürütülebilir mi (teknik ve maliyet riskleri)? 6. Programda uygun personel bulunuyor mu? 7. Onaylanmış işlevsel temeli olan program mevcut bütçe dahilinde yürütülebilir mi? 8. Güncellenen Maliyet Analizi Gereksinimleri Tanımı, onaylanmış işlevsel temel ile tutarlı mı? 9. Güncellenen maliyet tahmini mevcut bütçeye uygun mu? 10. Ön tasarımın uygun yapılandırma yönetimiyle devam etmesini sağlamak için sistem İşlevsel Temeli oluşturuldu mu? 11. Onaylanan işlevsel temel çizgisindeki yazılım işlevselliği, güncellenen işlevsellik ile tutarlı mı? yazılım metrikleri ve kaynak yüklü program? 3.3 Yazılım Gereksinimi ve Mimari İncelemesi (SAR) Yazılım Gereksinimleri ve Mimari İncelemesi (SAR), yazılım gereksinimleri, mimari ve teknik ürünlerin test planlaması, yazılım geliştirme süreçleri ve tüm yazılım öğeleri için yazılım geliştirmenin mevcut durumuna ilişkin bir dizi çok disiplinli incelemeden oluşur. SAR, nihai hale getirilmiş Yazılım Öğesi (SI) gereksinimlerinin ve operasyonel konseptin bir incelemesidir. SAR, SI gereklilikleri, yüklenicinin sistem, alt sistem veya temel öğe seviyesindeki gerekliliklere yanıt verebilirliğini ve yorumunu değerlendirmek için yeterince tanımlandığında yürütülecektir. Başarılı bir SAR, sözleşme yapan kurumun Yazılım Gereksinimleri Spesifikasyonlarının, Arayüz Gereksinimleri Spesifikasyonlarının ve Yazılım Test Planı Operasyonel Konsept Belgesinin ön yazılım tasarım döngüsüne ilerlemek için tatmin edici bir temel oluşturduğunu belirlemesine bağlıdır. Ek SAR bilgileri için Ek C'ye bakın. Not: Yazılım Yapılandırma Öğesi (SWCI) ve yazılım öğesi (SI) aynı anlama sahiptir ve teknik camiada birbirinin yerine kullanılır. 3.4 Ön Tasarım İncelemesi (PDR) PDR, sistemin bir dizi multidisipliner PDR'sinin ve incelenmekte olan sistemin ayrıntılı tasarıma ilerleyebilmesini ve belirtilen performansı karşılayabilmesini sağlamak için yapılacak olan bireysel Yapılandırma Öğelerinin (CI'ler) bir dizi incelemesinin resmi sonucudur. maliyet (program bütçesi), program (program çizelgesi), risk ve diğer sistem kısıtlamaları dahilindeki gereksinimler. Tipik PDR sonuçları şunları içerir: 1. Sistem ön tasarımının, sistemdeki her yapılandırma öğesi, tahsis edilen temel (ABL) için performans belirtimlerinde ele alındığı ve fonksiyonel temeldeki (FBL) her bir işlevin bir veya daha fazla yapılandırma öğesi. Konfigürasyon öğeleri, donanım ve yazılım öğelerinden oluşacak ve uçak gövdeleri, aviyonikler, silahlar, mürettebat sistemleri, motorlar, eğitmenler ve eğitim vb. öğeleri içerecektir. 2. CI'lerin Donanım Konfigürasyon Öğesi (HWCI) geliştirme spesifikasyonunun performans ve mühendislik uzmanlığı gereksinimleri ile uyumluluğunun belirlenmesi 3. Tanımlama derecesinin değerlendirilmesi ve ilgili teknik riskin değerlendirilmesi seçilmiş üretim yöntemleri ve süreçleri 4. Konfigürasyon öğesi ile diğer ekipman, tesis, bilgisayar yazılımı ve personel öğeleri arasında fiziksel ve işlevsel arayüzlerin varlığının ve uyumluluğunun kurulması Sayfa 10 / 168 Machine Translated by Google 5. Seçilen üst düzey SWCI tasarımlarının ve test yaklaşımlarının ilerleme, tutarlılık ve teknik yeterliliğinin ölçümü 6. Yazılım gereksinimleri ile SWCI(lar) ön hazırlık arasındaki uyumluluğun değerlendirilmesi tasarım 7. PDR'nin SWCI(lar) operasyonunun ve desteğinin ön versiyonunu değerlendirmesi belgeler 3.5 Kritik Tasarım İncelemesi (CDR) CDR, ayrıntılı tasarım esas olarak tamamlandığında her bir yapılandırma öğesi için yürütülecek olan sistemin ve ayrı CI'ların bir dizi CDR'sinin çok disiplinli bir teknik incelemesidir ve amacı, her bir yapılandırma öğesinin ayrıntılı tasarımının incelenmekte olan sistemin ayrılmaz bir parçası, üretim, sistem entegrasyonu, gösterim ve test aşamalarında ilerleyebilir ve maliyet (program bütçesi), program (program çizelgesi) dahilinde konfigürasyon öğesi geliştirme spesifikasyonlarının belirtilen performans ve mühendislik uzmanlık gereksinimlerini karşılayabilir, risk ve diğer sistem kısıtlamaları. 1. CDR, konfigürasyon öğesi ile diğer ekipman, tesis, bilgisayar yazılımı ve personel öğeleri arasındaki ayrıntılı tasarım uyumluluğunu belirler. 2. CDR, yapılandırma öğesi risk alanlarını değerlendirir (teknik, maliyet ve zamanlama temelinde) 3. CDR, üretilebilirlik analizlerinin sonuçlarını değerlendirir 4. CDR, tasarım çözümünün ayrıntılı tasarımının, performans ve test özelliklerinin kabul edilebilirliğinin belirlenmesine ve operasyon ve destek belgelerinin yeterliliğine odaklanır. 5. CDR, sistemdeki her konfigürasyon öğesi (ürün temel çizgisi) için ürün spesifikasyonlarında yakalandığı şekliyle nihai sistem tasarımını değerlendirir ve ürün temel çizgisindeki her ürünün ayrıntılı tasarım belgelerinde, örneğin aşağıdakiler için ürün spesifikasyonlarında ele alındığından emin olur: A. Konfigürasyon öğelerinin fabrikasyonunu sağlamak ve üretimi dahil etmek için donanım çizimler B. Seçilen yaşam döngüsü model(ler)ine dayalı olarak Yazılım Geliştirme Planında (SDP) belirtilen ölçüde bir veya daha fazla Yazılım Konfigürasyon Öğesinin (SWCI) yazılımı (örn. yazılım mimarisi ve ayrıntılı tasarım belgeleri) 6. Karmaşık sistemler için, yüklenici her bir alt sistem veya konfigürasyon öğesi için bir CDR yürütebilir. Bu bireysel incelemeler, genel bir sistem CDR'sine yol açacaktır. Bireysel incelemeler yapıldığında, genel sistem CDR'sinin vurgusu, genel sistem ayrıntılı tasarım gerekliliklerinin yanı sıra konfigürasyon öğesi işlevsel ve fiziksel arayüz tasarımına odaklanmalıdır. 7. Sistem CDR'si, seçilen yaşam döngüsü model(ler)ine dayalı olarak donanım, insan ve yazılım nihai ayrıntılı tasarımlarının SDP'de belirtilen ölçüde tamamlanıp tamamlanmadığını ve yüklenicinin sistem fabrikasyonunu, demosunu başlatmaya hazır olup olmadığını belirler. ve test 3.6 Teste Hazırlık İncelemesi (TRR) Teste Hazırlık Gözden Geçirmesi (TRR), yüklenicinin bir nihai öğe (EI) için resmi bir doğrulama testi etkinliğine başlamaya hazır olduğunu doğrulamak için yürütülecek çok işlevli ve çok disiplinli bir inceleme ve süreç değerlendirmesidir. Test prosedürlerinin tamamlanıp tamamlanmadığını belirlemek ve yüklenicinin resmi EI testine hazır olduğundan emin olmak için her EI için yapılır. Test prosedürleri, ilgili test planlarına ve açıklamalarına uygunluk ve test gerekliliklerini yerine getirmedeki yeterlilik açısından değerlendirilir. TRR'de, sözleşme kurumu ayrıca geliştirme testinin sonuçlarını ve operasyon ve destek belgelerindeki güncellemeleri de inceler. Başarılı bir TRR, sözleşmeye bağlıdır Sayfa 11 / 168 Machine Translated by Google ajansın test prosedürlerinin, ortamın ve önceki test sonuçlarının resmi EI testine geçmek için tatmin edici bir temel oluşturduğuna dair kararlılığı. 3.7 İşlevsel Yapılandırma Denetimi (FCA) İşlevsel Konfigürasyon Denetimi (FCA), bir CI'nin fiili performansının, performans spesifikasyonunda belirtilen gereklilikleri karşıladığını doğrulamak ve CI'nın bu gereklilikleri karşıladığını tasdik etmek için periyodik olarak düzenlenmesi gereken bir doğrulama sürecidir. 1. FCA, sistemin gerçek performansının, sistem performans spesifikasyonunda belirtilen gereklilikleri karşıladığını doğrulamak için toplanır. Çok büyük, karmaşık CI'ler/sistemler için denetimler kademeli olarak gerçekleştirilebilir. Her bir artış, CI/sistemin belirli bir işlevsel alanını ele alacak ve bu artışın performans yeteneklerinde bulunan tüm tutarsızlıkları belgeleyecektir. 2. FCA, tamamlanan operasyon ve destek belgelerini de inceler 3. Bir konfigürasyon öğesinin geliştirilmesinin tatmin edici bir şekilde tamamlandığını ve konfigürasyon öğesinin, işlevsel veya tahsis edilen bölümde belirtilen performans ve işlevsel özelliklere ulaştığını doğrulamak için resmi bir FCA gerçekleştirilir. konfigürasyon tanımlama 4. Eksiksiz FCA'lar tarafından tanımlanan tüm eylem öğelerinin durumunu ele almak ve bunların tamamlandığını belgelemek ve tasdik etmek için özet bir FCA toplanabilir. 3.8 Fiziksel Yapılandırma Denetimi (PCA) PCA, "Yapıldığı Gibi" konfigürasyon öğesinin üretilmekte olan bir öğenin gerçek konfigürasyonunu tanımlayan teknik belgelere uygun olduğunu doğrulamak için gerçekleştirilecek, belirlenmiş bir konfigürasyon öğesinin teknik incelemesidir. 1. PCA, tasarım belgelerinin sözleşmede belirtilen EI ile eşleştiğini doğrular. 2. PCA, üretim süreçlerinin, kalite kontrol sisteminin, ölçüm ve test ekipmanının ve eğitimin yeterince planlandığını, izlendiğini ve kontrol edildiğini onaylar. PCA ayrıca, yüklenici tarafından öğenin üretiminde kullanılan destekleyici süreçlerin birçoğunu doğrular ve öğenin, Sistem Doğrulama İncelemesi (SVR) tamamlandıktan sonra etkilenmiş veya yeniden tasarlanmış olabilecek diğer öğelerini doğrular. 3. PCA, tam oranlı üretim kararından önce veya Hükümet, Teknik Veri Paketi aracılığıyla elde ettiği öğenin ayrıntılı tasarımını kontrol etmeyi planladığında toplanır. Hükümet bu tür bir kontrolü uygulamayı veya öğenin Teknik Veri Paketini (örneğin, performansa dayalı satın alma) satın almayı planlamadığında, yüklenici, öğenin ayrıntılı tasarımını kontrol etmek ve bir ürün oluşturmak için başlangıç noktasını tanımlamak üzere dahili bir PCA yürütecektir. taban çizgisi 4. Tasarım ve üretim belgeleri eşleştiğinde PCA'nın tamamlanmış olduğu kabul edilir. sözleşmede belirtilen öğe Sayfa 12 / 168 Machine Translated by Google 3.9 Sistem Doğrulama İncelemesi (SVR) SVR, sistemi oluşturan bir grup konfigürasyon öğesinin sözleşmeye dayalı belirli performans gerekliliklerini (şartnameler veya eşdeğeri) karşıladığının doğrulanacağı bir test, inceleme veya analitik süreçtir. Bu gözden geçirme, bireysel yapılandırma öğesi için FCA'da doğrulanan donanım veya yazılım gereksinimleri için geçerli değildir. 3.10 Üretime Hazırlık İncelemesi (MRR) MRR'ler, ana yüklenici tarafından, incelenmekte olan programa uygun olarak, arzu edilen bir savunma yüklenicisinin savunmaya özgü ve/veya savunma açısından kritik üretim özelliklerini bünyesinde barındıran kaliteli bir ürünün üretimine başlamadan önce, inşa etmeye hazır olunmasını sağlamak için yürütülecektir. ana yüklenici, alt yüklenici veya kritik bileşen tedarikçisi tarafından bir birim veya sözleşmeyle belirlenmiş diğer konfigürasyon öğeleri. 3.11 Üretime Hazırlık İncelemesi (PRR) PRR'ler, üretim risklerinin ve yüklenicinin bu riskleri yönetme metodolojisinin değerlendirilmesinde ve yüklenicinin, onların alt yüklenicilerinin ve tedarikçilerinin PRR'lerin bulgularını ve belirli hususları Hükümeti tatmin edecek şekilde çözüp çözmediğinin belirlenmesinde Hükümete yardımcı olmak için yürütülecektir. Üretime devam etme kararını uygulamadan önceki eylemler. 1. PRR'ler, üretime devam etme kararının uygulanmasındaki riski değerlendirmek için Tam Ölçekli Geliştirme aşaması (genellikle iki ilk inceleme ve bir son inceleme) sırasında artımlı bir şekilde gerçekleştirilir. PRR, ilk aşamalarında, yüksek riskli ve düşük verimli imalat süreçlerini veya malzemelerini belirleme ihtiyacı veya tasarım gereksinimlerini karşılamak için imalat geliştirme çabası gerekliliği gibi brüt üretim kaygılarıyla ilgilenir. Gözden geçirmeler, tasarım olgunlaştıkça, yeterli üretim planlaması, tesis tahsisi, üretilebilirlik odaklı değişikliklerin dahil edilmesi, aletlerin ve test ekipmanlarının tanımlanması ve imalatı, uzun vadeli öğe edinimi vb. gibi kaygılarla ilgilenerek daha rafine hale gelir. 2. PRR riski inceler; üretim veya üretim hazırlıklarının program eşiklerini, performansı, maliyeti veya diğer yerleşik kriterleri ihlal edebilecek kabul edilemez risklere maruz kalıp kalmadığını belirler. 3. PRR, doğru olup olmadığını belirlemek için tam, üretim tarafından yapılandırılmış sistemi değerlendirir ve tüm sistem gereksinimlerini tamamen uygular 4. PRR, nihai sistem gereksinimlerinin izlenebilirliğinin nihai sistem gereksinimlerine uygun olup olmadığını belirler. üretim sistemi korunur 5. Artımlı PRR'lerin zamanlaması, program duruşunun bir fonksiyonudur ve özel olarak belirlenmemiştir. diğer incelemelere kilitlendi Sayfa 13 / 168 Machine Translated by Google Sayfa 14 / 168 Machine Translated by Google 4. Teknik İnceleme Hedefleri Teknik incelemeler, planlanan teknik ve/veya sözleşme hedeflerine göre bir projedeki ilerlemeyi değerlendirmek için tasarlanmış gerekli sistem mühendisliği faaliyetleridir. Bu incelemeler: 1. Program tanımından EI geliştirmesine kadar sözleşme yapan kurum ve Devlet (aynı zamanda birbirinin yerine "sözleşme yapan kurum" olarak da anılır) için bir teknik inceleme kılavuzu olarak hizmet edin 2. Programın durumunu ve sonraki aşamalara kabul edilebilir bir riskle ilerlemeye hazır olup olmadığını değerlendirmek için geliştirme çabasındaki mantıksal geçiş noktalarında teknik incelemelerin yapıldığından emin olun 3. Teknik incelemelerin, program ekiplerine bugüne kadar kaydedilen ilerlemeyi belirleme, gereksinimlere göre öngörülen veya fiili performansı değerlendirme, potansiyel sorunları ve riskleri belirleme ve program gecikmelerini ve maliyet artışını önlemek için hafifletme planlarına olan ihtiyacı belirleme konusunda bir yöntem sağladığından emin ol. programı 4. Teknik incelemelerin, teknik ilerleme konusunda yüklenici ve sözleşme acentesinin mutabakatını kolaylaştırdığından ve karşılıklı olarak üzerinde anlaşmaya varılan bir dizi kritere göre başarılı bir incelemenin sağlanmasına yardımcı olduğundan emin ol 5. Her inceleme için tanımlanan teknik inceleme kriterlerinin adaya dayalı olduğundan emin olun Bölüm 6'da tanımlanan kriterler 6. Her gözden geçirme sırasında, tüm kriter öğelerinin programın teknik gereksinimlerine ve bunların program maliyeti ve programa ilişkin etkilerine göre gözden geçirileceğini garanti et Nihai öğe geliştirme çabasını yürütmek ve bu gözden geçirmeleri desteklemek için yüklenicinin ve alt yüklenicinin tesislerinde zaten mevcut olan mevcut yetenekleri ve kaynakları mümkün olan en üst düzeyde dikkate almak için program hedefleri ve kaynakları Bu hedefler işletmenin tüm seviyelerinde (örneğin, ana yüklenici, alt yüklenici ve bayi seviyeleri) uygulanabilir. Gözden geçirme ve denetimlere devlet müşterisinin katılımı, belirli programın ihtiyaçlarına göre değişiklik gösterecektir. 4.1 Belirtilen İncelemeler Aşağıdaki incelemeler ve denetimler yapılacaktır: SRR - Ek A Sistem Gereksinimleri İncelemesi SFR - Ek B Sistem İşlevsel İncelemesi SAR - Ek C Yazılım Gereksinimleri ve Mimari İncelemesi PDR - Ek D Ön Tasarım İncelemesi CDR - Ek E Kritik Tasarım İncelemesi TRR - Ek F Teste Hazırlık İncelemesi FCA - Ek G İşlevsel Konfigürasyon Denetimi PCA - Ek H Fiziksel Konfigürasyon Denetimi SVR - Ek I Sistem Doğrulama İncelemesi M/PRR - Ek J İmalat ve Üretime Hazırlık İncelemesi 4.2 Teknik İnceleme Kriterleri Tüm gözden geçirmeler için Teknik Gözden Geçirme Kriterleri (TRC), programın teknik olarak plana göre ilerlediğini ve bir sonraki aşamaya veya olaya geçmeye hazır olduğunu göstermek için gerekli tüm öğelerden oluşmalıdır. Şekil 1, Yüklenici memurunun temsilcisi ile Yüklenici, Taşeron ve EI geliştiricisi arasında ortak bir faaliyet olarak yürütülecek inceleme sürecinin genel akışını göstermektedir. Sayfa 15 / 168 Machine Translated by Google Yüklenicinin teknik incelemelerde sağlaması gereken TRC'lerin listesi bunlarla sınırlı olmamak üzere şunları içerecektir ile: 1. Yüklenici tarafından planlandığını gösteren ölçülebilir ölçümlerin ve başarıların bir listesi yapılan inceleme için ilerleme ve gelişimsel olgunluk 2. Kritik yolda olan tüm öğeler veya sorunlar için risk değerlendirmeleri, örneğin: a. "İleriye gitme" kararını engelleyecek yüksek riskli öğeler yok B. Sunulacak herhangi bir yüksek riskli öğeye uygun bir azaltma eşlik etmelidir plan 3. Performansı gösteren, birikmiş ve incelemeye hazır veriler 4. Eksiksiz, yürütülebilir ve tamamen desteklenebilir olan kilit kararlar 5. Her bir inceleme veya denetim olayı 6. Sözleşmeyle tanımlandığı şekliyle ilgili olaylara veya kalemlere karşılık gelen unsurlar, birleştirilmiş, veya genişletilmiş, yani: a. Programın Entegre Ana Planı (IMP) ve Entegre Ana Çizelgesi (EYS) B. Hedefler Bildirimi veya Çalışma Bildirimi (SOW) c. İhtiyaç Tahsis Belgesi (RAD) 7. Önceki teknik incelemelerden alınan eylem öğeleri tamamlanır ve kapatılır. TRC listesi, incelemelerin bir hazır olma kararlılığıyla veya ilerlemeye hazır olma durumuna ulaşmak için doğrudan bir planla sonuçlanmasını sağlamak için hazırlanır. Bu itibarla, incelemeye giriş için yeterlilik, tüm ölçüt öğelerinin belirli bir inceleme aşaması için yerine getirildiği veya yeterince ele alındığı ve sunum ve değerlendirme için tamamen hazır olduğu anlamına gelir. 4.3 Teknik İnceleme Başarısı Teknik gözden geçirme başarısı, tüm kriter unsurlarının yüklenici tarafından, karşılıklı olarak üzerinde anlaşmaya varılan bir "Kabul Kriterleri" setine göre sözleşmeyi yapan kurumu tatmin edecek şekilde gösterildiğinde elde edilir: 2. Her son durumu belirli bir gereklilik(ler) ile ilişkilendirme 3. Sonu doğrulamak ve doğrulamak için kullanılan ölçüm veya metriklerin esasını tanımlama kriter maddesinin durumu yeterince karşılandı "Kabul Kriterleri", başarının nesnel kanıtıdır ve gerçekleştiğinde, seçilen tasarım çözümünün ve yüklenici tarafından her bir tasarım gözden geçirme kilometre taşına atanan tamamlama kriterleri öğelerinin: 1. Tüm teknik gereksinimlere göre izlenebilir 2. Sistem mimarisine uygun 3. Gerçekçi ve fiziksel olarak üretilebilir bir EI tasarımında sentezlenebilir 4. Kullanıcının operasyonel ihtiyaçlarını makul bir maliyet karşılığında karşılamak için uygulanabilir ve kabul edilebilir risk 5. Aşağıdaki özelliklere sahip teknik ilerlemenin değerlendirilmesi için gözden geçirme kriterlerine sahip olun: A. İlgili satın alma stratejisini yansıtacak şekilde uygun şekilde uyarlanmıştır B. Her biri için kendine özgü veya benzersiz olan ana risk faktörlerini yansıtacak şekilde uygun şekilde uyarlanmıştır. programı C. İlerlemenin belgelenmiş kanıtlarının hazırlanmasına izin ver Sayfa 16 / 168 Machine Translated by Google D. Bir sonraki tasarım olgunluğu seviyesi için programın yürütülmesine devam etmek için hazır olma durumu hakkında bilgilendirilmiş bir muhakeme ve sözleşme yapan kurumun onayına izin vermek için yeterlidir. Herhangi bir gelişimsel DoD programına özgü olan "Kabul Kriterleri" için genel rehberlik, SRR, SFR, SAR, PDR ve CDR'ye özgü Ek A'dan E'ye kadar sağlanmaktadır. Sayfa 17 / 168 Machine Translated by Google DEVLET VE DESTEK KURULUŞLARI ANA / ALT YÜKLENİCİ(ler) Gerekli incelemelerin Teknik İncelemeleri Gerçekleştirmek için Sözleşmeye Dayalı RQM'ler Oluşturun sayısı, sıklığı ve Teknik İnceleme Sağlayın Başlangıç Talimatlar, Standartlar, Rehberlik türleri, satın alma kurumu tarafından görüşülür ve uyarlanır İnceleme Kriterlerini Belirleyin Ödül Sonrası KPT, Yükleniciler ve Diğer Paydaşları ve Bunların Belirlenmesi Destek İncelemesine İlişkin Sorumluluklar İnceleme Gerçekleştirmek için Katılımcı Taahhütleri Oluşturun mi Gözden Geçirme Hazırlık Değerlendirmesini Gerçekleştirin Müteahhit Hazır? HAYIR Sorunları Çözme ve Bağlantı Kesilmeleri Evet Teknik İnceleme Gerçekleştirme Teknik Riskleri ve Eksiklikleri Belirleyin -061128-043_ AFD Uzaya Garantili Erişim, Cilt. 3 No. 1_Kasım 2006 DoDD 5000.1 DoDI ve 5000.02 Savunma Tedarik Sisteminin Çalışması 63-101_Operasyon AFI Tabanlı Entegrasyon Yetenekler Geliştirme ve Sistemi DOD Edinimi için Risk Kılavuzu, Yönetimi Baskı, Altıncı 1.0 V (Ağu 2006) Eylem Öğelerini ve Kapanış Planlarını Belgeleyin HAYIR - Gerektiğinde Teknik İnceleme Desteği Sağlayın Evet Kaynak Kılavuzu: Son Efsane Ortak Çaba Şekil 1. Genel Teknik İnceleme Süreç Haritası. Sayfa 18 / 168 - Sonraki Gözden Geçirme Planlarını Hazırlayın ve Belgelendirin - Sonuçlar? - Kabul etmek Gözden geçirmek Takip İncelemesi Gerçekleştirin ZAMAN Machine Translated by Google 5. Roller, Sorumluluklar ve Yetki Bu bölüm, yüklenici(ler) ile ihale makamı arasındaki tipik rolleri, sorumlulukları ve karar yetkisi ilişkilerini açıklamaktadır. Teknik inceleme planlama ve yürütme sorumluluğu, sözleşmeyi yapan kurum veya Satın Alma Sözleşme Görevlisi (PCO) ve yüklenici veya yüklenicinin program yöneticisi tarafından eşit olarak paylaşılır. 5.1 Yüklenici Katılımı ve Sorumlulukları Yüklenici, Sözleşme ile değiştirilenler dışında, Teknik Gözden Geçirme ve Denetimlerin aşağıdaki gerekliliklere uygun olarak yürütülmesinden sorumlu olacaktır. 5.1.1 Alt Yükleniciler ve Tedarikçiler Alt yüklenicilerin, satıcıların ve tedarikçilerin uygun şekilde resmi incelemelere ve/veya denetimlere katılmasını sağlamaktan yüklenici sorumlu olacaktır. 5.1.2 Başkan Teknik inceleme başkanı, yüklenicinin program yöneticisi veya onun atadığı kişi olacaktır. Başkan, toplantı gündeminin yayınlanmasından, toplantı tutanaklarının kaydedilip yayınlanmasından, katılanların listesinin tutulmasından, toplantı yeri seçimi ve koordinasyonundan ve her bir teknik inceleme ile ilgili tüm idari konulardan sorumludur. 5.1.3 Yüklenici Gereksinimleri Yüklenici, Teknik Gözden Geçirme ve Denetimlerin aşağıdaki gereksinimlere uygun olarak yürütülmesinden sorumlu olacaktır. Yükleniciler, sözleşmeyi yapan kurumla koordinasyona tabi olarak, ana kilometre taşı programıyla uyumlu olarak her Gözden Geçirme ve Denetim için zaman, yer ve gündemi belirlemekten sorumlu olacaktır. Bu, hem yüklenici hem de ihale makamı tarafından toplantı için yeterli hazırlığa izin verecek şekilde, her inceleme ve/veya denetimden yeterince önce gerçekleştirilecektir. 5.1.3.1 İnceleme, Denetim Programları ve Mevcut Bilgiler Yükleniciler, her Gözden Geçirme ve Denetim planının gerekli bilgilerin ve sözleşme maddelerinin mevcudiyeti ile uyumlu olmasını sağlayacaktır, örneğin sistem mühendisliği verileri, ticari çalışma sonuçları, üretilebilirlik analizi sonuçları, risk analizi sonuçları, spesifikasyonlar, kılavuzlar, çizimler, raporlar, donanım , yazılım veya maketler. 5.1.3.2 Gözden Geçirme ve Denetim Hazırlığı Yükleniciler, her Gözden Geçirme ve Denetim için, Gözden Geçirme ve Denetimin kapsamı ve büyüklüğü ile tutarlı yeterli ayrıntıda hazırlık yapacaklardır. 5.1.3.3 Gözden Geçirme ve Denetim Yürütmesi Yükleniciler, her Gözden Geçirme ve Denetim için bir eş başkan belirleyecektir. Katılımcı yüklenici ve taşeron personeli veya sunum yapmak üzere seçilen kişiler, inceleme kapsamında sunulan materyalleri teknik detaylarıyla tartışmaya hazır olacaktır. Özellikle, yüklenicinin eşbaşkanı veya onun ve onun atadığı kişi aşağıdakilerden sorumlu olacaktır: 1. Her gözden geçirmenin planlanması, organizasyonu, koordinasyonu ve sunumu 2. Gözden geçirmelerde yükleniciyi temsil eden ve adına hareket eden kişilerin listesinin hazırlanması ve onaylanması 3. PCO tarafından incelenmek ve onaylanmak üzere kullanılacak “Kabul Kriterleri”nin hazırlanması A. Yüklenici program yöneticisi, incelemeyi başlatmak için tavsiye edilen ve üzerinde karşılıklı olarak mutabakata varılan “Kabul Kriterlerinin” gösterilebileceğini garanti etmelidir. B. Yüklenici, her bir gözden geçirme için, projenin kapsamı ve büyüklüğü ile tutarlı, başarıların nesnel kanıtı olarak yeterli ayrıntıda destekleyici veriler hazırlayacaktır. Sayfa 19 / 168 Machine Translated by Google aşağıdaki beş ana kategori altında karşılıklı olarak mutabık kalınan “Kabul Kriterleri”ne göre gözden geçirin: (1) Sistem Mühendisliği ve Mimari Geliştirme (2) Sistem, Segment ve Alt Sistem Tasarımı (3) Sistem Doğrulama ve Doğrulama (4) Mühendislik Disiplinleri ve Uzmanlık Mühendisliği (5) Entegre Teknik Risk ve Azaltma 4. Kabulün ilgili tüm alanlarındaki başarıların nesnel kanıtlarının sunulmasını sağlamak için taşeronların, satıcıların ve tedarikçilerin uygun şekilde katılımı. Kabul Kriterleri”, PKP'de belgelendiği şekliyle. Teknik gözden geçirmeler, PKP'de belgelendiği şekilde ve PKP onay yetkilisi tarafından özel olarak feragat edilmediği ve program IMP ve IMS ile mutabakata varılmadığı sürece, programdan bağımsız olan konu uzmanlarının katılımını içerecektir (yani emsal değerlendirmesi). müteahhitlik kurumu Bu, hem yüklenici hem de ihale makamı tarafından inceleme için "Kabul Kriterleri"nin geliştirilmesine ve toplantı için yeterli hazırlık süresine izin verecek şekilde yeterince önceden gerçekleştirilmelidir. 6. Her gözden geçirme planının gerekli incelemelerin mevcudiyeti ile uyumlu olduğunun belirlenmesi bilgi ve sözleşme maddeleri 7. İncelemeyi etkili bir şekilde gerçekleştirmek için gerekli kaynakları ve materyalleri sağlamak. Bu, uygun olduğu ölçüde ve sözleşmenin gerektirdiği inceleme türü ve kapsamına göre uyarlanabilir, örneğin: a. Toplantı gündemi ve planları b. konferans odası(lar) C. Uygulanabilir sistem mühendisliği verileri, örneğin, spesifikasyonlar, çizimler, kılavuzlar, raporlar, çizelgeler, tasarım ve test yöntemleri ve verileri, risk analizi ve uzmanlık çalışması ve ticari çalışma sonuçları D. Mimari ürünler, sistem arayüzleri, geçerli standartların listesi, üretilebilirlik analiz sonuçları, donanım, yazılım ve maketler e. Sistem Doğrulama Çapraz Referans Matrisi (VCRM) f. Önceki teknik inceleme eylem öğeleri vb. G. Gözden geçirme eylem öğelerini yakalamak, kaydetmek, izlemek ve düzenlemek için bir sistem (AI'ler 8. Her inceleme için bir başkan atama. Bu kişi toplantı gündemini yayınlamaktan, toplantı tutanaklarını kaydetmekten, birleştirmekten ve yayınlamaktan, katılımcıların bir listesini tutmaktan sorumludur. , toplantı yeri seçimi ve koordinasyonu ve tüm idari öğeler 5.1.3.4 Toplantı Tutanakları Eşbaşkan, girdileri resmi toplantı tutanaklarına kaydetmek için kabul edilebilir bir yöntem sağlayacaktır, örneğin: 1. Tutanaklar, başkan tarafından dikte edildiği şekilde kaydedilmeli ve asgari olarak önemli soru ve yanıtları, eylem maddelerini, sapmaları, sonuçları, sunumlardan veya tartışmalardan kaynaklanan önerilen eylem planlarını vb. içermelidir. 2. Ana başlıkta özetlenen yan toplantılarda yapılan tartışmalardan elde edilen sonuçlar toplantı ve uygun yorumlar resmi tutanaklara okunur 3. Kabul edilmeyen tavsiyeler, kabul edilmeme gerekçesi ile birlikte kaydedilir 4. Hem yüklenici hem de yüklenici tarafından günlük olarak özetlenen her günlük oturumun eylem maddeleri ajans personeli her günün oturumunun sonunda Sayfa 20 / 168 Machine Translated by Google 5.1.3.5 Tutanakların İncelenmesi ve Eylemin Belirlenmesi Kararlaştırılan çözüm ve düzenleme için ihale makamının mı yoksa yüklenici eyleminin mi (veya her ikisinin birden) gerekli olup olmadığını belirleyerek, tüm eylem kalemleri teknik inceleme tutanaklarına kaydedilecektir. Tutanaklar, tartışmaların bir kaydını ve reddedilen eylemler için gerekçeyi içerecektir, örneğin, kapsamın dışında, başka bir yerde ele alınmış (yere atıfta bulunarak), XYZ eyleminin kopyası, vb. Örnek bir eylem öğesi formu Tablo 2'de verilmiştir. 5.1.3.6 Dakika Yayını Resmi tutanakların yayınlanmasından ve dağıtılmasından yüklenici sorumludur. 5.2 Satın Alma Sözleşme Görevlisi (PCO) Katılımı ve Sorumluluğu 5.2.1 Satın Alma Sözleşme Görevlisi (PCO) Rolü Satın Alma Sözleşme Görevlisi (PCO) veya onun ve atadığı kişi, her İnceleme ve Denetimin eş başkanıdır. Eşbaşkan, ihale acentesi ile yüklenici arasında tek irtibat noktası olarak hareket eder ve toplantı gündeminin ve toplantı tutanaklarının onaylanmasından sorumludur. Eşbaşkan ayrıca aşağıdakilerden sorumludur: 1. "İnceleme Ekibi" (inceleme yetkilisi) üyelik seçimi, yani: A. "İnceleme Ekibi", bu STD'de listelenen her incelemenin tamamını veya bir kısmını gerçekleştirmek için uygun gruplar oluşturabilir. B. Bu grupların organizasyonu, program yöneticisinin ve/veya inceleme makamının takdirindedir c. İnceleme makamının üyeliği, gerektiğinde satın alma faaliyetini, faaliyet teknik liderliğini, yüklenici üst yönetimini, kullanıcı topluluğunu ve dış kurumlardan konu uzmanlarını içerebilir. 2. Gözden geçirme programı, yeri, gündemi, taslağı ve içeriği, katılımcı davet listesinin onaylanması 3. Karşılıklı (sözleşme acentesi ve yüklenici) üzerinde anlaşmaya varılan kriterlere göre yüklenicinin başarısının ve ilerlemesinin değerlendirilmesi ve derecelendirilmesi için ölçülebilir metriklerin hazırlanması 4. Gözden geçirme değerlendirmesini ve derecelendirmesini hazırlamak ve karara devam etmek için yetki vermek 5. Aşağıdakileri sağlamak için eylem öğelerinin (AI'ler) günlük incelemesini ve onayını hazırlamak: A. AI'lar, AI formunda belgelenir (Tablo 2) b. Eylem maddeleri, tüm önemli sözleşme kurumu girdilerini yansıtır C. Eylem öğeleri uygun şekilde oluşturulmuştur d. Önem ve zaman açısından kritik hususlar değerlendirilir e. Üst düzey eylem planı tanımlanır ve üzerinde anlaşmaya varılır f. Sorumlu vekil belirlenir g. Kapanış tarihleri belirlenir ve üzerinde anlaşmaya varılır 5.2.2 Gözden Geçirme Paneli ve Katılımcı Seçimi Eşbaşkan, inceleme panelinin ve katılımcı bireylerin adlarının, kuruluşlarının ve doğrulanmış güvenlik izinlerinin bir listesini hazırlayacak, onaylayacak ve önceden yükleniciye sağlayacaktır. her inceleme. Sayfa 21 / 168 Machine Translated by Google Tablo 2. Örnek Eylem Madde Formu AI KONTROL NUMARASI: PROGRAM ADI: _________________ _________________________ DÜZENLEME TARİHİ:_____________________________ Oluşturanın Adı ve Kuruluşu: EYLEM AÇIKLAMASI ve TANIMI: _________________________________________________________________________________________________ _________________________________________________________________________________________________ _____________________________________________________________ GÖREVLİ: _______________________________ __________________________ YÜKLENİCİNİN ORGANI ve IPT: KATEGORİ (onay): SORUN __, KAYGI__ KRİTİK SINIF (kontrol edin): 1__, 2__ veya 3__ GÜVENLİK SINIFLANDIRMASI (kontrol edin): U__, C__, S__, TS__ _______________________________________________________________________________ KRİTİK AÇIKLAMA: ____________________________________________________________________________ _______________________________________________________________________________ BAĞIMLILIK (P000 veya WBS): A -__________________________________________________________________________ B -__________________________________________________________________________ C- ___________________________________________________________________________ Askıya Alma Tarihi:____________ İHTİYAÇ TARİHİ: _________________ DURUM (kontrol): İPTAL EDİLDİ__, AÇIK__, KAPALI__, BEKLEMEDE__, YENİDEN ATANDI veya İLE BİRLEŞTİRİLDİ Al: _____________________ AI ÇÖZÜMÜ ve KAPATMA (OBJEKTİF DELİL – VERİ, RAPOR, VB.): ____________________________________________________________________________________ REDDİN GEREKÇESİ: _______________________________________________________ TAMAMLAMA TARİHİ: GÖREVLİ İMZASI: TEKNİK ONAY (ŞEF MÜHENDİSLİK) TEKNİK ONAY (DPT) ___________________ _____________________ ___________________ _____________________ İMZA TARİHİ SÖZLEŞME NO. İMZA TARİHİ TEKNİK İNCELEME (daire): SRR / SFR / SAR / PDR / CDR Sayfa 22 / 168 DURUM TARİHİ: Machine Translated by Google 5.3 Resmi Onay Bu standart, Sistemler, Ekipmanlar ve Bilgisayar Yazılımları üzerinde Teknik Gözden Geçirmeler ve Denetimler yapmak için gereksinimleri belirler. Bir Gözden Geçirme ve Denetimin tamamlandığının sözleşme makamı tarafından resmi olarak kabul edilmesi, tutanaklarda yapılan açıklamaların veya Gözden Geçirme ve Denetimde tartışılan konuların onaylandığı şeklinde yorumlanmamalıdır ve yükleniciyi Sözleşmenin bir parçası olan gerekliliklerden muaf tutmaz. sözleşme. Tedarik Sözleşme Görevlisi (PCO), inceleme tutanaklarının alınmasından ve AI'ların elden çıkarılmasından sonra yükleniciye her incelemenin tamamlandığının resmi bir teyidini sağlar. Sözleşme veren kurum, yüklenicinin inceleme performansının yeterliliğini aşağıdakileri bildirerek tespit eder: 1. Onay: incelemenin tatmin edici bir şekilde tamamlandığını belirtmek için 2. Koşullu onay: devam etmek için PCO incelemesi, müzakeresi ve onayı için yüklenici tarafından bir hafifletme planının/planlarının sunulmasını gerektirebilecek sonuçtaki eylem öğelerinin tatmin edici bir şekilde tamamlanmasına kadar incelemenin tamamlanmış sayılmadığını belirtmek için , veya 3. Onaylanmama: incelemenin ciddi şekilde yetersiz olduğunu belirtmek 5.4 için Veri Gereksinimleri Listesi ve Çapraz Referans Bu standart, bir DD Form 1423, Sözleşme Veri Gereksinimleri Listesini (CDRL) içeren bir satın almada kullanıldığında, aşağıda tanımlanan veri gereksinimleri, onaylı bir Veri Öğesi Açıklamasında (DD Form 1664) belirtildiği şekilde geliştirilecek ve sözleşmeye dahil edilmiş onaylı CDRL. Veri gerekliliklerine ilişkin DoD FAR maddesi hükümleri (şu anda DoD FAR Eki 52.227-7031) uygulandığında ve DD Form 1423 kullanılmadığında, aşağıda belirtilen veriler, sözleşme veya satın alma emri gerekliliklerine uygun olarak yüklenici tarafından teslim edilecektir. . Bu standardın gerektirdiği teslim edilebilir veriler aşağıdaki paragraflarda belirtilmiştir. Paragraf No. 5.1.2 5.1.3.4 Veri Gereksinimi Başlığı Geçerli DID No. Konferans Gündemi DI-ADMN-81249A Konferans Tutanakları DI-ADMN-81250A Güncel DID'ler ve MIL-STD'ler Web'de şu adreste bulunabilir: http://assist.daps.dla.mil/quicksearch/ Sayfa 23 / 168 Machine Translated by Google Sayfa 24 / 168 Machine Translated by Google 6. İlgili Teknik İnceleme ve Denetim Öğeleri 6.1 Kaynak Otorite ve Materyal Belirli incelemeleri tanımlayan kaynak otoritesi veya materyali ve bunları EI edinimlerine uygunluk için yürütmek için gereken kaynaklar, doğrudan veya sözleşme çalışma bildirimi (SOW) yoluyla program yürütme yapısına referans olarak dahil edilir. 6.2 ACAT Programları ve Tedarik Kategorisi (ACAT) program seviyeleri I ila III için Savunma Tedarik Sisteminin İşletilmesi için Sözleşmeye Dayalı Rehberlik Talimatları ve bunun sonucu olarak her seviye için Dönüm Noktası Karar Otoritesi (MDA) DoDI 5000.02 tarafından tanımlanır. Bu DoDI, tüm kilometre taşları ve aşamalar için yasal ve düzenleyici bilgi gereksinimlerini, Kazanılmış Değer Yönetimi (EVM) uygulama politikasını, Satın Alma Programı Temel Çizgileri (APB'ler) için yasal ve düzenleyici politikayı ve benzersiz karar forumları veya politikaları olan program kategorilerini tanımlar. Bu politikalar, bilgi teknolojisi (BT) programları, Ulusal Güvenlik Sistemleri (NSS) için geçerli olan belirli yasal ve düzenleyici gereklilikleri; ayrıntılı özel test ve değerlendirme (T&E) prosedürleri; kaynak tahmini, İnsan Sistemleri Entegrasyonu (HSI), hizmetlerin satın alınması, Savunma İş Sistemleri ve Sistem Mühendisliği ile birlikte tüm satın alma programlarına uygulanabilir idari ve uluslararası politika için ayrıntılı politika. Edinme programının her aşaması için teknik incelemeler, her olay için açıkça tanımlanmış “Kabul Kriterleri” ile Entegre Ana Planda (IMP) önemli dönüm noktası olayları olarak tanımlanır. Belirli programlar, yüklenicinin Entegre Ana Çizelgesine (EYS) dahil edilmek üzere her inceleme ve destekleyici alt düzey inceleme faaliyetleri için sözleşmeyi yapan kurum ve yüklenici tarafından ortaklaşa geliştirilir. Teknik incelemeler, bireysel program kapsamına ve karmaşıklığına uyacak şekilde uygun şekilde uyarlanabilir (Ek K – MIL STD-1521'i Uyarlamak için Uygulama Kılavuzu). Gözden geçirmelerin uyarlanması veya ortadan kaldırılması, mühendislik ve lojistik işlevsel disiplin liderliği ile koordine edilmeli ve programın PKP'sinde belgelenmelidir. Teknik incelemeleri Sistem Mühendisliği Planına (SEP) entegre etmenin temel amacı, Kullanıcı Aracısının sözleşmeye dayalı spesifikasyonlarını ve performans gereksinimlerini karşılayan sistemleri tasarlamak, geliştirmek ve sahaya sürmektir. Tüm ACAT programları, PKP'de aşağıdaki temel teknik incelemeleri1 veya kapılı olayları2 içerecektir (geçerli olduğu BEN. şekilde): İlk Teknik İnceleme (ITR)1 II. Alternatif Sistem İncelemesi (ASR)1 III. Entegre Mevcut Durum İncelemesi (IBR)2 IV. Sistem Gereksinimleri İncelemesi (SRR)1 İÇİNDE. BİZ. Sistem İşlevsel İncelemesi (SFR)1 Yazılım Gereksinimleri ve Mimari İncelemesi (SAR)1 VII. Teknoloji Hazırlık Değerlendirmesi (TRA)2 8. Ön Tasarım İncelemesi (PDR)1 IX. Kritik Tasarım İncelemesi (CDR)1 X. Teste Hazırlık İncelemesi (TRR)1 11. Sistem Doğrulama İncelemesi (SVR)1 12. Üretime Hazırlık İncelemesi (PRR)1 13. Operasyonel Test Hazırlık İncelemesi (OTRR)2 XIV. Fiziksel Yapılandırma Denetimi (PCA)1 XV. Hizmet İçi İnceleme (ISR)1 Programın yapısı ve/veya edinim döngüsünün neresinde programın gireceği dikkate alındığında, programların uygulanmayan teknik incelemeler yapması gerekmez. Bu uyarlama, ayarın bir parçası olarak güncellenecektir. Sayfa 25 / 168 Machine Translated by Google program mühendisleri, lojistikçiler ve onların işlevsel disiplin liderliği ile birlikte gündemi ve katılımcıları gözden geçirin. 6.3 "Kabul kriterleri" Ek A, B, C, D ve E, SRR, SFR, PDR'ye giriş ve başarılı çıkış için başarıların nesnel kanıtı olarak hem geliştirme ajansı hem de yüklenici tarafından özel olarak dikkate alınması gereken “Kabul Kriterlerini” ele almaktadır. ve CDR incelemeleri. İncelemeye giriş, yüklenicinin kriter unsurlarını uygun bir şekilde ele almasını ve tüm kriter unsurlarının ihale makamını tatmin edecek şekilde uygun şekilde ayrıştırıldığı anlamına gelecek şekilde incelemeden başarılı bir şekilde çıkabilmesini gerektirir. SRR, SFR, SAR, PDR ve CDR için özel "Kabul Kriterleri", aşağıdaki beş ana kategori altında başarıların nesnel kanıt örnekleri olarak Ek A, B, C, D ve E'de belirtildiği gibi düzenlenecektir: 1. Sistem Mühendisliği ve Mimari Geliştirme 2. Sistem, Segment ve Alt Sistem Tasarımı 3. Sistem Doğrulama ve Validasyon 4. Mühendislik Disiplinleri ve Uzmanlık Mühendisliği 5. Entegre Teknik Risk ve Azaltma Geliştirme ajansı ve yüklenici ortaklaşa benzersiz "Kabul Kriterleri" geliştirecektir. F'den J'ye kadar olan teknik incelemeler için, bu beş ana kategori kriter örneğini kullanarak. 6.4 Sistem Mühendisliği Süreç Hedefleri Sistem mühendisliği süreci, gereksinim analizi ile başlayan, işlevsel (mantıksal) analiz ve gereksinim tahsisine ve ardından çözüm tasarlamaya (sentez) devam eden yinelemeli bir süreçtir. Yineleme, karmaşık sistem geliştirmenin normal seyrinde montaj ve entegrasyon sırasında yukarıdan aşağıya yinelemeler ve artan seviyelerde ayrıntılı ve aşağıdan yukarıya yineleme ile sistem mühendisliği süreci boyunca geri bildirim döngüleri, sistem analizi ve kontrol yoluyla gerçekleşir. Ekler A, B, C, D ve E, beş temel tasarım incelemesinde uygun şekilde tanımlanmış kriterlerle hazırlık ve gösterimde gerçekleştirilen herhangi bir sistem için tipik sistem mühendisliği süreçlerini, görevlerini ve ürünlerini genişletilmiş ayrıntılarla açıklar. Tanımlanan görevler, sistem yaşam döngüsü boyunca gerçekleştirilecektir; ancak, içinde tanımlanan “Kabul Kriterleri”nin gösterilmesinde bu görevlerin ürettiği detay ve olgunluk büyük ölçüde EI'nin yaşam döngüsündeki olgunluk durumuna bağlı olacaktır. Yüklenici/geliştirici ve sözleşme ile müşteri kurumlarının ortak sorumluluğundadır; sistem mühendisliği sürecini tasarım gözden geçirme süreciyle, uyumluluk belgelerinin, standartların ve referans kılavuzlarının ve el kitaplarının karşılıklı olarak mutabakata varıldığı ve sözleşmeyle uygun olarak belirtildiği şekilde uyarlanmasıyla entegre etmek. (IAW) Ek K. Tasarım gözden geçirme süreçlerinin ayrılmaz ve doğal bir parçası olarak geliştirici, müşterinin desteği ve onayı ile aşağıdaki gibi kullanıcı gereksinimleri ve hedeflerini daha yüksek bir olgunluk düzeyiyle geliştirebilir, geliştirebilir ve güncelleyebilir: a. Yetenek beyanları, tanımlanmış olanlara karşılık gelen eşiklere ve hedeflere ihtiyaç duyar. yetenek boşlukları B. Müşteri IAW tarafından yönlendirilen uygulanabilir görünümler (Operasyonel, Sistem ve Teknik) dahil olmak üzere mimari ürünler DoD Mimari Çerçevesi (DoDAF) c. Alternatif malzeme yaklaşımlarının ve seçilen malzeme yaklaşımları için, daha fazla ayrıntılandırma ve müteakip geliştirme potansiyeli sunan yetenek boşluklarını doldurabilecek alternatif operasyonel ve sistem konseptlerinin belirlenmesi D. Savaşçının Operasyonel Senaryolar ve Operasyon Konsepti (CONOPS) ile dikkate alınan operasyonel ve sistem ihtiyaçları arasındaki yetenek açıkları, CONOPS ile yüklenicinin Operasyon Konsepti (OPSCON) arasında tutarlılığı sağlarken e. Yetenekler ve yeteneklerdeki evrimsel büyüme arasındaki ilişkinin değerlendirilmesi, bir yandan malzeme için yaşam döngüsü maliyeti, program ve risk Sayfa 26 / 168 Machine Translated by Google Öte yandan, maliyeti, programı veya riski yönlendiren bu yetenekleri vurgulamak için yetenekler sağlayabilecek yaklaşımlar veya sistem kavramları F. Varsa, nihai olarak yeni yetenekle değiştirilecek, kısıtlanacak veya tamamlanacak olan mevcut bir sistemden geçiş için yaklaşımların geliştirilmesi G. Gelecek vaat eden sistem konseptlerinin geliştirilmesine yönelik gelecekteki potansiyel eylemler için teknolojik gelişmelerin ve diğer risk azaltma adımlarının tanımı H. Sürdürme stratejileri i. Tehdit ortamının tanımı (Savunma İstihbarat Teşkilatı (DIA) veya Servis Teknik İstihbarat Merkezi onaylı belgelere dayalıdır ve bunlara atıfta bulunulmuştur) J. Operasyonel test planlaması Bunu yaparak geliştirici, sistemin gereksinimleri, kullanıcı gereksinimleri veya operasyonel yetenek gereksinimleri süreci arasındaki tutarsızlıkları belirleyebilir ve üretilebilir, desteklenebilir ve örneğin aşağıdakiler gibi istenen hedefleri karşılayan bir temel sistem tasarım yapılandırmasına ulaşabilir: a) Operasyon, sistem davranışı ve gerekli işlevsellik kavramlarıyla tutarlı gerekli minimum veya eşik operasyonel yetenekler dahil olmak üzere, gereksinimler temelindeki işlevsel ve performans gereksinimlerini doğru ve eksiksiz bir şekilde yansıtmalıdır b) Tüm sıralama, eşzamanlılık, ve zamanlama Gereksinimler c) Ayrıntılı ve kesin işlevler veya mantıksal öğeler için temeli ve bunların tahsis edilmiş veya türetilmiş performanslarını ve işlevsel gereksinimleri bir sonraki alt seviyede yeterince tanımlayın d) Gereksinimleri alt düzeylere ayrıştırın, böylece her biri tahsis edilen temel çizgiyi oluşturmak için fiziksel hiyerarşinin öğeleriyle ilişkilendirilebilir ve üst düzey performans gereksinimlerinin ve tasarım kısıtlamalarının alt düzeylere tahsisi tamamlanır e) İlişkileri içerebilir fiziksel çözüme ve kararda belgelenmesi veri tabanı f) Hem iç hem de dış arabirimlerin tanımını içerebilir ve fiziksel uygulamanın yanı sıra veri formatları, veri semantiği vb. gibi mantıksal konuları ele alır. g) Müşteri katılımı ve onayı yoluyla doğrulanabilir , örneğin: (1) İstenen sistem özelliklerine uyun (2) Gereksinim temel çizgisinin her bir öğesi ile işlevsel mimarinin her bir öğesi arasında iki yönlü izlenebilirliğe izin verin Tasarımın gözden geçirilmesi ve ilgili destekleyici süreçler ve veriler böylece, temel tasarımın sistem etkinliği, yaşam döngüsü maliyeti, programı, riski ve evrimsel büyüme potansiyelinin uygulanabilir ve karşılanabilir olduğuna dair üzerinde anlaşmaya varılan kriterlere karşı yüksek derecede güven ile değerlendirme ve doğrulama sağlar. . 6.5 Teknoloji Hazırlık Değerlendirmesi (TRA) TRA, tüm edinim programları için düzenleyici bir bilgi gereksinimidir. TRA, sürdürülebilirlik faktörleri de dahil olmak üzere kritik teknoloji öğelerinin (CTE'ler) olgunluğunu değerlendiren sistematik, metrik tabanlı bir süreçtir. CTE, bir platformun veya sistemin geliştirme, üretim veya operasyonda sistem operasyonel eşik gereksinimlerini karşılamak için bağlı olduğu yeni veya yeni teknoloji veya uygulaması olarak kabul edilir. Sayfa 27 / 168 Machine Translated by Google Her TRA, tanımlanmış Teknoloji Hazırlık Düzeylerini (TRL'ler) ve Üretim Hazırlık Düzeylerini (MRL'ler) kullanarak seçilen sistem öğelerinin mevcut hazırlık düzeyini puanlayacaktır. TRA, dönüm noktası karar tarihlerini veya ilgili karar noktalarını olumsuz etkileyebilecek kritik teknolojileri (üretimle ilgili kritik teknolojiler dahil) ve diğer potansiyel teknoloji riski alanlarını vurgulayacaktır. Her TRA, özellikle SRR, PDR ve PRR olmak üzere diğer Teknik İncelemelerle eşzamanlı olarak yürütülecektir. TRA'nın Sistem Edinme döngüsündeki TRL, MRL, bireysel teknik incelemeler ve dönüm noktası karar noktaları ile ilişkileri Şekil 2'de gösterilmektedir. B Programı Başlatma A malzeme teknoloji Gelişim Çözüm Analiz malzeme Gelişim Karar ITR Prototip Sistem Tasarımı PDR ASR SRR SFR PDR CDR veya MRL'ler 1 23 14 3 23412 5 4 5 6 6 Operasyonlar Operasyonlar & dağıtım CTP Karar CDR bir Destek Sürdürme Gözden geçirmek PCA TR SVR (FCA)/ PRR IBR ARASINDA ARASINDA ATEŞ IOC Üretme & Postalamak Postalamak PDR bir IBR TL'ler C Mühendislik ve Üretim Geliştirme ISR OTRR IBR ARASINDA 7 89 7 8 9 Şekil 2. Sistem Edinim Kapıları, Kilometre Taşları ve Olaylarla TRA İlişkisi Sayfa 28 / 168 10 İmha etmek Machine Translated by Google ekler Teknik İncelemeler ve Denetimler Sistemler, Ekipman ve Bilgisayar Yazılımı Sayfa 29 / 168 Machine Translated by Google ekler Sayfa 30 / 168 Machine Translated by Google Ek A Ek A - Sistem Gereksinimlerinin İncelenmesi (SRR) 10. Sistem Gereksinimleri İncelemesi (SRR) SRR, geliştirme için sözleşmesi yapılan tüm gereksinimlerin (operasyonel ve sistem) Yetenek Geliştirme Belgesinden (CDD) türetildiğini ve aşağıdaki şekilde tanımlandığını doğrulamak için kullanılan çok işlevli ve çok disiplinli bir teknik inceleme ve sistem mühendisliği (SE) süreç değerlendirmesidir: A. Program maliyeti, bütçe, program, risk, kullanıcı ve/veya diğer kısıtlamalarla tutarlıdır b. Sistem belirtiminde yakalanır C. Sistem mimarisi ticaretine ve konsept tanımına devam etmek için yeterince olgunlaşmıştır d. Tercih edilen sistem çözümü için mevcut teknolojilerle tutarlıdır e. Yönetilebilir risk ile program hedeflerini karşılayabilir. . 10.1 Genel SRR, işlevsel analiz ve ön gereksinimlerin tahsis edilmesi (örneğin, işletim, bakım, eğitim, Donanım Yapılandırma Öğeleri (HWCI'ler), Yazılım Yapılandırma Öğeleri (SWCI'ler), tesis CI'leri, üretim hususları, personel ve insan) tamamlandıktan sonra yüklenici tarafından yürütülecektir. faktörler) yüklenicinin Sistem Mühendisliği Yönetimi çabasının ilk yönünü ve ilerlemesini ve optimum ve eksiksiz bir yapılandırmaya yakınsamayı belirlemek. SSR'de, sistem gereksinimlerinin önemli bir kısmı oluşturulmuş ve temel alınmıştır ve sistemin doğasına ve karmaşıklığına bağlı olarak, segmentler, alt sistemler veya CI'ler için ayrı SRR'ler programlanmıştır. Temel SRR unsurları aşağıdaki değerlendirmeleri içerir: a. Temel performans parametrelerinin (KPP'ler) çoğunluğu, CONOPS tarafından belgelendiği şekliyle Sistem Gereksinimleri, alternatiflerin analizi (AoA) sonuçları, İlk Yetenekler Belgesi (ICD) ve yetenek geliştirme belgesi (CDD) ve sistem performans spesifikasyonları ile tutarlıdır b. Sistem gereksinimleri, KPP'ler ve destekleyici teknik performans ölçütleri (TPM'ler) gereksinim tahsis belgesinde (RAD) tanımlanmış ve belgelenmiştir C. Temel Sistem Gereksinimleri şunlarla tutarlıdır: (1) Maliyet (program bütçesi ve finansman profili) (2) Birlikte çalışabilirlik (3) Belirtilen diğer sistem kısıtlamaları (4) Risk (5) Çizelge (program çizelgesi ve Entegre Ana Çizelge (EYS)) D. Her sistem için biçim, uygunluk, işlevsellik ve performans (FFF&P) temel çizgileri belirlenir misyon ve kullanıcı hedefleriyle tutarlı tasarım konsepti ve CI 10.2 Amaç SRR'de, toplam Sistem Mühendisliği Yönetimi faaliyeti ve çıktısı, Çalışma Bildirimi, sistem, alt sistem ve CI gerekliliklerine uygunluk açısından gözden geçirilecektir. SRR, yüklenicinin türetilmiş tasarım gereksinimlerinin, paydaş ihtiyaçlarını karşılayacak ve aşağıdakileri içerecek bir sistemle sonuçlanan müşteri gereksinimlerini tam olarak karşıladığını doğrulamak için Sistem Geliştirme ve Gösterimin Sistem Edinme öncesi ve sonrası aşamasının kilit bir unsurudur. : Sayfa 31 / 168 Machine Translated by Google Ek A A. Yüklenicinin türetilmiş tasarım gereksinimlerinin ve önerilen ön sistem tasarımının, satın alma programı temel çizgisini (APB) desteklediğinin ve aşağıdaki belgelerde belirtilen sistem ve arayüz gereksinimlerini tam olarak uyguladığının doğrulanması: (1) İlk Yetenekler Belgesi (ICD) (2) Yetenek Geliştirme Belgesi (CDD) (3) Sistem Mühendisliği Planı (SEP) (4) Test ve Değerlendirme Ana Planı (TEMP) (5) Program Odaklı ES&OH Değerlendirmesi (PESHE) (6) Program Koruma Planı (PPP) (7) Teknoloji Hazırlık Değerlendirmesi (TRA) B. Önerilen ön sistem tasarımının kullanıcının aşağıdakilerle tutarlı olduğunun doğrulanması: (1) KONOPLAR (2) Çevre güvenliği ve iş sağlığı (ES&OH) gereklilikleri (3) Entegre Destek Planı (ISP) (4) İşler Arası İhtiyaçlar (5) KPP'ler (6) Operasyonel Mimari (OA) (7) Sistem Performans Spesifikasyonları (8) Sistem desteği ve bakım hedefleri ve gereksinimleri Bu gözden geçirme için kritik öneme sahip olan husus, yüklenicinin önerilen sistem kavramı, ürünleri ve süreçlerine özgü risklerin anlaşılması ve SRR'nin riskleri entegre yönetim planı (IMP), entegre ana program (EYS) ve satın alma ajansı tarafından yönetilebilen risk. 10.3 Amaç SRR, APB hedefini yerine getirmek ve sistem için bir ön işlevsel temel (BL) oluşturmak üzere uyarlanmış analitik ve tasarım mühendisliği çabalarının gözden geçirilmesi yoluyla yüklenicinin sistem mühendisliği yönetim planlarının ve süreçlerinin yeterliliğini değerlendirmek için yürütülür. Bu değerlendirmeler, aşağıdaki gibi analitik ve SE çabalarını içerebilir: A. Çalışmalar (1) Kavramlar (2) Tasarımlar (3) Gereksinim tahsisi (4) Sistem arabirimi (5) İşlemler (ör. işlevler, görev, destek, donanım, sabit yazılım, yazılım vb.) B. Analiz ve Sentez (1) Fonksiyonel akış (2) İnsan faktörleri (3) Yaşam döngüsü maliyeti (4) Lojistik destek (5) İnsan gücü gereksinimleri ve personel Sayfa 32 / 168 Machine Translated by Google Ek A (6) Misyon ve gereksinimler (7) Program riski (8) Gereksinim geliştirme (9) Uzmanlık Mühendisliği (ör. Donanım ve Yazılım Güvenilirliği, Bakım Yapılabilirlik, Üretilebilirlik, Silah Entegrasyonu, Elektromanyetik Uyumluluk, Beka Kabiliyeti ve/veya Güvenlik Açığı (Nükleer Dahil), Muayene Yöntem ve Teknikleri, Enerji Yönetimi, Çevresel Hususlar) (10) Sistem mimarisi geliştirme (11) Sistem maliyet etkinliği (12) Eğitim ve tesis gereksinimleri C. Değerlendirmeler (1) Temel teknolojiler ve bileşenler için endüstriyel temel yetenek ve olgunluk (2) Teknoloji olgunluğu d. Planlar ve Planlama (1) Yapılandırma yönetimi (2) Veri yönetimi (3) Mühendislik entegrasyonu (4) İlk Program Odaklı ES&OH Değerlendirmesi (PESHE) uyumluluğu (5) İlk test ve değerlendirme (6) Entegre test (7) Kilometre taşı programları (8) Ön imalat (9) Üretilebilirlik analizi (10) Şartname oluşturma (11) Sistem güvenliği (12) Teknik Performans Ölçümü (TPM) (13) Teknoloji hazırlığı ve yönetimi Temel SRR ürünleri, örneğin aşağıdakileri içerecektir: A. Sistem geliştirme ve gösterimi için kapsamlı bir risk değerlendirmesi b. Donanım, insan ve yazılıma sistem gereksinimlerinin bir ön tahsisi alt sistemler C. Sistem gereksinimlerinin, tercih edilen sistem çözümünün, mevcut teknolojinin ve program kaynaklarının (finansman, program, personel ve süreçler) Sistem Geliştirme ve Gösterime (SDD) ilerlemek için tatmin edici bir temel oluşturduğuna dair bir onay D. Onaylanmış bir ön sistem performans spesifikasyonu e. Güncellemeleri içeren onaylı bir ürün destek planı (PSP) f. Maliyet ve kritik yol etmenlerini ele alan onaylanmış bir sistem geliştirme ve tanıtım aşaması sistem mühendisliği planı (SEP) G. Yazılım bileşenlerinin tanımlanması (taktik, destek, teslim edilebilir, teslim edilemez vb.) Sayfa 33 / 168 Machine Translated by Google Ek A SRR'den alınacak en önemli çıkarım, tanımlanmış gereksinimlerin program geliştirme maliyeti, zaman çizelgesi ve APB hedefleri bağlamında sağlanan sistem performansı yeteneği üzerindeki etkilerinin net bir şekilde anlaşılmasıdır. 10.4 SRR “Kabul Kriterleri” SRR'de, sistem mühendisliği yönetim faaliyetlerinin tüm ana program öğeleri ve risk faktörleri dikkate alınacaktır. SRR'nin temel beklentisi, gözden geçirmenin değişiklik kontrolü altına alınabilecek onaylanmış bir teknik temel ile sonuçlanması ve temelin maliyet, program ve performans gereksinimleri kısıtlamaları dahilinde uygulanabileceğinin belirlenmesidir. Bir SRR'nin hazırlanmasında ve programlanmasında, yüklenici, sözleşme makamını tatmin edecek şekilde aşağıdakileri gösterecektir: A. Her bir kriteri desteklemek için uygun şekilde gerçekleştirilen tüm uygulanabilir mühendislik faaliyetleri b. Kabul edilen SSR kriterleri öğelerinin çoğu ve tamamı başarıyla ele alınmıştır c. Tüm kriter öğeleri uygun şekilde ayrıştırılmıştır d. Temel sistem gereksinimleri sağlam, desteklenebilir ve sözleşme yapan kurumu tatmin edecek şekilde belgelenmiştir. SRR “Kabul Kriterleri” aşağıdaki beş ana kategori altında düzenlenecektir: 1. Sistem Mühendisliği ve Mimari Geliştirme (10.4.21) 2. Sistem, Segment ve Alt Sistem Tasarımı (10.4.2) 3. Sistem Doğrulama ve Doğrulama (10.4.3) 4. Mühendislik Disiplinleri ve Uzmanlık Mühendisliği (10.4.4) 5. Entegre Teknik Risk ve Azaltma (10.4.5) Bu gözden geçirme, yüklenicinin temel ve üzerinde mutabık kalınan SRR “Kabul Kriterlerini” destekleyen teknik çabasının nesnel kanıtı olacaktır, örneğin: a) Açıklandığı şekliyle sistem gereksinimleri, İlk Yetenekler Belgesini veya taslağı karşılayabilir mi? Yetenek Geliştirme Belgesi? b) Sistem gereksinimleri, sistem işlevsel tanımını ve işlevsel ayrıştırmayı sağlamak için yeterince ayrıntılı ve anlaşılır mı? c) Onaylanmış bir sistem performans spesifikasyonu var mı? d) Programın başarılı olması için yeterli süreçler ve ölçümler mevcut mu? e) İnsan Sistemleri Entegrasyon gereklilikleri gözden geçirildi ve genel Sistem tasarımı? f) Geliştirme için riskler biliniyor ve yönetilebilir mi? g) Program çizelgesi yürütülebilir mi (teknik ve/veya maliyet riskleri)? h) Programda uygun personel bulunuyor mu? i) Program mevcut bütçe dahilinde yürütülebilir mi? j) Güncellenen maliyet tahmini mevcut bütçeye uygun mu? k) Ön Maliyet Analizi Gereksinimleri Tanımı, onaylananla tutarlı mı? sistem performans belirtimi? l) Sistem belirtimindeki yazılım işlevselliği, yazılım boyutlandırma tahminleri ve kaynak yüklü program ile tutarlı mı? m) Teknoloji Geliştirme aşaması, geliştirme risklerini yeterince azalttı mı? n) Bu incelemeyle ilişkili tüm IMP ve IMS görevleri başarıyla kapatıldı mı? Sayfa 34 / 168 Machine Translated by Google Ek A Aşağıdaki bölümler, gözden geçirilecek tüm geçerli mühendislik faaliyetleriyle birlikte, sözleşme ile özel olarak düzenlendiği şekilde, gerçekleştirilmesi gereken asgari ancak her şeyi kapsamayan kriter listesini ele almaktadır. 10.4.1 Sistem Mühendisliği ve Mimari Geliştirme SRR'de Sistem Mühendisliği ve Mimari Geliştirme gereksinimleri olgunluk kriterleri örneklerinin kanıtı: A. Sistem Mühendisliği ve Mimari Geliştirme 1. Sistem gereksinimleri eksiksiz, açıkça belirtilmiş, uygulanabilir ve doğrulanabilir. KPP ve sistem CONOPS, sistem performans belgesi (SPD) ve AoA çalışmaları vb.'den türetilen sistem gereksinimleri, örneğin, sistem performans spesifikasyonları ve Arayüz Kontrol Belgeleri (ICD'ler) ile ilişkili KPP ve sistem gereksinimleri 2. Sistem mühendisliği metodolojisi uygulamaları eksiksiz, pratik ve kapsamlıdır 3. Sistem gereksinimleri kavramsal mimari kavram(lar)ında sentezlenmiştir, örneğin: A. Mimari konseptler, programın sistem gerekliliklerine uygunluk düzeyini gösterir, örneğin, uygulanan modelleme ve sentez metodolojileri kanıtlanmış uygulamalara dayanır b. Mimari görünüm(ler) her bir sistem için inşa edilir (sistemler sistemi, sistemler, segmentler ve alt sistemler) kavram(lar)ı: (1) Sistem mimarisi görünümü/görünümleri, sistemi ve iç ve dış arabirim gereksinimlerini ve yüklenici operasyonel kavramlarını uygular (2) Sistem mimarisi görünüm(ler)i uygulanabilir ve genişletilebilir (3) Form, uyum ve işlev (FF&F) ve KPP'ler açısından her bir sistem (sistemler sistemi, sistem ailesi, segmentler ve alt sistemler) kavram(lar)ı için aday mimari görünümler geliştirilir, türetilir ve değerlendirilir. (4) Görevleri ve faaliyetleri, sistem bileşenleri öğelerine ve kuruluş sahipleri ve operatörlerine göre performans gereksinimlerini tanımlayan bir operasyonel görünüm (OV) geliştirilir. (5) Sistem bileşenleri, öğeler ve kuruluş sahipleri ve operatörler tarafından işlevsel arayüz gereksinimlerini tanımlayan bir sistem görünümü (SV) geliştirilir. (6) Tasarım konseptini uygulamak için gerekli olabilecek standartları ve sözleşmeleri tanımlayan Kritik Teknik Standartlar Görünümü geliştirilir 4. Kavramsal sistem tasarım çözümleri (alternatifler dahil) mühendislik ticaret alanı, teknik gereksinimler, sistem performansı bağlamında geliştirilir ve değerlendirilir , riskler (teknik, programatik, program, maliyet), yaşam döngüsü maliyeti (LCC) ve bağımsız değişken olarak maliyet (CAIV) çalışmaları vb., örneğin: a. Her aday sistem tasarım çözümü için temel teknik ve programatik ayrıntılar geliştirilir ve türetilir ve CDD, Sistem Performans Spesifikasyonu ve diğer türetilmiş gereksinimlerle ilişkilendirilir, örneğin, yüklenicinin operasyonel konseptleri, Warfighter ihtiyaçları ve operasyon konseptiyle (CONOPS) tutarlıdır B. Önerilen sistem tasarım çözümleri, program performansı, maliyet ve program riskleri ve azaltma stratejileri açısından değerlendirilir. C. Sistem tasarım çözümleri için askerden arındırma ve kullanım ömrü sonunda imha (EOL) dikkate alınır (alternatifler dahil) 5. Aday harici sistem arayüzleri belirlenir ve başlangıç ve kavramsal arayüz gereksinimleri geliştirilir, örneğin: a. Kritik harici sistem arayüzleri, taslak Sistem Spesifikasyonu ile tutarlı ve referansta bulunulan temel performans ve arayüz gereksinimlerini tanımlayan geliştirilir ve türetilir. Sayfa 35 / 168 Machine Translated by Google Ek A B. Yüklenicinin operasyonel konseptleri, sistem ve harici arayüz ile tutarlıdır. Gereksinimler C. İç ve dış sistemler üzerindeki etkiler ve sistem gereksinimleri belirlenir d. Sistem ve harici arayüz gereksinimleri, aşağıdakiler dahil tüm sözleşme hükümlerini karşılar: sözleşmeyle dayatılan spesifikasyonlar ve standartlar e. Anlaşıldığı ve sistem tasarım çözümüne entegre edildiği şekliyle sistem gereksinimleri, ilk yetenekler belgesini (ICD) veya yetenek geliştirme belgesini (CDD) karşılar 6. Ön Sistem Gereksinim Temelleri, her tasarım konsepti için belirlenir, örneğin: A. Kavramsal sistem tasarımı konseptleri ve çözümleri, ön görev ve sistem gereksinimi temelleri açısından belgelenmiştir. B. Kavramsal sistem tasarımı konseptleri ve çözümleri, ön fonksiyonel temeller açısından belgelenmiştir. C. Önerilen ve önerilen tüm gerekli sistem gereksinimleri belgelenmiştir 7. Ön yaşam döngüsü maliyeti (LCC) ve bağımsız değişken olarak maliyet (CAIV) çalışmaları her bir (tasarım) konsepti desteklemek için geliştirildi, örneğin: a. LCC ve CAIV modellemesi ve analizleri, her bir tasarım konsepti için uygulanır ve ilişkilendirilir; örneğin, öngörülen program geliştirmeyi ve tamamlanan işletme ve idame maliyetlerini ve ayrıca diğer "harici" sistemlere yönelik tahmini maliyet etkilerini gösteren maliyet modelleri B. Geçerli ticari çalışmaların yapıldığını gösteren LCC ve CAIV metodolojisi sunulmaktadır. yürütülen 8. Sistem geliştirme maliyeti ve programları belirlenir, örneğin: A. Sistem geliştirme maliyetini ve programlarını tahmin etmek için uygun maliyet modelleri kullanılmıştır b. Karmaşıklık ve diğer parametreler gibi gerçekçi sistem geliştirme maliyet etkenleri ve varsayımlar belgelenmiştir ve maliyet ve program tahminlerini geliştirmek için doğrulanmış sistem geliştirme maliyet modellerinde kullanılmıştır c. Yaşam döngüsü maliyet tahmini, sistem desteğini yeterince içerir d. Geliştirme ve destek görevlerinin tümü, yaşam döngüsü maliyet tahminlerine dahil edilir, e. Ön sistem geliştirme tahminleri desteklenebilir ve geçmişe dayalıdır; örneğin, ön sistem geliştirme maliyeti ve program tahminleri, SRR'de uygun tahmini riski karşılamak için yeterli marja sahiptir. 9. Sistem mimarisinin ve tasarım konseptinin/kavramlarının KPP'lere göre izlenebilirliği, bir satın alma kurumu tarafından onaylanmış ve belirlenmiş bir veri tabanında ve veri havuzunda belgelenir ve gösterilir, örn.: A. Sistem mimari(ler)i ve tasarım konsept(ler)i ticaret çalışmaları ele alınır b. Sistem mimari(ler)i ve tasarım konsept(ler)i KPP'lere göre izlenebilirliğe sahiptir ve sistem ticaret araştırmalarıyla doğrulanmıştır C. Ön sistem iç ve dış arayüz gereksinimleri, sistemle tutarlıdır birlikte çalışabilirlik gereklilikleri ve İlk Yetenekler Belgesi D. Sistem dahili ve harici arayüz gereksinimleri temel alınmıştır ve aşağıda her sistem mimarisi ve tasarım konsepti için konfigürasyon yönetimi 10. Ön Sistem Performans Spesifikasyonu, her bir sistem tasarım konsepti için görev gerekliliklerini karşılamak üzere geliştirilir ve gösterilir; örneğin, her bir tasarım konsepti için, temel görevin sağlanması için benzer sistemlerden modeller, simülasyonlar, analizler ve test sonuçları kullanılarak kanıtlar sağlanır ve performans gereklilikleri (CONOPS, ICD ve KPP'ler) karşılanır. Sayfa 36 / 168 Machine Translated by Google Ek A B. Birlikte Çalışabilirlik Mimarisi Geliştirme 1. Her sistem (Sistemler Sistemi, Sistem Ailesi, Segmentler ve Alt Sistemler) tasarım konsepti için sistem ve görev birlikte çalışabilirlik gereksinimlerini karşılamak için seçilen Savunma Bakanlığı Bilgi Standartları Deposu (DISR) standartlarını gerekçelendirin, yani sistem tasarımları DISR uyumlu ve uyumlu olmalıdır 2. DISR dışındaki yeni veya benzersiz standartlar, onay ve DISR değerlendirmesi için sunulur (örn. yeni veri formatları, veri değişim protokolleri ve şemaları, Ethernet alternatifleri) 3. Uygulanan her tasarım konsepti için sistem ve harici arayüz gereksinimleri tarafından bir ön birlikte çalışabilirlik sistemi mimarisi tanımlanır. 4. Uyumluluğun sağlanması ve kullanıcılar ile operatörler arasındaki karşılıklı ilişkilerin tanımlanması için ön birlikte çalışabilirlik analizleri tamamlanır. 5. Birlikte çalışabilirlik ticaret çalışmaları ve gereksinim analizleri tamamlandı, örneğin: A. Birlikte çalışabilirlik performansı ve tasarım parametreleri ve sürücüleri, gereksinim analizi ve ticaret araştırmalarından elde edilir B. Sonuçlar tüm sistem temellerine ve modellerine entegre edilir c. Değerlendirilen tüm kritik ve ana gereksinimleri gösteren bir metodoloji sunulmuştur 6. İlk sistem mimarisi, operasyonel kavramların uygulanmasını destekler ve birlikte çalışabilirlik hedefleri 7. Sistem operasyonel kavramları şunları içerir, örneğin: A. Donanım ve yazılım perspektifinden hem nominal hem de nominal olmayan senaryolar, örneğin işlemci yük devretme, sistem mimarisiyle tutarlı artıklık yönetimi b. Sistemle tutarlı nominal ve nominal olmayan senaryolar için ayrıntılı zaman çizelgeleri mimari C. Uygun olduğu şekilde uydu aracı, takımyıldızı ve görev yönetimi d. Operasyon ve bakım personelinin tanımlanması, örneğin sayılar, beceriler, roller ve konumlar, sistem mimarisi ile tutarlı 8. Ön sistem mimarisi, sistemi ve harici arayüzü (I/F) tamamen uygular. Gereksinimler 9. Global Information Grid'e (GIG) yönelik ön sistem I/F'leri tanımlanır 10. Uygulanabilir GIG anahtar arayüz profilleri (KIP'ler) tanımlanır 10.4.2 Sistem (Sistem Sistemi, Sistem Ailesi), Segment ve Alt Sistem Tasarımı SRR'de Sistem, Segment ve Alt Sistem Tasarım Kavramlarının Kanıtı olgunluk kriteri örnekleri: A. Sistem, Segment ve Alt Sistem Tasarımı 1. Ön Sistem, Segment ve Alt Sistem tanımlanır; ön tasarım kavramları yerleşik ve ana ve kritik performans parametreleri tanımlanır 2. Sistem, Segment ve Alt Sistem kavramsal tasarım çözümleri, performans gereklilikleri, mühendislik alanı, teknoloji durumu ve eksiklikleri ve teknik, programatik, zaman çizelgesi ve maliyet riskleri dikkate alınarak değerlendirilir, örneğin: a. Mühendislik analizi, sistem mimarisinin temel performans parametrelerini ve sürüş gereksinimlerini karşılama B. Yüklenicinin önerdiği teknik performans ölçütleri (TPM'ler), gelişen sistem kapasitesini yeterince değerlendirmek için gerekli olan tüm temel performans parametrelerini (KPP'ler) ve kritik tasarım parametrelerini içerir. Sayfa 37 / 168 Machine Translated by Google Ek A C. Yüklenicinin ölçümleri ve TPM süreçleri sağlam, son teknoloji uygulamaları, teknikleri ve araçları yansıtır D. Mühendislik analizi, mühendislik ilke ve tekniklerinin sağlam bir şekilde kullanıldığını gösterir. 3. Sistem(ler) (Sistemler Sistemi, Sistem Ailesi, Segmentler ve Alt Sistemler) performans parametreleri, özellikler, tasarım zorlukları ve risk değerlendirmesi tamamlandı ve sistem risk modeline entegre edildi 4. Kritik performans ve işlevsel gereksinimler, bireysel Sistem(ler) (Sistemler Sistemi, Sistem Ailesi, Segmentler ve Alt Sistemler) tasarım konsepti çözümlerine dahil edilir 5. Sistem(ler)in operasyonel sürdürme gereksinimleri tanımlanır ve türetilir, örneğin: A. Kritik sistem performansı gereksinimleri türetilir ve program gereksinimlerine ve CONOPS'a göre izlenebilir B. İzlenebilir gerekçelendirme ile her konsept çözümü için LCC modellemesi geliştirilir 6. Sistem(ler) Komuta, Kontrol, İletişim, Bilgisayar ve İstihbarat (C4I) Gereksinim Analizleri değerlendirilir ve segmentler ve alt sistemler arasında ön performans tahsis edilir, örneğin: A. Ön C4I stratejisi, savaş yönetimi ve bilgi teknolojisi (BT) ihtiyaçlarını ve sistem(ler) arasındaki bağımlılıkları tanımlar (Sistem Sistemi, Sistem Ailesi, Segmentler ve Alt Sistemler) B. Ön ağ merkezli (yani ağ) arayüz ticareti çalışmaları tamamlandı ve birlikte çalışabilirlik gereklilikleri dahil olmak üzere aday mimariler ve bilgi ortamları tanımlandı c. Ön C4I performans gereksinimleri, birlikte çalışabilirliği, birbirine bağlanabilirliği, her tasarım konsepti için desteklenebilirlik, senkronizasyon ve yeterlilik 7. Tehdit senaryoları tamamlandı ve tehdit ortamları tanımlandı, kuşatıldı ve bunlarla ilişkilendirildi sistem(ler) tasarım konseptleri, örneğin: a. Tehdit senaryoları ve ortamları tanımlanır ve değerlendirilir; performans parametreleri tanımlanır ve sistem tasarım kavramları oluşturulur ve tehditlere göre izlenebilir b. Tehdit operasyonel kriterlerinin sistem tasarım konseptlerine dahil edildiğini gösterir 8. Ortamlar (örneğin, doğal termal, nem, taşıma) tanımlanır ve performans parametreleri türetilir ve kapsanır, örneğin: a. Çevresel parametreler bilinen kaynak verilerden elde edilir, kanıtlanmış metodoloji kullanılarak sistem fonksiyonel analizi B. Çevresel parametreler, sistem tasarım kavramlarına dahil edilir B. Her aday sistem için ana bileşenlerin performans gereksinimleri belirlenir ve değerlendirilir (Sistemler Sistemi, Sistem Ailesi, Segmentler ve Alt Sistemler) çözümü, örneğin: 1. Tüm ana bileşenler, eski sistemlerin, bileşenlerin ve teknolojinin yanı sıra yeni tasarımların kullanımı da dahil olmak üzere sistem tasarım konseptlerine dayalı olarak tanımlanır. 2. Anahtar parametreler ve bilgiler her ana bileşen için geliştirilir ve değerlendirilir: A. Başlıca performans parametreleri belirlenir b. Eksiklikler de dahil olmak üzere kritik teknolojiler belirlenir 3. COTS ve azalan üretim kaynağı (DMS) dahil olmak üzere kritik tasarım ve üretim gereksinimleri ve zorlukları belirlenir 4. Ön güvenilirlik, kullanılabilirlik, bakım yapılabilirlik ve test edilebilirlik gereksinimleri tanımlanır ve belirlenen tasarım faktörleri, örneğin: Sayfa 38 / 168 Machine Translated by Google Ek A A. Kritik performans parametreleri tanımlanır ve gereksinim analizinden ve kanıtlanmış metodolojilerden türetilir B. Performans parametrelerini karşılamak için gerekli çözüm konseptleri oluşturulur ve değerlendirilir (doğrulama ve analiz metodolojileri dahil) C. Donanım ve yazılım için ana bileşen güvenilirliği, kullanılabilirliği, bakımı yapılabilirliği ve test edilebilirlik tasarım faktörleri, sistem tasarım konseptlerine dahil edilir; örneğin, tahsis ve arıza tespiti ve izolasyon yetenekleri, yerleşik test, arıza tespiti ve izolasyon alt sistemi, ayrı destek unsurları arasında tanımlanır. ekipman ve manuel prosedürler D. Ön teknoloji sistem performans gereksinimleri analiz edilir, konsept(ler) ticaret çalışmaları tamamlanır, Teknoloji Hazırlık Düzeyi (TRL) değerlendirmeleri tamamlanır ve bir geliştirme stratejisi belirlenir, örneğin: (1) TRL gösterilir veya kaynak dahil olmak üzere teknoloji geliştirme stratejileri tanımlanır ve program gereksinimleri (2) Program (Maliyet, Program ve Teknik) riskleri belirlenir, karakterize edilir ve önceliklendirilir ve azaltma stratejileri ve Yakma Planları (BDP) geliştirilir ve IMS ve Sistem Risk Modeli'ne entegre edilir 5. Ön Sanayi Üssü (IB) değerlendirmesi tamamlanır ve risk alanları belirlenir ve önceliklendirilir değerlendirme sonuçlarına göre, örneğin: A. IB değerlendirme verileri tasvir edilir ve risk alanları belirlenir B. Kaynak ve program gereksinimleri dahil olmak üzere hafifletme stratejileri geliştirilir Not: Aşağıdaki örnekler, SRR'de ele alınması beklenen veri türleri ve ayrıntı düzeyine açıklık getirmeyi amaçlamaktadır. Yüklenicinin, geliştirilen sistem tipine uygun alt sistemleri ve bileşenleri ve önerilen sistem konseptini ve teknik, maliyet ve program parametrelerini etkili bir şekilde değerlendirmek ve değerlendirmek için gerekli olan her bir alt sistem ve bileşen için uygun kriterleri belirlemesi amaçlanmaktadır, örneğin: Elektrik Gücü için: • Ön Elektrik Güç Dağıtım Sistemi (EPDS) performans gereksinimleri, özellikleri ve işletim kriterleri, başlangıç güç bütçeleri, izin verilen marjlarla toplam güç talebi ve çalışma modları (sıklık ve süre) dahil olmak üzere tanımlanır. • Spesifik teknolojileri ve topolojileri de dahil olmak üzere, ele alınan güç kaynağı kaynaklarının tip(ler)inin ön seçimi ve değerlendirilmesi • Belirlenen ön pil (veya enerji depolama) güç gereksinimleri ve çalışma modları tanımlanmış (sıklık ve süre) • Kullanım ömrü başlangıcı (BOL) ve kullanım ömrü sonu (EOL) pil ömrü gereklilikleri ve diğer benzersiz pil seçimini veya tasarımını etkileyebilecek gereksinimler belirlenir • Aday pil hücresi teknolojileri belirlenir ve pil mimarileri tanımlanır Yazılım için: • Göstermek için modülerlik yapısı da dahil olmak üzere kavramsal yazılım mimarisi geliştirildi yazılım üretilebilirliği, uyarlanabilirliği, sürdürülebilirliği • İlk işleme kapasitesi ve çıktı gereksinimleri belirlenir • Yeniden programlanabilirlik kriterleri ve yeteneği tanımlanır • Eşdeğer kaynak kod satırlarının (ESLOC) bir ön tahmini yapılır • Ön yazılım risk yönetimi ve hafifletme süreçleri tanımlanır Sayfa 39 / 168 Machine Translated by Google Ek A o Sistem ve program riskleri; karmaşıklık, boyut, işlem hızı, verim, programlar, COTS kullanılabilirliği, eski yeniden kullanım uygunluğu ve yazılım geliştirme süreçleri ve araçları gibi uygun olduğu şekilde ön kritik yazılım risklerini içerir. o Yazılım risk yönetimi süreçleri, yazılım geliştirmenin bir parçasıdır ve Sistem Risk Yönetimi Modeli ile entegredir. • Kavramsal yazılım mimarisi, açık sistem standartlarının kullanımını ele alır ve tüm gereksinimleri karşılar. uygun birlikte çalışabilirlik ile ilgili gereksinimler 10.4.3 Sistem, Segment ve Alt Sistem Doğrulama ve Validasyon Sistem, Segment ve Alt Sistem Tasarım Kavramlarının Kanıtı SRR'de doğrulama ve doğrulama (V&V) gereksinimleri olgunluk kriteri örnekleri: A. Ön Sistem, Segment ve Alt Sistem V&V stratejileri, kavramları ve metodolojiler gelişmiş: 1. Sistem(ler)in performans gerekliliklerini ve parametrelerini doğrulamak ve doğrulamak için kavramsal stratejiler oluşturulur, örneğin: a. Sistem, Segment ve Alt Sistem için V&V stratejisi ve metodolojisi ve bileşen b. V&V strateji metodolojisi ve teknikleri, örneğin: (1) Analitik, modelleme ve simülasyon (M&S) ve test etme (2) Yeni teknolojinin kullanımı, yeterlilik uygulamaları, sistem(ler) düzeyinde gösterimler ve testler (3) Harici kuruluşlar ve/ veya tesisler ve kaynak gereksinimleri ve desteği (4) ) Kanıtlanmış uygulamaların kullanımı B. Sistem, Segment ve Alt Sistem operasyonel fonksiyon ortamları belirlenir ve tanımlanır ve analiz ve ticari çalışmalar yoluyla operasyonlara ve FBL'ye göre izlenebilir: 1. Ön sistem(ler) V&V test ortamları tanımlanır ve sistem(ler)in işlevlerine ve spesifikasyon gerekliliklerine göre izlenebilir 2. V&V stratejileri ve metodolojisi ile ilişkili çevresel parametreleri gösterir C. Genel Geliştirme, Test ve Değerlendirme (DT&E) öğeleri, her bir kavramsal seçimlerinin gerekçesi ile çözüm D. Ön OT&E gereklilik analizleri tamamlandı ve operasyonel olarak izlenebilir test kriterleri tanımlandı T&E ticaret sonuçları: 1. Analiz, tüm potansiyel paydaşlardan gelen girdileri ve gereksinimleri içerir 2. V&V test gereksinimleri türetilir ve program planlama ve tasarım konseptine entegre edilir 3. Programı etkileyebilecek kaynak ve program gereksinimleri ve sorunları belirlenir teknik, maliyet veya program parametreleri E. Spesifikasyonlar aracılığıyla operasyonel gerekliliklere göre izlenebilir olan ön test gereklilikleri ve sonuçları V&V çapraz referans matrisi (VCRM) tarafından tanımlanır. F. Risk alanları belirlenir ve risk azaltma stratejileri belirlenir: 1. Teknoloji eksikliklerine dayalı olanlar da dahil olmak üzere V&V testi eksiklikleri belirlenir ve karakterize 2. Risk azaltma stratejileri geliştirilir ve kaynak gereksinimleri G dahil olmak üzere bir sistem risk modeline entegre edilir. Her gereksinim için V&V yöntemleri belirlenir, örneğin, bir V&V uyum matrisi geliştirilir. Sayfa 40 / 168 Machine Translated by Google Ek A 10.4.4 Mühendislik Disiplinleri ve Uzmanlık Mühendislik Mühendislik Disiplini ve Uzmanlık Mühendislik Kanıtı Mühendislik tanımlama ve değerlendirme olgunluk kriteri örnekleri (aşağıda A'dan R'ye kadar listelenen kategoriler), 1. Anahtar performans gereklilikleri bakımından SRR'de 2. Temel performans parametreleri 3. Eski sistemlerin, bileşenlerin ve teknolojinin kullanımı 4. Yeni tasarımların kullanımı A. Parçalar, Malzemeler ve Süreçler (PM&P) 1. Ön PM&P işlevsel gereksinimleri oluşturulmuştur 2. Her sistem tasarım konsepti için parça performansını etkileyen ortamların ve çevresel parametrelerin ilk değerlendirmesi tamamlandı 3. Risk değerlendirmeleri, teknolojiler, tedarik kaynakları ve parçaların ortak kalite seviyeleri (örn. güvenilirlik) dahil olmak üzere her bir tasarım çözümü konsepti için parça mühendisliği tasarım stratejileri geliştirilir. 4. Potansiyel uzun vadeli öğelerin ve süreçlerin ve/veya tesis ihtiyaçlarının ve etkilerinin tanımlanması B. Test ve Değerlendirme (T&E) 1. Ön T&E stratejisi, tasarım ve belirtilen gereksinimlerle uyumluluğu sağlamak için tanımlanan tüm test hedefleri, test ortamları ve test kaynakları ile gösterilmektedir. 2. Ön T&E metodolojisi/yöntemleri, sistem teknik gerekliliklerini doğrulamak için kritik olan tüm sistem bileşenlerini ele alan ve her bir belirli test öğesinin özelliklerine, etkililiklerine ve marjlarına göre uyarlanmış tüm test yaklaşımları için tanımlanır. 3. Test ortam(lar)ı, gerçekleştirilecek işlemler ve prosedürler, veri toplama gereklilikleri, dokümantasyon, analiz yöntemleri ve geçme-kalma (örn. , başarı) kriterleri 4. NDI ve COTS dahil olmak üzere sistemlerin, alt sistemlerin, bileşenlerin, düzeneklerin geliştirme, kalifikasyon ve kabul testleri uygulanır, örneğin: A. Niteliklendirme ve doğrulama yaklaşımı, belirli test edilecek öğe B. Aday seçimini desteklemek için geliştirme testi sonuçları mevcuttur C. Hayatta Kalma ve Güvenlik Açığı 1. Her bir tasarım konsepti için, değerlendirilen her tehdit için KPP'ler oluşturan ve beklenen tehdit kategorilerini, tehdit ortamlarını ve bunların meydana gelme olasılıklarını tanımlayan hayatta kalma ve güvenlik açığı tehdidi değerlendirmeleri gerçekleştirilir. 2. Görev için kritik olan bir dizi hayatta kalma özelliği ve hedefi tanımlanmıştır. özellikle: Kritiklik, Hükümetin İlk Yetenekler Dokümanında (ICD) ve Sistem Düzeyinde Operasyon Konsepti'nde (CONOPS) tanımlanan operasyonel ve hayatta kalma hedeflerini karşılayan bir sistem açısından tanımlanır. B. Özellikler ölçülebilir niceliksel parametreler cinsinden ifade edilir C. Özellikler, test ve analiz yoluyla doğrulamaya uygundur D. Özellikler, sistemin konfigürasyon temel çizgisine yansıtılır, e. Beka özellikleri, fark edilebilir sistem sertliği niteliklerine ve sistem tasarım kriterlerine dönüşmüş olmalıdır. Sayfa 41 / 168 Machine Translated by Google Ek A 3. Ön sistem ve tehdit etkileşimi analizi, her bir tehdit için izin verilen marjları belirlemek üzere her bir tasarım konsepti için gerçekleştirilir 4. Tehdit analizlerinden elde edilen beka kabiliyeti tasarım kriterleri, aday tasarım çözümlerini destekler değerlendirilen her bir tehdidi azaltmak D. Çevre Güvenliği ve İş Sağlığı (ES&OH) 1. Her tasarım konsepti için yaşam döngüsü ortamları tanımlanır ve sisteme göre değerlendirilir Gereksinimler 2. Ana Karar Noktası B (KDP-B) Program Odaklı Çevre Güvenliği ve İş Sağlığı Değerlendirmesi (PESHE) uyum hedeflerini, KDPA'da başlatıldığı şekliyle IAW uygun standartlarını tamamlamak için, her biri için iç ve dış operasyonel ortamların değerlendirilmesi de dahil olmak üzere, yeterli veri derlenir. tasarım konsepti 3. Kritik insan sağlığı ve güvenliği faktörleri belirlenir ve sistem güvenlik programı mimarisine dahil edilir 4. Tehlikeli madde yönetimi ve kirlilik önleme görevleri belirlenir ve önceliklendirilir E. Toplu Mülkler 1. Toplu mülkler ve uygun olanlar dahil olmak üzere bir ilk toplu mülk bütçesi oluşturulur. kenar boşlukları 2. Ağırlık artışı, ağırlık merkezi ve atalet momenti tahminleri için parametreler kurulmuş F. Sistem Güvenliği Mühendisliği (SSE), İletişim Güvenliği (COMSEC), Bilgi Güvencesi (IA) ve Program Koruması (PP) 1. SSE, IA, COMSEC ve PP güvenlik gereksinimleri, Savunma Bakanlığı ve AF politikalarına, direktiflerine ve sistem spesifikasyonları sürecine ve planına (yani, DIACAP) uygun olarak tercih edilen her bir tasarım konsepti çözümü için belirlenir. 2. SSE, COMSEC, IA ve PP gereksinimlerinin entegrasyonu tanımlanır 3. Güvenlik SSE, COMSEC ve PP, kurcalamaya karşı koruma uygulamalarına yaklaşır (bir ön güvenlik konsepti, tehdit, güvenlik açığı ve risk değerlendirmeleri, koruma karşı önlemleri ve test ve değerlendirme metodolojisi ve gereksinimleri), tanımlanır 4. Sistem ve veri koruması, kullanılabilirlik, bütünlük, gizlilik ve kimlik doğrulama için ön IA kontrolleri belirlenir ve her tasarım konsepti için reddedilemezlik, DIACAP sertifikasyonu ve akreditasyon gerekliliklerini içerecek şekilde ele alınır, örneğin: 5. “Ağ Merkezli Operasyonlar ve Harp (NCOW) Referans Modeli (RM)” – “NCOW RM” sunuldu 6. KIP uyumluluğu gösterildi 7. İç denetim uyumu gösterildi 8. Tahmini maliyetler ve program hedefleri, aşağıdakiler için programın temel çizgisine dahil edilmek üzere belirlenir: SSE, İSEDAK 9. Sistemin yaşam döngüsü için Program Koruma ve Bilgi Güvencesi önlemleri aktiviteler geliştirildi 10. Bilgi güvencesi için yazılım gereksinimleri eksiksiz ve uygundur; örneğin, bilgi güvence standartları Sistem yazılımı Gereksinimlerine dahil edilmiştir 11. İlişkili Sertifikasyon ve Akreditasyon zaman çizelgeleri oluşturuldu G. Birlikte Çalışabilirlik Sayfa 42 / 168 Machine Translated by Google Ek A 1. Sistem ve görev birlikte çalışabilirlik gereksinimlerini karşılayan Ön DoD Bilgi Standartları Deposu (DISR) standartları belirlenir (yani, DISR uyumlu ve uyumlu olmalıdır) 2. Onaylanmak ve DISR'ye dahil edilmek üzere sunulan seçilen tasarım konsepti için DISR dışında yeni ve benzersiz standartlar önerilir (yani, yeni veri formatları, veri değişim protokolleri ve şemaları, Ethernet alternatifleri) 3. Ön birlikte çalışabilirlik mimarisi gereksinimleri belirlenir 4. Birlikte çalışabilirlik analizi yaklaşımları seçilir H. Güvenilirlik ve Sürdürebilirlik (R&M) 1. Ön R&M gereklilikleri ve özellikleri tanımlanır (örn. görev süresi, Ao ve Do, MTBF, MTTR, arıza modları, tek arıza noktası, fazlalık vb.) 2. Ön R&M analizi gerçekleştirilir ve sonuçlar genel sistem mimarisine beslenir her bir tasarım çözümü konsepti için 3. Çevresel Etkiler Stres Taramasının (EESS) tanımlanmasına yönelik metodolojiler oluşturulmuştur 4. Paketleme, Taşıma, Depolama ve Taşınabilirlik (PHS&T) çevresel gereksinimleri R&M programına dahil edildi I. Elektromanyetik Girişim (EMI) ve Elektromanyetik Uyumluluk (EMC) 1. Aşağıdaki EMI ve EMC hususları her bir tasarım konsepti için ele alınır, örneğin: a. Ön elektromanyetik girişim kontrol yaklaşımları geliştirildi B. Ön dahili ve harici EMI ve EMC gereksinimleri tanımlanır C. Ön EMI duyarlılık gereksinimleri ve kısıtlamaları belirlenir (yani, pasif modülasyon, araç alıcıları ve mühimmat ile verici Radyo Frekans Girişimi (RFI), güç veriyolları üzerinde yayılan etkiler, yıldırım ve aşırı gerilim koruması) D. Ön EMI ve EMC açısından kritik çevresel özellikler ve hassas unsurlar tanımlanmış 2. EMC Kontrol Planında ele alınan tüm önemli alanların bir özeti, program gereksinimlerinin uyarlanması ve eski ekipman ve diğer NDI'ların kullanımı dahil ancak bunlarla sınırlı olmamak üzere 3. Birim seviyesinde EMC gereksinimleri doğrulama planlamasının bir özeti 4. EMC personel planı 5. Tüm risk alanları ve risk azaltma kapatma planları J. İnsan Sistemleri Entegrasyonu (HSI) 1. Operatörler, kullanıcılar, bakımcılar ve sürdürücüler için kullanıcı arabirimi donanım ve yazılım gereksinimleri ayrıştırılır ve her tasarım konsepti için türetilir 2. Kullanılabilirlik, sürdürülebilirlik veya desteklenebilirlik gereksinimleri ayrıştırılır ve her tasarım çözümü için sistem gereksinimlerinden türetilir 3. Personel, iş yükü ve beceri düzeyi gereksinimleri ayrıştırılır ve her tasarım konsepti için türetilir, örneğin, alt sözleşme faaliyetlerine aktarılan tüm HSI ile ilgili gereksinimler, standartlar ve standart uygulamalar 4. HSI gereklilikleri eksiksiz ve uygun standartlarla tutarlıdır; örneğin, son kullanıcıların, operatörlerin, bakım sağlayıcıların ve sürdürücülerin tanımı ve tanımı, uygun sözleşme kuruluşu kuruluşlarıyla koordine edilir 5. İnsan Sistemleri Entegrasyonu (HSI) için yazılım gereklilikleri eksiksizdir ve tüm ilgili standartları referans alır (örn. MIL-STD 1472F, DoD İnsan Bilgisayar Arayüzü (HCI) Stil Kılavuzu ve SMC/AXE Rapor No. HMRB-2001-1) Sayfa 43 / 168 Machine Translated by Google Ek A K. İmalat ve Üretilebilirlik 1. Stres yaratan tasarım niteliklerini ve ilgili özel imalat gereksinimlerini (aşırı karmaşıklık, çoklu, çok sıkı toleranslar, hassas montaj, kırılgan bileşenlerin taşınması vb. gibi niteliklerden kaynaklanan) yönlendirecek gereksinimler belirlenir 2. Yeni teknolojiler için üretim ve üretilebilirlik planları tanımlanır L. Yaşam Döngüsü Lojistiği 1. İlk desteklenebilirlik ticaret çalışmaları ve analiz sonuçları da dahil olmak üzere, her bir tasarım çözümü konsepti için ön lojistik yönetimi bilgisi (LMI) eksiksiz ve doğrulanmıştır. 2. Seçilen tasarım konsepti için sistem düzeyinde tasarım faktörleri, aşağıdaki lojistik unsurlar için doğrulanır: tasarım arayüzü, tedarik desteği, test ekipmanı, insan gücü ve personel, eğitim ve öğretim ekipmanı, PHS&T, tesisler, bilgisayar kaynakları, teknik veriler ve bakım planlama, örneğin desteklenebilirlik gereksinimleri ve tasarım faktörleri, her tasarım konsepti için tanımlanır ve CONOPS, ICD ve CDD'ye göre izlenebilir. Aşağıdaki lojistik unsurlar için tasarım faktörleri belirlenir: M. Sistem Emniyeti 1. Ön emniyet risk analizi sonuçları ve hafifletme yaklaşımları dahil olmak üzere, her bir tasarım konsepti için sistem emniyet gereksinimleri belirlenir 2. Ön tehlike analizi tamamlanır ve güvenlik tehlikelerinin ilk listesi, her bir tasarım çözümünün test edilmesi, çalıştırılması ve imha edilmesi 3. Kritik insan sağlığı ve güvenliği faktörleri belirlenir ve sistem güvenlik programı mimarisine dahil edilir 4. İlk tehlikeli madde listesi derlenir ve Ulusal Çevre Politikası Yasası (NEPA) ve Mesleki Güvenlik ve Sağlık Yasası/Yönetim (OSHA) kriterlerine göre önceliklendirilir örn. izin verilen maruz kalma seviyeleri (PEL'ler), toksisite, uçuculuk ve taşınabilirlik N. Risk Değerlendirmesi 1. Riskler tanımlanır, değerlendirilir, kontrol edilir, en aza indirilir ve kabul edilir, yani: A. Seçilen tasarım yaklaşımının ve ilgili azaltma planının teknoloji olgunluk düzeyi B. Tek kaynak öğelerin kullanımı C. Önerilen işten çıkarmaların sayısı ve seviyeleri d. Prototiplerin, yeterlilik testi makalelerinin, test yataklarının ve test döngüsü sayısının kullanımı sonuç programı mülahazaları e. COTS ürünlerinin kullanımı ve desteği O. Kalite Güvencesi 1. Her tasarım konsepti için ön kalite ve ürün güvence gereksinimleri tanımlanır 2. Ön doğrulama, muayene ve test yaklaşımları belirlenir P. Çevresel Kontroller 1. Ön operasyonel çevre çalışmaları tamamlandı 2. Ön çevre kontrol test ve değerlendirme stratejileri geliştirildi 3. Ön çevre kontrol güvenilirlik ticaret çalışmaları ve analizleri tamamlandı S. Yazılım 1. Yazılım Sistem Gereksinimleri, örneğin: A. Yazılım gereksinimleri analizi, işlevselliğin tam olarak tahsis edilmesini içerir Sayfa 44 / 168 Machine Translated by Google Ek A B. Tüm uygun arayüz standartları, yazılım gereksinimlerine dahildir (örn. Uzaydan Yere Bağlantı Seti (SGLS)). C. Güvenilirlik, güvenilirlik, sürdürülebilirlik ve kullanılabilirlik için yazılım gereksinimleri, sistem gereksinimleri analizine ve yazılım ve donanıma yapılan tahsislere dayalı olarak eksiksizdir. D. Desteklenebilirlik için yazılım gereksinimleri, sistem gereksinimlerine göre tamamlandı yazılım ve donanıma analiz ve tahsisler e. Yazılım güvenlik gereksinimleri, sistem gereksinimleri analizine dayalı olarak tamamlandı ve yazılım ve donanıma tahsisler F. Tüm uygun yazılım güvenlik standartları (örn. EWR-127 veya AFSPC Kılavuzu 91-710) sistem gereksinimlerine dahil G. Tüm uygun bilgi güvence standartları, sistem gereksinimlerine dahildir h. Yeniden programlanabilirlik için yazılım gereksinimleri, tüm uygun bilgisayarlar için tamamlanmıştır. kaynaklar Ben. İnsan Sistemleri Entegrasyonu (HSI) için yazılım gereklilikleri eksiksizdir ve tüm uygun standartlara atıfta bulunur (örn. MIL-STD 1472F, DoD HCI Stil Kılavuzu ve SMC/AXE Rapor No. HMRB-2001-1) j. Harici öğelerle birlikte çalışabilirlik için yazılım gereksinimleri eksiksizdir ve tüm uygun birlikte çalışabilirlik ve açık sistem standartlarına atıfta bulunur. k. Kenar boşlukları için yazılım gereksinimleri, tüm bilgisayar kaynakları (örn. bellek ve depolama kapasitesi, işlemci verimi ve iletişim bant genişliği) l. Yazılım gereksinimleri, COTS ürünlerine uygun şekilde tahsis edilir 2. Durumlar ve modlar için yazılım gereksinimleri, sistemden tahsis edildiği şekilde tanımlanır Gereksinimler 3. Bilgi güvencesi için yazılım gereksinimleri eksiksiz ve uygundur, örneğin, bilgi güvence standartları sistem gereksinimlerine dahil edilmiştir 4. Operasyonel Kavramlar, örneğin: A. Sistem operasyonel kavramları, yazılım perspektifinden hem nominal hem de nominal olmayan senaryoları içerir, örneğin, işlemci yük devretme, artıklık yönetimi b. Operasyonlar, bakım ve eğitim ihtiyaçları için yazılım gereksinimleri eksiksizdir c. Sistem operasyonel kavramları, yazılım perspektifinden operasyon ve bakım personelinin, örneğin sayılar, beceriler, roller ve pozisyonların tanımlanmasını içerir d. Desteklenebilirlik için yazılım gereksinimleri eksiksizdir ve hem yazılım hem de donanım 5. Yazılım Metrikleri ve Teknik Performans Ölçütleri oluşturulur, örneğin: A. Ön yazılım metrik planlaması, program ve mühendislik yönetimi için bilgi ihtiyaçlarını karşılamak için yeterlidir. B. Seçilen TPM'ler, işlemciler, bellek, depolama ve giriş ve çıkış kanalları, veri yolları ve ağlar gibi tüm bilgisayar kaynakları için kullanım tahminlerini içerir c. Veri tabanı ve araçlar, ölçümler ve TPM izleme, trend belirleme ve raporlama için seçilir R. Veri Depolama (Güvenlik, Erişim, Dağıtım ve Teslimat) 1. Ön Depolama Sistemi Yeteneği, Esneklik ve Ölçeklenebilirlik gereksinimleri, örneğin: A. Analiz, gerekli güvenilirlik, sürdürülebilirlik ve kullanılabilirlik özelliklerini tanımlar. depolama sistemleri ortamları Sayfa 45 / 168 Machine Translated by Google Ek A B. Beklenen ömrünü destekleyen belirlenen kapasite, esneklik ve genişletilebilirlik parametreleri sistem C. Anahtar sistem bileşenleri ve yedeklilik gereksinimleri, örneğin, depolama ortamı donanım ve yazılım yetenekleri ve türleri belirlenir d. Depolama sistemi yönetim gereksinimleri belirlenir e. Depolama sistemi işletim ortamları tanımlama ve sağlamlaştırma gereksinimleri belirtilmiştir 2. Depolama Sistemi Mimarisi (SSA), örneğin: A. Bir ön depolama sistemi mimarisi, iletişimleri ve işleme kapasitesini tanımlar Gereksinimler B. Bir ön depolama sistemi gereksinimleri belirlenir, örneğin, merkezi depolamaya karşı dağıtılmış depolama; çevrimiçi, yakın hat ve çevrimdışı ihtiyaçlar; arşivleme (uygunsa hiyerarşik depolama yönetimi dahil), yedekleme ve geri yükleme; ve veri çoğaltma c. ön depolama donanım bileşenleri belirlenir, örneğin, RAID, Depolama Alanı Ağları (SAN), Ağa Bağlı Depolama (NAS) ve Doğrudan Bağlı Depolama (DAS), SSA ile tutarlıdır D. örneğin, otomatik dosya taşıma ve şeffaf dosya alma gibi bir ön veri yönetimi yazılımı yetenekleri tanımlanmıştır; hiyerarşik düzeyler arasında geçiş; ve medya kullanımı, hata tespiti ve tanımlama hakkında rapor veren yardımcı programlar 3. Güvenlik, örneğin: a. Sistem gereksinimlerini destekleyen bir ön kullanıcı bütünlüğü düzeyi (örn. erişim kontrol listeleri) belirlenir b. Gerekli bir ön şifreleme düzeyi belirlenir c. CDS, MLS ve Security Enclaves gibi özel güvenlik yeteneklerine yönelik bir ön ihtiyaç belirlenmiş ve sistem gereksinimlerinin karşılanmasını sağlamak için depolama sistemine dahil edilmiştir. 4. Veri Dağıtım Yöntemleri, örneğin: a. Veri alıcılarının ön listesi belirlenmiştir, örneğin bilgisayar ve insan aracıları. B. Veri dağıtmanın ön yöntem(ler)i tanımlanır, örneğin, Abone Ol ve Yayınla, İt ve Çekme ve küresel veya kısıtlı Web tabanlı erişim c. Ön veri dağıtım yöntemleri, depolama mimarisiyle uyumludur 5. İşlevsellik, örneğin: A. Bir ön analiz, desteklemek için gereken işlevselliğin fiziksel yönlerini belirledi. görev B. Ön platform türleri (sunucu ve istemci) ve desteklenen işletim sistemleri şunlardır: tanımlanmış C. Ön veri bağlantısı ve taşıma protokolleri (örn. fiber kanal, sonsuz bant, SWCI) tanımlanır D. Ön raporlama (örn. kullanım) ve bakım metrikleri (örn. MTBF ve MTTR) tanımlanmış e. Metrikler ve sistem düzeyinde gereksinimler arasındaki ön eşleme tamamlandı Sayfa 46 / 168 Machine Translated by Google Ek A 10.4.5 Entegre Teknik Risk Yönetimi ve Azaltma SRR'de entegre bir program (teknik, maliyet, program ve performans) RM ve Hafifletme (RM&M) sürecinin temel bir bileşeni olarak teknik risk yönetimi (RM) süreci olgunluk kriterleri örneklerinin kanıtı. A. Risk belirleme ve risk derecelendirme stratejileri aşağıdaki gibi hususları kapsar: 1. Sistem etkililik analizi, teknik performans ölçümü, amaçlanan üretim yöntemleri ve maliyetler arasındaki karşılıklı ilişki 2. Diğer dış kuruluşlar tarafından sağlanan veya tasarım standartlarının uygulanmasından etkilenen öğeler dahil olmak üzere sistemin, alt sistemin ve bileşenin donanım ve yazılım öğeleri, vesaire. 3. Miras alınan donanım veya yazılım kullanımı 4. Gerçekleştirilmesi gereken dış olaylara bağımlılık 5. Endüstriyel temel, teknoloji geliştirme, mühendislik becerileri ve kaynaklar 6. Azaltma süreçleri ve prosedürleri 7. Takip geliştirme ve düşük oranlı üretim 8. Sistem gereksinimleri, ön sistem fonksiyonel tanımı, ve fonksiyonel ayrıştırma olgunluk ve güven seviyeleri 9. İş geliştirme planlarının Program IMP, IMS ve WBS'ye bağımlılığı 10. Program takvimi, teknik ve fonlama risk değerlendirme sıralaması, izleme ve dokümantasyon yeterlilik 11. Plan ve fonlama riskleri 12. Teknik riskler 13. Risk metriklerinin toplanması, analizi, izlenmesi ve raporlanması için risk yönetimi veri tabanı ve araçları 14. Taslak hafifletme süreçleri ve prosedürleri 15. Sonraki aşamalar için kapsamlı risk değerlendirmesi 16. Anlaşıldığı şekliyle ve sistem tasarım çözümüne entegre edilen sistem gereksinimleri 17 Başlangıç Yetenekleri Belgesi (ICD) veya taslak Yetenek Geliştirme Belgesi (CDD) 18. Sistem gereksinimleri olgunluğu ve güvenilirliği 19. Ön sistem fonksiyonel tanımı ve fonksiyonel ayrıştırma Sayfa 47 / 168 Machine Translated by Google Ek A B. Risk azaltma ve azaltma stratejileri, kaçınma ve kontrol aşağıdaki gibi öğeleri kapsar: 1. Program IMP, IMS ve WBS'ye bağımlılıklarla bağlantılı olan azaltma planları 2. Sürekli risk izleme ve gözden geçirme, tanımlama, değerlendirme ve sıralama 3. Teknoloji ve üretim hazırlık seviyesi (TRL ve MRL) değerlendirmeleri ve ölçümleri katmak: A. Ön (veya ilk 5) program düzeyindeki riskler b. Başlıca riskler için formüle edilmiş ön risk azaltma planı c. Gereksinim risk izleme d. Kritik yazılım sorunlarının yazılım risk yönetimi, örneğin, karmaşıklık, boyut, işlem hızı, verim, programlar, COTS kullanılabilirliği, eski yeniden kullanım uygunluğu ve yazılım geliştirme süreçleri ve araçları Sayfa 48 / 168 Machine Translated by Google Ek B Ek B - Sistem İşlevsel İncelemesi (SFR) 20. Sistem İşlevsel İncelemesi (SFR) SFR, incelenmekte olan sistem tasarım konseptinin ön tasarıma geçmek için yeterince olgun olup olmadığını ve tüm sistem gereksinimlerinin ve işlevsel performans gereksinimlerinin Yetenekten türetildiğini belirlemek için kullanılan çok disiplinli bir teknik ürün ve SE süreç değerlendirmesidir. Tanımlandığı şekliyle Geliştirme Belgesi (CDD): A. Program maliyeti ve bütçe, program, risk, kullanıcı ve/veya diğer kısıtlamalarla tutarlıdır b. Sistem belirtimlerinde (işlevsel temel) ele alınır c. İşlevsel temelde tamamen ayrıştırılır ve tanımlanır ve donanım ve yazılım gereksinimlerini tanımlayabilen alt düzey alt sistem ve CI işlevselliğine kadar izlenir. D. Tercih edilen sistem çözümü için mevcut teknolojilerle tutarlılığı koruyun e. Yüklenicinin ürünlerine ve süreçlerine özgü riskler dahil olmak üzere geliştirme, üretim, doğrulama, konuşlandırma, operasyonlar, destek, eğitim ve elden çıkarma dahil olmak üzere tüm birincil sistem mühendisliği işlevlerini ele alın F. Yönetilebilir riskle program hedeflerini karşılayabilir SFR, sistemin ve EI'nin teknik kapsamını ve riskini ele alacak ve Sistem Mühendisliği Planını doğrulayacak şekilde uyarlanacaktır. SFR, ön tasarım başlamadan önce sistem tasarım konseptinin güvenilir ve uygulanabilir olmasını sağlayan son gözden geçirmedir. 20.1 Genel SFR, sistem tanımlama çabası şu noktaya ilerlediğinde yürütülecektir: A. Sistem mimarisinin işlevsel ve performans özellikleri tanımlanır ve tüm isteğe bağlı tasarım konseptleri tanımlanır B. Sistemin biçim, uyum, işlev, performans (FFFP) ve arayüz (I/F) gereksinimleri optimize edilmiş ve ilgili teknik riskler değerlendirilmiştir. C. Geliştirme, üretim, doğrulama, devreye alma, operasyonlar, destek, eğitim ve imha dahil olmak üzere tüm birincil sistem mühendisliği fonksiyonlarının mühendislik fonksiyonları ele alınmıştır. D. Teknik ve tahsis edilen temel (ABL) gereksinimleri ve bir sonraki çaba aşaması için mühendislik planlamasını üreten sistem mühendisliği süreçleri tanımlanmıştır e. Üretim değerlendirmelerinden kaynaklanan teknoloji olgunluğu sorunları anlaşılır, sorun çözme planları yapılır ve sonraki aşamalardaki üretim mühendisliği gereksinimleri belirlenir Gözden geçirmenin temel unsurları, bunlarla sınırlı olmamak kaydıyla aşağıdakileri içerecektir: A. Sistem ve segment gereksinimlerinin yeterliliği ve bunların donanım ve yazılım kalemlerine ve personele tahsisi B. Sistem mimarisinin sistem ve segment gereksinimlerini karşılama yeterliliği ve kullanıcının İşlem Kavramı C. Sistem ve segment doğrulama planlamasının yeterliliği d. Destekleyici mühendislik analizlerinin yeterliliği e. Gerekli teknolojinin hazır olması f. Mühendislik ve yönetim planlarının ve süreçlerinin yeterliliği g. Kalan sistem ve program risklerinin kabul edilebilirliği Sayfa 49 / 168 Machine Translated by Google Ek B SFR'nin temel amacı, sonraki geliştirme faaliyetlerine devam etmek için artık risk seviyesinin kabul edilebilir olup olmadığını belirlemektir. SFR, geliştirme, üretim, doğrulama, dağıtım, operasyonlar, destek, eğitim ve imha dahil olmak üzere tüm birincil sistem mühendisliği işlevlerini ele alır. 20.2 Amaç SFR, normalde SRR'den sonra yürütülür. SFR'nin amacı: A. Yüklenicinin sistem mühendisliği ve yönetiminin yönünü ve ilerlemesini değerlendirin süreçler B. Yüklenicinin eksiksiz, tutarlı ve teknik olarak sağlam bir sistem, segment ve alt sistem gereksinimleri ve sistem mimarisi seti üzerindeki yakınsamasını değerlendirin SFR şunları onaylar: A. Teknoloji olgunluğu gösterildi ve tasarımın başlamasından önce planlanan risk azaltma çabaları tamamlandı ve sonuçlar önerilen gereksinimlere ve tahsis edilen temele yansıtıldı B. Gereksinim analizi, önerilen gereksinim temel çizgisinin doğru ve kapsamlı olduğu noktaya kadar ilerlemiştir (gerçi belki birkaç Belirlenecek(ler) (TBD), Çözülecek(ler) (TBR) ve Sağlanacak( s) (TBS)(ler)) C. Ön tahsis edilen temel, önerilen gereksinim temel çizgisini yansıtır ve performans, maliyet, program, risk ve gelişimsel büyüme potansiyeli açısından dengelenir D. Karar veri tabanı, gereksinim temel çizgisinin kaynağından ön tahsis edilen temel çizgiye ve herhangi bir öğeden o öğenin gerekçesine kadar iki yönlü izlenebilirliği destekler. e. Gelişen tahsis edilen temel hattın, gereksinim temel hattını tatmin edecek bir tasarıma yol açabileceği değerlendirmesi F. Mevcut olan veya SFR'den sonra kullanılması önerilen ön fiziksel hiyerarşi, planlanmış veya onaylanmış PWBS ve CWBS'nin tümü tutarlıdır. G. Gelişen tasarımın yaşam döngüsü maliyeti, programın karşılanabilirliği ile tutarlıdır kısıtlamalar H. Kalan riskler tanımlanmıştır ve planlananlar bağlamında ele alınabilir. sözleşme ve program faaliyetleri 20.3 Amaç SFR'nin amacı: a. Tahsis edilenlerle ilişkili optimizasyonu, korelasyonu, eksiksizliği ve riskleri değerlendirin. teknik gereksinimler B. Tahsis edilen teknik gereksinimleri üreten sistem mühendisliği sürecini değerlendirin c. Çabanın bir sonraki aşaması için mühendislik planlamasını değerlendirin d. Temel üretim hususlarının belirlendiğini gözden geçirin e. Sonraki aşamalarda üretim mühendisliği için planlamanın ele alındığını doğrulayın Başarılı bir SFR örnek olarak şunları sağlayacaktır: A. Yerleşik bir sistem işlevsel temel çizgisi b. Sistem Geliştirme ve Gösterim (SDD) için güncellenmiş bir risk değerlendirmesi Sayfa 50 / 168 Machine Translated by Google Ek B C. Sistem ve yazılım kritik yolunu içeren güncellenmiş bir program geliştirme çizelgesi sürücüler D. Güncellemeleri olan onaylı bir SWCI SFR'den çıkarılacak en önemli çıkarım, aşağıdaki hususlarda net bir anlayış ve anlaşmadır: A. İncelenmekte olan sistem(ler)in alt düzey performans gereksinimleri tam olarak tanımlanmıştır ve olgun sistem konseptiyle tutarlıdır B. Alt düzey sistem gereksinimleri, üst düzey sistem performansına kadar uzanır ve Yetenek Geliştirme Belgesi C. Sistem performans gereksinimlerinin, alt düzey performans gereksinimlerinin ve tasarım ve geliştirme planlarının ön tasarıma ilerlemek için tatmin edici bir temel oluşturduğunun belirlenmesi 20.4 SFR "Kabul Kriterleri" SFR'de, program risk faktörleri olan tüm ana sistem mühendisliği yönetim unsurları ve faaliyetleri dikkate alınır. SFR'nin amacı şunları tespit etmektir: A. Doğru ve kapsamlı bir gereksinim temeli (RBL) onaylanabilir b. Nihai bir işlevsel taban çizgisi (FBL) oluşturulabilir c. Aşağıdakilere yönelik etkili ve verimli ilerleme kaydedilir: (1) Tüm teknik performans gereksinimlerini karşılamak (2) Olgun teknolojilerin uygulanması ve kullanılması yoluyla riski satın alma (3) TPM'leri izleme, izleme, durum belirleme ve bunlara ulaşma yeteneği (4) İlişkili maliyet ve program hedefleri Her bir kriter, ilgili tüm mühendislik faaliyetlerinin kriteri desteklemek için uygun şekilde yürütüldüğünün sözleşme makamını tatmin edecek şekilde gösterilmesi üzerine başarılı bir şekilde yerine getirilmiş kabul edilecektir. Gözden geçirmeye giriş, yüklenicinin gereklilik kriter öğelerini uygun şekilde ele almasını ve uygulanabilir bir teknik ve program risk yönetimi stratejisi göstermesini gerektirir. İncelemeden başarılı bir şekilde çıkılması, tüm kriter unsurlarının ihale makamını tatmin edecek şekilde gösterildiği anlamına gelir. SFR “Kabul Kriterleri” aşağıdaki beş ana kategori altında düzenlenecektir: 1. Sistem Mühendisliği ve Mimari Geliştirme (20.4.1) 2. Sistem, Segment ve Alt Sistem Tasarımı (20.4.2) 3. Sistem Doğrulama ve Doğrulama (20.4.3) 4. Mühendislik Disiplinleri ve Uzmanlık Mühendisliği (20.4.4) 5. Entegre Teknik Risk ve Azaltma (20.4.5) Bu gözden geçirme, yüklenicinin temel ve üzerinde mutabık kalınan SFR “Kabul Kriterlerini” destekleyen teknik çabasının nesnel kanıtı olacaktır, örneğin: A. Açıklandığı şekliyle sistem işlevsel gereksinimleri, Yetenek Geliştirme Belge. B. Sistemin işlevsel gereksinimleri, sistemin etkinleştirilmesi için yeterince ayrıntılı ve anlaşılırdır. devam etmek için tasarım C. Programın başarılı olması için yürürlükte olan süreçler ve ölçümler yeterlidir d. Riskler biliniyor ve geliştirme için yönetilebilir e. Program programı yürütülebilir (teknik, maliyet ve program riskleri) Sayfa 51 / 168 Machine Translated by Google Ek B F. Program uygun bir şekilde kadrolandırılmıştır g. Onaylanmış işlevsel temeli olan program, mevcut bütçe dahilinde yürütülebilir h. Yüklenicinin önerdiği sistem işlevsel temel çizgisi, mevcut güncellemeyle tutarlıdır. Maliyet Analizi Gereksinimleri Açıklaması (KART) i. Güncellenen maliyet tahmini, mevcut bütçeye uygundur J. Sistem İşlevsel Temel Çizgisi, ön tasarımın devam etmesini sağlamak için oluşturulmuştur. uygun yapılandırma yönetimi k. Onaylanan işlevsel temeldeki yazılım işlevselliği, güncellenen yazılım ölçümleri ve kaynak yüklü program ile tutarlıdır l. Bu incelemeyle ilişkili tüm IMP ve IMS görevleri başarıyla kapatıldı Aşağıdaki bölümler, gözden geçirilecek tüm ilgili mühendislik faaliyetleriyle birlikte, sözleşme ile özel olarak düzenlendiği şekilde, SFR'yi desteklemek için gerçekleştirilmesi gereken asgari, ancak her şeyi kapsamayan kriter listesini ele almaktadır. 20.4.1 Sistem Mühendisliği ve Mimari Geliştirme SFR'deki Sistem Mühendisliği, Mimari Geliştirme ve Tasarım Geliştirme olgunluk kriterleri örnekleri: A. Sistem, segment ve alt sistem fonksiyonel gereksinimleri eksiksiz, uygulanabilir, doğrulanabilir ve açıkça ifade B. KPP'ler, sistem gereksinimleri, CONOPS ve SPD, seçilenlerle karşılaştırılır ve ilişkilendirilir tasarım konsepti ve Gereksinim Tahsis Belgesinde (RAD) ele alınmıştır C. Temel sistem işlevsel gereksinimleri, seçilen tasarım için mimariden türetilir konsept, örneğin: 1. Mimari, beklenen program uyumluluğu seviyesini gösterir, örneğin: A. Temel sistem modellemesi ve seçilen sentez metodolojisi kanıtlanmış uygulamalara dayalıdır b. Sistem, segment ve alt sistem işlevsel gereksinimleri (yani, dahili ve harici) konfigürasyon yönetimi altındadır ve ön tasarıma devam etmek için yeterince olgunlaşmıştır. 2. Seçilen Sistem, Sistemler Sistemi ve Sistem Ailesi tasarımı için mimari görünümler kavram, türetilmiş KPP'lere kadar açıkça izlenebilir, örneğin: a. Sistem mimarisi, seçilen tasarım konseptinin sistem, segment, alt sistem ve arayüz gereksinimlerini ve yüklenicinin operasyonel konseptlerini tam olarak uygular. B. Seçilen tasarım konsepti için mimari uygulanabilir ve genişletilebilir 3. Seçilen tasarım konsepti için bir mimari görünüm(ler) oluşturulur, örneğin: A. Gerekli sistem görünümü/görünümleri belirlenir ve kurulur, sistemler ve operasyonel ihtiyaçlara yönelik özellikler B. Sistem bileşenleri ve unsurları ile organizasyon sahipleri ve operatörler tarafından temel fonksiyonel performans gereksinimlerini tanımlayan gerekli operasyonel görünüm(ler) belirlenir ve oluşturulur. C. Seçilen tasarım çözümü konseptini uygulamak için gerekli standart tanımları ve kuralları oluşturarak gerekli teknik standart görünüm(ler) belirlenir ve tamamlanır. Sayfa 52 / 168 Machine Translated by Google Ek B D. Sistem tasarım konsepti, mühendislik ticaret alanı, teknik gereksinimler, sistem performansı, riskler (teknik, programatik, program, maliyet), LCC ve CAIV ticaret analizi vb. bağlamında seçilmiştir, örneğin: 1. Anahtar teknik ve seçilen sistem tasarım konsepti için geliştirilen ve türetilen programatik ayrıntılar, örneğin, yüklenicinin operasyonel konseptleri tam olarak uygulanır ve tüm program yaşam döngüsü için kullanıcının güncellenen Operasyon Konsepti (CONOPS) ile tutarlıdır 2. Yüklenicinin güncellenen operasyonel konseptleri, sistem ve segment ile tutarlıdır ve arayüz gereksinimleri temel alınmıştır ve konfigürasyon yönetimi altındadır 3. Önerilen sistem tasarım konsepti için birlikte çalışabilirlik işlevsel gereksinimleri tanımlanır ve performans tahsisleri oluşturulur, örneğin: a. Seçilen tasarım için nihai birlikte çalışabilirlik performansı ve tasarım parametreleri ve sürücüleri kavramın gereksinim analizinden türetildiği gösterilmiştir B. Ticaret çalışmalarının sonuçlarının seçilen sistem tasarımı temel çizgisine entegre edildiği gösterilmiştir ve model C. Gösterilen birlikte çalışabilirlik gereklilikleri ve işlevsel performans kriterleri, seçilen tasarım konseptine dahil edilir d. Askerden arındırma ve EOL'de imha etme gereklilikleri, sistem tasarımına entegre edilmiştir taban çizgisi E. Sistem harici arayüzleri tanımlanır ve işlevsel performans arayüzü (hem dahili hem de harici) gereksinimler seçilen tasarım konsepti için geliştirilir, örneğin: 1. Sistemden sisteme, segmentten segmente, alt sistemden alt sisteme ve bileşenden bileşene işlevsel arayüz analizleri tamamlanır 2. Bölümler arası ve alt sistemler arası arabirim gereksinimleri, Sistem Performansı ve Bölüm ve Alt Sistem Spesifikasyonları ile tutarlıdır ve bunlara atıfta bulunulmuştur. 3. Seçilen sistem için iç ve dış sistemlere etkiler ve sistem gereksinimleri belirlenir. tasarım konsepti 4. Sistem ve harici arayüz işlevsel gereksinimleri, aşağıdakiler dahil tüm sözleşme hükümlerini karşılar: seçilen tasarım konsepti için uyumlu spesifikasyonlar ve standartlar, örneğin: a. Bölüm, bölümler arası, alt sistem ve alt sistemler arası gereksinimler, uyumlu tüm spesifikasyonları ve standartları karşılar b. Geliştirilen Ön Fonksiyonel Akış Blok Diyagramları (FFBD'ler), daha yüksek ve daha düşük seviye gereksinimler arasındaki akışı ve izlenebilirliği gösterir. F. Görev ve Sistem İşlevsel Gereksinimleri Temel Çizgiler, seçilen tasarıma göre belirlenir kavram, örneğin: 1. Misyon ve sistem gereksinimleri ana hatlarının oluşturulmasını destekleyen yeterli sayıda doğrulanmış teknik bilgi mevcuttur 2. Tasarım konseptine göre FBL seçilir; tüm KPP ve sistem performansı ve spesifikasyon gerekliliklerini karşılamaya yeterli ayrıntılar, örneğin, gereksinim akışı ticari araştırmalar ve sistemden segmente, alt sisteme ve bileşenlere kadar analizler eksiksiz ve kabul edilen ticari sonuçlara göre izlenebilir G. Yaşam döngüsü maliyeti (LCC) ve bağımsız değişken olarak maliyet (CAIV) değerlendirmesi, seçilen tasarım konsepti ve işlevsel temel, örneğin: 1. YDD ve CAIV modellemesi ve seçilen tasarım konsepti ve işlevsel temel ile uygulanan ve ilişkilendirilen analizler, örneğin, öngörülen program geliştirmeyi temsil eden maliyet modelleri, öngörülen maliyet dahil işletim ve idame maliyetlerinin tamamlanması diğer “harici” sistemlere olan etkiler Sayfa 53 / 168 Machine Translated by Google Ek B H. Seçilen tasarım konseptinin sistem KPP'lerine ve sistem ticaret çalışmalarına izlenebilirliği açıkça gösterilmiştir. gösterilmiştir, örneğin: 1. KPP'ler ve ticari çalışma analizi için seçilen tasarım konseptinin izlenebilirliği ve korelasyonu sonuçlar gösterildi 2. Sistem gereksinimleri ve harici arabirim işlevsel gereksinimleri, sözleşme Sistem Performansı Spesifikasyonu, segment ve alt sistem spesifikasyonları ve kullanıcının Yetenek Geliştirme Belgesi (CDD), örn. segment, segmentler arası, alt sistemler ve alt sistemler arası arayüz gereksinimlerine göre izlenebilir ve tam olarak uygulanır izlenebilir ve sistem ve harici arayüz işlevsel gereksinimleri uygular 3. Seçilen tasarım konsepti için sistem ve harici arayüz fonksiyonel gereksinimleri temel alınmıştır ve konfigürasyon yönetimi altındadır I. Seçilen tasarım konsepti için geliştirilen Sistem Performans Spesifikasyonu, hem gereksinimlere hem de fonksiyonel temellere göre izlenebilir, örneğin: 1. Segment ve alt sistem spesifikasyonları ön olarak tanımlanır ve Sisteme göre izlenebilir Performans Spesifikasyonu 2. Modelleme ve simülasyon yeteneği planlama ve çizelgeleme sistem ile senkronize edilir, segment, alt sistem ve arayüz tasarımı geliştirme planları ve çizelgeleri 3. Sistem düzeyinde doğrulama çapraz referansı ön olarak tanımlanır ve seçilen tasarım konseptinin doğrulama metodolojisine göre izlenebilir J. Seçilen tasarım için sistem entegrasyonu ve doğrulama gereksinimleri analizleri tamamlandı kavram, örneğin: 1. Doğrulama hedefleri, türleri, seviyeleri ve doğrulama dizisi ve toplanacak doğrulama verileri için gerekçe ile tamamlanan sistem düzeyinde doğrulama planlaması K. Seçilen tasarım için teknik ve işlevsel ana hatların bir ön tahsisi tanımlanır konsept, örneğin: 1. Seçilen tasarım konsept sistemi, segmentleri ve alt sistemleri için ön tahsis temel çizgisi, mühendislik ticareti değerlendirmeleri ve risk çalışması sonuçlarıyla ilişkilendirilir 2. Tüm ön Donanım Yapılandırma Öğesi (HWCI) ve Yazılım Yapılandırma Öğesi (SWCI) açıklamaları geliştirildi 3. Tüm ön HWCI'ler ve SWCI'ler spesifikasyon gereklilikleri tanımlanmıştır ve şunlara göre izlenebilirdir: sistem performans belirtimi 4. Tüm yazılım bileşenleri (taktik, destek, teslim edilebilir, teslim edilemez vb.) önceden tanımlanmıştır ve sistem performans spesifikasyonuna göre izlenebilirdir 20.4.2 Sistem, Segment ve Alt Sistem Tasarımı Sistem, Segment ve Alt Sistem Tasarım Kavramlarının Kanıtı olgunluk kriteri örnekleri SFR'de: A. Seçilen tasarım konsepti için sistem, segmentler ve alt sistemler oluşturulur ve ana ve kritik performans parametreleri temel alınır 1. Seçilen tasarım konsepti, tüm hususlar arasında izlenebilirliği gösterir, örneğin: A. Performans gereklilikleri B. Mühendislik ticaret alanı, teknoloji durumu ve eksiklikleri ile teknik, programatik, program ve maliyet riskleri C. Seçilen tasarım konseptinin yeterliliği, tüm ilgili özel mühendislik disiplinleri dahil olmak üzere mühendislik analizi kullanılarak kanıtlanmıştır ve TPM'ler ve KPP'ler ile tutarlıdır, örneğin: Sayfa 54 / 168 Machine Translated by Google Ek B (1) Mühendislik analizi, işlevsel gereksinimlerin donanım ve yazılım öğelerine ve personele tahsis edilmesinin sistem gereksinimlerini karşılayacağını yeterince göstermiştir. (2) Mühendislik analizi, tasarımın ilerlemeye hazır olduğunu yeterince gösterdi. 2. Seçilen tasarım konsepti için sistem risk modelini oluşturan sistem performans parametreleri, özellikleri, tasarım zorlukları ve risk değerlendirmeleri, konfigürasyon yönetimi altındadır. seçilmiş tasarım konsepti B. C4I gereksinim analizi sonuçları ve alt sistem ve bileşenler arasında tahsis işlemi tamamlanır ve seçilen sistem tasarım konseptine göre izlenebilir, örneğin: 1. Seçilen tasarım konsepti için C4I stratejisi savaş yönetimi ve bilgi teknolojisi (BT) ihtiyaçları ve sistem alt sistemleri ile sistem, sistemler sistemi ve sistem ailesi arasındaki bağımlılıklar için çözüm 2. Ağ merkezli (ör. ağ) ticaret çalışması sonuçları, seçilen tasarım konsepti için mimari ve bilgi ortamlarını gösterdi 3. C4I gereksinimlerinin birlikte çalışabilirliği, karşılıklı bağlantıyı, desteklenebilirliği, senkronizasyonu ve yeterliliği sağladığını gösterin; örneğin, performans kriterleri seçilen sistem tasarım konseptine dahil edilir ve bölümler, alt sistemler ve bileşenler arasında tahsis edilir C. Tehdit senaryoları ve tehdit ortamları başlangıçta tanımlanmış veya çevrelenmiş ve bunlarla ilişkilendirilmiştir. seçilen sistem tasarım konsepti, örneğin: 1. Tehdit senaryoları ve ortamları tanımlanır ve doğrulanır 2. Performans parametreleri tanımlanır ve seçilen sistem tasarım konseptine göre izlenebilir ve bilinen ve tanımlanmış tehditlere 3. Tehdit senaryosu operasyonel ve çevresel kriterlerinin seçilen sistem tasarım konseptine dahil edildiğini ve bölümlere, alt sistemlere ve bileşenlere tahsis edildiğini gösterin D. Ortamlar (ör. doğal ve moloz, şok, titreşim, termal, nem, vakum) tanımlanır ve seçilen sistem tasarım konseptiyle ilişkilendirilen parametreler ör.: 1. Bilinen kaynak (örn. benzer sistemler) verilerinden elde edilen çevresel parametreler ve kanıtlanmış metodoloji kullanılarak sistem fonksiyonel analizleri, örn., doğrulanmış çevresel modeller ve simülasyonlar 2. Çevresel parametrelerin seçilen sistem tasarım konseptine dahil edildiğini ve bölümlere, alt sistemlere ve bileşenlere tahsis edildiğini gösterin E. Güvenilirlik, kullanılabilirlik, sürdürülebilirlik ve test edilebilirlik (RAM&T) gereksinimleri ve seçilen tasarım konseptiyle ilişkili tasarım faktörleri, örneğin, RAM&T tasarım kriterlerinin seçilen tasarım konseptine dahil edildiğini ve bölümlere, alt sistemlere ve bileşenlere tahsis edildiğini gösterir F. Anahtar performans parametreleri de dahil olmak üzere sistem operasyonel sürdürme stratejisi tanımlanır; desteklemeye yönelik tasarım sürücüleri, tüm ana sistem ve program gereksinimleri dahil olmak üzere seçilen tasarım konseptine entegre edilmiştir, örneğin: 1. Seçilen sistem tasarım konsepti için önemli sistem performansı gerekliliklerini temel almak için kullanılan sürdürülebilirlik ticaret çalışması sonuçları, program gerekliliklerine ve CONOPS'a göre izlenebilir 2. LCC destekleme modeli, seçilen tasarım konseptiyle ilişkilidir G. Seçilen tasarım konseptine ulaşmak için geliştirme stratejisi Teknoloji Hazırlık Düzeyleri (TRL'ler) uygulandı, örneğin, risk azaltma stratejileri geliştirildi ve seçilen tasarım konsepti için kaynak gereksinimleri de dahil olmak üzere sistem risk modeline entegre edildi Sayfa 55 / 168 Machine Translated by Google Ek B H. Endüstriyel Temel (IB) değerlendirme sonuçları, seçilen sistem tasarım konsepti, risk alanlar tanımlanır ve önceliklendirilir ve azaltma stratejileri tanımlanır, örneğin: 1. Tanımlanmış ve örtük risk alanlarıyla ilişkilendirilen IB değerlendirme verileri 2. Kaynaklar ve program gereklilikleri dahil olmak üzere planlanmış ve uygulanmış hafifletme stratejileri I. Seçilen sistem tasarım konseptinin ana alt sistemleri ve Bileşenler temel alınır: 1. Tüm ana alt sistemler ve bileşenler, seçilen sistem tasarım konseptine göre izlenebilir ve eski sistemlerin, bileşenlerin ve teknolojinin yanı sıra diğer yeni tasarımların kullanımını tanımlar. 2. Anahtar parametreler ve bilgiler her ana alt sistem için geliştirilir ve değerlendirilir ve seçilen sistem tasarım konseptinin bileşeni, örneğin: a. Başlıca performans parametreleri belirlenir b. Eksiklikler de dahil olmak üzere kritik teknolojiler belirlenir c. Kritik tasarım ve üretim gereksinimleri ve zorlukları belirlenir Not: Aşağıdaki örnekler, SFR'de ele alınması beklenen veri türleri ve ayrıntı düzeyine açıklık getirmeyi amaçlamaktadır. Yüklenicinin, geliştirilen sistem tipine uygun alt sistemleri ve bileşenleri ve önerilen sistem konseptini ve teknik, maliyet ve program parametrelerini etkili bir şekilde değerlendirmek ve değerlendirmek için gerekli olan her bir alt sistem ve bileşen için uygun kriterleri belirlemesi amaçlanmaktadır, örneğin: Elektrik Güç Sistemleri İçin • Elektrik Güç Dağıtım Sistemi (EPDS) performans gereksinimleri, özellikleri ve işletim kriterleri, güç bütçeleri, güç talebi (marjlarla birlikte) ve çalışma modları (sıklık ve süre) dahil olmak üzere seçilen sistem tasarım konsepti için geliştirilir ve temel alınır. • Seçilen tasarım konsepti için doğrulanmış özel teknolojileri ve topolojileri dahil olmak üzere güç kaynağı kaynaklarının tip(ler)inin seçimi • Türetilmiş pil ömrü gereksinimleri (BOL ve EOL) ve seçilen tasarım konsepti için temel alınan ayrıntılı pil tasarımını etkileyebilecek diğer tüm benzersiz gereksinimler • Seçilen tasarım konsepti için sağlanan pil hücresi teknoloji(ler)i seçim(ler)i; pil mimarileri (hiyerarşi ve sistem tasarım konsepti performans kriterlerine göre izlenebilirlik dahil) Yazılım için • Seçilen sistem tasarım konsepti için SWCI düzeyine göre yazılım mimarisi tanımlanmıştır • SWCI harici ve dahili arayüzleri tanımlanır • SWCI'lara yazılımla ilgili segment gereksinimleri tahsisi tanımlanır • Seçilen tasarım konsepti için işleme kapasitesi ve üretim gereksinimleri doğrulanır çözüm • Yeniden programlanabilirlik kriterleri ve yeteneği, seçilen sistem tasarım konsepti ile ilişkilendirilir ve bu konsept için doğrulanır. • Seçilen tasarım konseptinin yazılım mimarisini ve hiyerarşisini yansıtmak için bir ESLOC tahmini geliştirilir ve tasarım konseptinin yazılım performans gereksinimlerine göre izlenebilirlik gösterilir. • Ön yazılım bakım planı tamamlandığında yazılım bakımı, program lojistik planını destekler Sayfa 56 / 168 Machine Translated by Google Ek B • Yazılım risk yönetim planı tamamlandı. yazılım risk yönetimi aracı uyumlu olacaktır program risk yönetimi araçlarıyla • Seçilen sistem tasarımı için yazılım risk yönetimi ve azaltma süreçleri doğrulanır kavram 20.4.3 Sistem, Segment ve Alt Sistem Doğrulama ve Sistem, Segmentler ve Alt Sistem Tasarım Konseptlerinin Onaylanması V&V gereksinimleri SFR'deki olgunluk kriterleri örnekleri: A. Sistem V&V stratejileri, kavramları ve metodolojileri, önerilen tasarım konsepti için doğrulanır kabul gerekçesi ile çözüm: 1. Başlıca sistem performansını göstermek ve doğrulamak için oluşturulan konsept stratejileri tasarlayın gereksinimler ve parametreler, örneğin: a. V&V stratejisi ve metodolojisi, seçilen tasarım konsepti için sistem, segment ve alt sistem ve bileşen düzeyinde doğrulama yaklaşımlarını ele alır b. V&V stratejisi ve metodolojisi, seçilen tasarım konsepti için analitik, modelleme ve simülasyon ve test stratejilerini ve tekniklerini ele alır, örneğin: (1) Analitik, modelleme ve simülasyon (M&S) ve test etme (2) Yeni teknoloji yeterlilik uygulamalarının, sistem(ler)inin kullanımı ) düzeyinde gösteriler ve testler (3) Seçilen tasarım konsepti ve desteği için harici organizasyonlar ve/veya tesisler ve kaynak gereksinimleri (4) Kanıtlanmış uygulamaların kullanımları referanslarla tanımlanır 2. Güncellenmiş sistem VCRM'si eksiksizdir ve sistem gereksinimleri ve harici arabirim gereksinimleriyle uyumludur, örneğin: a. Segment ve alt sistem VCRM'leri eksiksiz, segment ve alt sistemle tutarlı b. Gereksinimler sistem VCRM'sine göre izlenebilir C. Güncellenen sistem VCRM'si ve segment ve alt sistem VCRM'leri temel alınır ve yapılandırma yönetimi altındadır d. Sistem, segment ve alt sistem VCRM'lerindeki doğrulama yöntemleri, sistemi, segmentleri ve alt sistemleri doğrulamak için yeterlidir B. Seçilen tasarım konsepti için Sistem, Segment ve Alt Sistem operasyonel işlevleri ve ortamları tanımlanır ve yüklenicinin operasyon konseptine göre izlenebilir ve İşlevsel Temel: 1. Sistem V&V test ortamları tanımlanır ve seçilen tasarım konsepti için sistem performans spesifikasyonuna göre izlenebilir 2. Çevresel parametrelerin, seçilen tasarım konsepti için doğrulama stratejileri ve metodolojisi ile ilişkili olduğunu gösterin C. Seçilen sistem tasarım konsepti ve geliştirilen uygulama stratejisi için DT&E öğeleri tanımlanır D. OT&E gereksinimleri analizleri tamamlanır ve test kriterleri tanımlanır (AF ile bağlantılı olarak) Operasyonel T&E ticaret çalışması sonuçlarına göre izlenebilir seçilen sistem tasarımı konsepti için Operasyon Testi ve Değerlendirme Merkezi (AFOTEC)) tasarım konsepti 3. Program teknik, maliyet veya program parametrelerini etkileyebilecek kaynak ve program gereksinimleri ve sorunları belirlenir, örneğin: Sayfa 57 / 168 Machine Translated by Google Ek B A. Test yataklarının ve test tesislerinin gereksinimleri ve mimarisi belgelenir ve seçilen tasarım konseptinin sistemi, segmenti ve alt sistemi ve arayüz gereksinimleri doğrulaması (V&V) için uygun olduğu kanıtlanmıştır. B. Kritik donanım ve yazılım öğeleri için V&V kaynakları (ör. simülatörler, test yatakları, test tesisleri) belirlenir ve bunların geliştirilmesi veya satın alınması için planlar ve çizelgeler mevcuttur. E. Seçilen tasarım konsepti için bugüne kadar toplanan test gereksinimleri ve test verileri, V&V çapraz referans matrisleri (VCRM'ler) tarafından tanımlanan spesifikasyonlar yoluyla operasyonel gereksinimlere göre izlenebilir, örneğin, temsili sistem modellerini ve simülasyonları gerçeğe bağlamak için karşılaştırmalı test verilerinin kullanılması dünya ortamları ve sistem işlevsel performans gereksinimleri F. V&V risk alanları ve azaltma stratejileri, seçilen tasarım konsepti için temel alınır: 1. Seçilen tasarım konsepti için teknoloji eksikliklerine dayalı olanlar da dahil olmak üzere V&V testi eksiklikleri belirlenir ve karakterize edilir 2. Aşağıdakileri içeren risk azaltma stratejileri geliştirilir ve sistem risk modeline entegre edilir: seçilen tasarım konsepti için kaynak gereksinimleri 20.4.4 Mühendislik Disiplinleri ve Uzmanlık Mühendislik Mühendislik Disiplin ve Uzmanlık Mühendislik Kanıtı tanımlama ve değerlendirme olgunluk kriterleri örnekleri (aşağıda A'dan R'ye kadar listelenen kategoriler) SFR'de, örneğin: 1. Anahtar performans gereksinimleri 2. Anahtar performans parametreleri 3. Eski sistemlerin, bileşenlerin ve teknolojinin kullanımı 4. Yeni tasarımların kullanımı A. Parçalar, Malzemeler ve Süreçler (PM&P) 1. Seçilen tasarım konsepti için PM&P fonksiyonel gereksinimleri doğrulanır 2. Seçilen sistem tasarım konsepti için parça performansını etkileyen ortamların ve çevresel parametrelerin değerlendirilmesi tamamlanır 3. Önerilen tasarım çözümü için parça mühendisliği tasarım stratejisi, risk değerlendirmeleri, teknolojiler, tedarik kaynakları ve parçaların ortak kalite seviyeleri (yani güvenilirlik) dahil olmak üzere seçilir B. Test ve Değerlendirme (T&E) 1. T&E stratejisi başlangıçta, tasarım ve belirtilen gereksinimlerle uyumluluğu sağlamak için tüm test hedeflerini, test ortamlarını ve test kaynaklarını gösteren seçilen tasarım çözümü konseptiyle ilişkilendirilerek geliştirilir. 2. T&E metodolojisi/metodolojileri, seçilen tasarım konseptiyle ilişkilidir; örneğin, test metodolojisi/metodolojileri, sistem teknik gereksinimlerinin doğrulanması için kritik olan sistem bileşenleri için tüm test yaklaşımlarının ana hatlarını çizer ve özellikler, etkililik(ler) ve marjlara göre uyarlanır her belirli test öğesinin 3. Seçilen sistem tasarım konsepti için veri toplama, indirgeme ve analiz için test ve doğrulama metodolojisi, test ortam(lar)ı, gerçekleştirilecek işlemler ve prosedürler, veri toplama gereksinimleri, dokümantasyon, analiz yöntemleri ve geçiş dahil olmak üzere doğrulanır. -başarısızlık (yani başarı) kriterleri, örneğin: a. Entegrasyon ve doğrulama test planlamasının değerlendirilmesi b. Dinamik ortam testi için birimden sistem düzeyine entegrasyon ve test planı C. Sistem ve alt sistem gereksinimlerinin değerlendirilmesi için gerekli geliştirme testlerinin belirlenmesi Sayfa 58 / 168 Machine Translated by Google Ek B D. Doğrulama planlamasının sistem ve segment seviyelerinde yeterli olduğuna dair güvence e. Test tesislerinin seçimi C. Beka Kabiliyeti ve Hassasiyet 1. Seçilen tasarım konsepti ve KPP'ler için beka kabiliyeti ve güvenlik açığı tehdidi değerlendirmeleri, değerlendirilen her tehdit için, beklenen tehdit kategorilerini, tehdit ortamlarını ve bunların meydana gelme olasılıklarını tanımlayarak doğrulanır. 2. Her tehdit için izin verilen marjları belirlemek üzere seçilen sistem tasarım konsepti için sistem ve tehdit etkileşim analizleri yapılır değerlendirilen her tehdidi azaltmak için tasarım konsepti çözümü D. Çevre Güvenliği ve İş Sağlığı (ES&OH) 1. Seçilen tasarım konsepti için yaşam döngüsü ortamları, gerekçelerle tam olarak tanımlanır ve sistem gereksinimleri temel çizgisine ve performans kriterlerine göre izlenebilir 2. Program Odaklı Çevre, Güvenlik ve İş Sağlığı Değerlendirmesi (PESHE) uyum hedeflerini tamamlamak için derlenen veriler, seçilen sistem tasarım konsepti için doğrulanır 3. Tehlikeli madde yönetimi ve kirlilik önleme görevleri belirlenir ve seçilen sistem tasarım konsepti 4. Tehlikeli maddelerin çevre ve sağlık değerlendirmeleri yapılmıştır. E. Kütlesel Özellikler 1. Kütlesel özellikler büyüme tahsisleri ve metrikleri dahil olmak üzere, seçilen sistem tasarım konsepti için bir kütlesel özellikler bütçesi doğrulanır 2. Ağırlık artışı, ağırlık merkezi ve atalet momenti tahminleri için parametreler doğrulandı seçilen sistem tasarım konsepti için F. Sistem Güvenliği Mühendisliği (SSE), Bilgi Güvencesi (IA), İletişim Güvenliği (COMSEC) ve (SFR) için Program Koruması (PP): 1. Gereksinimlerin seçilen tasarım konseptine uygulanması IAW DoD ve AF politikaları, direktifleri ve sistem spesifikasyonları doğrulanır 2. Program koruma önlemleri için tasarım uygulaması, seçilen sistem tasarım kavramları ve SSE, IA ve COMSEC gereksinimlerini içerir 3. Sistem güvenliği yaklaşımları, bir satın alma ekibini, bir güvenlik belirtimini ve güvenlik konsepti güncellemelerini, tehdidi, güvenlik açığını ve risk değerlendirmelerini, koruma karşı önlemlerini ve güvenlik testi ve değerlendirme gerekliliklerini içerir. 4. DIACAP kullanarak belgelendirme ve akreditasyon dahil olmak üzere Bilgi Güvencesi ve COMSEC yaklaşımları, seçilen tasarım için yeterli adres sistemi ve veri koruması, kullanılabilirlik, bütünlük, gizlilik, kimlik doğrulama ve reddedilmeme 5. SSE, COMSEC, Program Koruma ve Bilgi için program temel maliyet tahminleri Güvence uygulaması ve sürdürülmesi rafine edildi G. Birlikte Çalışabilirlik 1. Seçilen tasarım konsepti için seçilen DoD Bilgi Standartları Deposu (DISR) standartlarının, sistem ve görev birlikte çalışabilirlik gereksinimlerini karşıladığı gösterilmiştir (yani, DISR uyumlu ve uyumlu olmalıdır) 2. Seçilen tasarım konsepti için önerilen DISR dışındaki yeni ve benzersiz standartlar, onay ve DISR'ye dahil edilmek üzere sunulur (yani, yeni veri formatları, veri değişim protokolleri ve şemaları, Ethernet alternatifleri) Sayfa 59 / 168 Machine Translated by Google Ek B 3. Seçilen sistem tasarım konsepti için birlikte çalışabilirlik mimarisi gereksinimleri tanımlanır 4. Seçilen tasarım konsepti için birlikte çalışabilirlik analizleri tamamlanır ve sonuçlar kullanıcıya gösterilir. uyumluluk sağlamak ve kullanıcılar ile operatörler arasındaki karşılıklı ilişkileri tanımlamak H. Güvenilirlik, Bağımlılık ve Sürdürebilirlik (RD&M) 1. R&M gereklilikleri ve özellikleri, seçilen tasarım konsepti (yani, Ortalama Görev Süresi (MMD), Kullanılabilirlik (Ao) ve Güvenilirlik (Do), MTBF, MTTR, arıza modları, tek arıza noktası) için gerekliliklerle ilişkilendirilir ve bunlara göre doğrulanır. fazlalık vb.) 2. R&M analizleri tamamlanır ve seçilen tasarım konsepti için sonuçlar genel sistem mimarisine beslenir, örneğin: A. Çevresel ve termal stres taramasının (ESS ve TSS) tanımlanmasına yönelik metodolojiler şunlardır: seçilen tasarım konsepti için temellendirilmiş ve onaylanmış B. Paketleme, elleçleme, depolama ve taşınabilirlik (PHS&T) çevresel gereklilikleri temel alınır ve seçilen tasarım konsepti için R&M programına dahil edilir 3. Güncelleme sistemi mimarisi için işlevsel bir FMECA sağlanmıştır, örneğin, kabul testi ve entegrasyon testi ile ADR'yi desteklemek için ölçüm parametrelerini ve anormal limitleri belirleyin I. EMI ve EMC 1. Elektromanyetik girişim kontrol yaklaşımları, seçilen tasarım konsepti 2. Dahili ve harici EMI ve EMC gereklilikleri, seçilen sistem için temel alınır ve doğrulanır. tasarım konsepti 3. EMI duyarlılık gereklilikleri ve kısıtlamaları, seçilen tasarım konseptiyle ilişkilendirilir ve doğrulanır (örn. pasif modülasyon, araç alıcıları ve mühimmatlı verici RFI'si, güç otobüsleri üzerinde yayılan etkiler, yıldırım ve aşırı gerilim koruması) 4. EMI ve EMC kritik çevresel özellikleri ve hassas unsurları temel alınır ve seçilen tasarım konsepti J. İnsan Sistemleri Entegrasyonu (HSI) için onaylanmıştır 1. Operatörler, kullanıcılar, bakımcılar ve servis sağlayıcılar için kullanıcı arabirimi donanım ve yazılım gereksinimleri destekleyiciler seçilen tasarım konseptine tahsis edilir 2. Kullanılabilirlik, bakım yapılabilirlik, çalıştırılabilirlik ve/veya desteklenebilirlik gereksinimleri, sistem fonksiyonel gereksinimleri ve seçilen tasarım konseptine tahsis edilmiş 3. Seçilen tasarım için operasyonel personel, iş yükü ve beceri seviyesi gereksinimleri tahsis edilir kavram 4. HSI ile ilgili tüm gereksinimler, standartlar ve standart uygulamalar, tüm alt seçilen tasarım konsepti için taahhüt faaliyetleri 5. Önceden belirlenmiş gereksinimler için HSI standartları, seçilen tasarım konseptine dahil edilir K. İmalat ve Üretilebilirlik 1. İmalat ve üretilebilirlik mühendisliği çalışmaları tamamlanmış; türetilen sonuçların uygulanması, seçilen tasarım konseptini tatmin edecek şekilde gösterilir, örneğin, en iyi yöntem, çalıştırma talimatları, montaj yardımcıları, aparatlar ve fikstür tasarımları, kısa aralık çizelgeleri, fabrika ve tezgah yerleşimi 2. Seçilen tasarım konsepti için üretilebilirlik ticaret araştırmaları, seçilen üretim süreçlerinin tasarım konseptini karşıladığını göstermektedir. 3. Seçilen tasarım konsepti için elde edilen üretilebilirlik analizi sonuçları, uygun maliyetli, üretilebilir ve test edilebilir ürün tasarımı Sayfa 60 / 168 Machine Translated by Google Ek B L. Yaşam Döngüsü Lojistiği 1. Seçilen tasarım konsepti için desteklenebilirlik gereksinimleri ve tasarım faktörleri doğrulanır 2. Seçilen tasarım konsepti için sistem düzeyinde tasarım faktörleri aşağıdaki lojistik unsurlar için doğrulanır: tasarım arayüzü, tedarik desteği, test ekipmanı, insan gücü ve personel, eğitim ve öğretim ekipman, PHS&T, tesisler, bilgisayar kaynakları, teknik veriler ve bakım planlaması 3. Lojistik yönetimi bilgileri (LMI), seçilen tasarım konsepti için FBL'yi desteklemek üzere tamamlanır ve doğrulanır ve güncellenmiş tüm desteklenebilirlik ticari çalışmaları ve analiz sonuçlarını içerir. M. Sistem Güvenliği 1. Sistem güvenliği risk analizi sonuçlarının iyileştirilmesi ve hafifletme yaklaşımlarının yeniden değerlendirilmesi dahil olmak üzere, seçilen sistem tasarım konsepti için sistem güvenliği gereksinimleri doğrulanır. 2. Sistem tehlike analizi tamamlanır ve seçilen tasarım konseptinin test edilmesi, çalıştırılması ve bertaraf edilmesi için öncelikli güvenlik tehlikelerinin dengeli bir listesi oluşturulur, örneğin: a. Ortadan kaldırmak, en aza indirmek veya kontrol etmek için İlk Tehlikeli Madde Yönetim Planı (HMMP) seçilen tasarım konsepti için tehlikeli maddeler B. Kritik insan sağlığı ve güvenliği faktörleri belirlenir ve seçilen sistem için doğrulanır sistem güvenlik programı mimarisine dahil edilen tasarım konsepti 3. Seçilen sistem tasarım konseptini etkileyen temel bir tehlikeli madde listesi derlenir ve NEPA ve OSHA kriterlerine göre önceliklendirilir, yani PEL'ler, toksisite, uçuculuk, taşınabilirlik 4. Tehlikeli maddeler için askerden arındırma ve imha hususları dikkate alınır N. Kontaminasyon Kontrolü 1. Kontaminasyon kontrolü ihtiyaçları ve yaklaşımları (ör. normal, orta veya zorlu ve stresli kontaminasyon kontrolü) seçilen tasarım konsepti için doğrulanır 2. Tespit etmek, doğrulamak ve önceliklendirmek için malzeme araştırması yapılır ve sonuçlar değerlendirilir seçilen tasarım konsepti için gaz giderme özellikleri O. Kalite Güvencesi 1. Kalite ve ürün güvence gereklilikleri, seçilenlerle ilişkilendirilir ve onlar için doğrulanır. tasarım konsepti 2. Seçilen tasarım konsepti için doğrulama, inceleme ve test yaklaşımları doğrulanır P. Çevresel Hususlar 1. Seçilen tasarım konsepti için sistemle izlenebilir çevre çalışmaları tamamlandı mimari ve R&M gereksinimleri 2. Tasarım üzerindeki çevresel etkiler için sağlam bir test programı tanımlanmıştır, örneğin: a. Seçilen tasarım için termal test ve değerlendirme stratejileri geliştirilir ve doğrulanır kavram B. Güvenilirlik termal ticaret analizleri tamamlandı ve sistem mimarisine izlenebilir hale getirildi ve R&M gereklilikleri S. Yazılım 1. Yazılım sistemi mimarisi ve tasarımı (arayüzler dahil), kullanılan yazılım geliştirme yaşam döngüsüyle tutarlı ayrıntı düzeyinde seçilen tasarım konsepti için tamamlanır ve doğrulanır, örneğin: a. Yazılım mimarisi ve tasarımı, tasarım gereksinimlerini karşılar Sayfa 61 / 168 Machine Translated by Google Ek B B. Yazılım gereksinimleri, mimarisi ve tasarımı birbirine çift yönlü izlenebilirliğe sahiptir. C. Yazılım gereksinimleri, mimari ve tasarım, daha üst düzey gereksinimler, mimari ve tasarım için çift yönlü izlenebilirliğe sahiptir D. Operasyonlar, bakım ve eğitim ihtiyaçları için yazılım gereksinimleri e. Güvenilirlik, güvenilirlik, sürdürülebilirlik ve kullanılabilirlik için yazılım gereksinimleri f. Hem yazılım hem de donanım için geçerli desteklenebilirlik için yazılım gereksinimleri g. Hem yazılım hem de donanım için geçerli olan yazılım güvenliği gereksinimleri h. Bilgi güvencesi için yazılım gereksinimleri i. İnsan sistemleri entegrasyonu (HSI) için yazılım gereksinimleri j. Tüm uygun birlikte çalışabilirlik ve açık sistem standartlarına atıfta bulunan harici öğelerle birlikte çalışabilirlik için yazılım gereksinimleri k. Kenar boşlukları için yazılım gereksinimleri (örneğin, bellek ve depolama kapasitesi, işlemci verimi, ve iletişim bant genişliği) l. Uygulanabilir birlikte çalışabilirlik ile ilgili tüm gereklilikleri karşılayan açık sistem standartlarının kullanımı m. COTS (ticari öğeler), GOTS ve yeniden kullanım ürünlerine yönelik yazılım gereksinimleri tahsisi n. Geliştirme dışı öğeler (NDI) (örneğin, COTS (ticari öğe), GOTS ve yeniden kullanım yazılımı), sistem ve yazılım mimarilerinin bileşenlerine tam olarak entegre edilmiştir. Ö. Geliştirme dışı öğeler (NDI) (örn. COTS, GOTS ve yeniden kullanım yazılımı) karşılanması gereken sistem, segment ve arayüz gereksinimleri 2. Yazılım mimarisi ve tasarımı, sistem gereksinimlerinden tahsis edilen durumlar ve modlar için gereksinimleri karşılar 3. Operasyonel Kavramlar, örneğin: A. Yazılım mimarisi ve tasarımı, yazılım perspektifinden hem nominal hem de nominal olmayan senaryolar dahil olmak üzere sistem ve yazılım operasyonel kavramlarını karşılar, örneğin, işlemci yük devretme, artıklık yönetimi B. Yazılım mimarisi ve tasarımı, operasyonlar için sistem ve yazılım gereksinimlerini karşılar, bakım ve eğitim ihtiyaçları C. Yazılım mimarisi ve tasarımı, yazılım perspektifinden sayılar, beceriler, roller ve pozisyonlar gibi operasyonlar ve bakım personeli dahil olmak üzere sistem ve yazılım operasyonel kavramlarını karşılar d. Yazılım mimarisi ve tasarımı, desteklenebilirlik gereksinimlerini karşılar ve her ikisine de uygulanır yazılım ve donanım 4. Yazılım ölçümlerinin ve teknik performans ölçümlerinin analizi şunu gösteriyor: A. Program ve mühendislik yönetimi ihtiyaçlarını karşılamak için yeterlidir b. Bugüne kadar tatmin edici ilerleme kaydedilmiştir ve bu ilerlemenin devam ettiğini göstermektedir. gelecek C. Tüm bilgisayar kaynakları için kullanım tahminleri, örneğin, işlemciler, bellek, depolama ve giriş ve çıkış kanalları, veri yolları ve ağlar tahmin edilen değerler içinde D. Veritabanları ve araçlar, ölçümler ve TPM takibi için seçilir; trend ve raporlama planlandığı gibi performans Sayfa 62 / 168 Machine Translated by Google Ek B R. Veri Depolama (Güvenlik, Erişim, Dağıtım ve Teslimat) 1. Depolama Sistemi Kapasitesi, Esnekliği ve Ölçeklenebilirliği a. Analiz, depolama sistemi ortamlarının gerekli güvenilirlik, sürdürülebilirlik ve kullanılabilirlik özelliklerini tanımlar B. Sistem tasarım ömrünü ele alan kapasite, esneklik ve genişletilebilirlik parametreleri tamamen tanımlanmıştır C. Anahtar sistem bileşenleri tam olarak tanımlanmıştır. Yedeklilik planları mevcuttur ve depolama ortamı donanım ve yazılım yetenekleri ve türleri de dahil olmak üzere tam olarak tanımlanmıştır D. Depolama sistemi yönetimi ve performans optimizasyonu ihtiyaçları (uygun bölümleme ve adreslenebilirlik sağlamak için yazılım yönetimi araçları dahil) belirlendi 2. Tasarım analizi, depolama sisteminin operasyonel ortamlarını belirledi Veri Depolama (Güvenlik, Erişim, Dağıtım ve Teslimat) 3. Depolama Sistemi Yeteneği, Esneklik, Ölçeklenebilirlik, örneğin: A. Analiz, depolama sistemi ortamlarının gerekli Güvenilirlik, Bakım Yapılabilirlik ve Kullanılabilirlik özelliklerini tanımlar B. Sistemin beklenen ömrünü ele alan kapasite, esneklik ve genişletilebilirlik parametreleri tamamen tanımlanmıştır C. Anahtar sistem bileşenleri tam olarak tanımlanmıştır. Depolama ortamı donanım ve yazılım yetenekleri ve türleri de dahil olmak üzere yedeklilik planları mevcuttur ve tam olarak tanımlanmıştır D. Depolama sistemi yönetimi, performans optimizasyonu (uygun bölümleme ve adreslenebilirlik sağlamak için yazılım yönetim araçları dahil) için ihtiyaçlar tamamen belirlenir e. Analiz, depolama sisteminin çalışması gereken işletim ortamlarını tam olarak belirlemiştir. Ele alınması gereken sertleşme yönlerinin tanımlanması tam olarak açıklanmıştır 4. Depolama Sistemi Mimarisi, örneğin: a. Depolama Sistemi Mimarisi, iletişim ve işleme kapasitesi dahil olmak üzere öğeleri tam olarak ele alır B. Depolama sistemi gereksinimlerinin türleri belirlenir ve mimariye tam olarak entegre edilir. Bu, merkezi ve dağıtılmış depolama gibi öğeleri içerir; çevrimiçi, yakın hat ve çevrimdışı ihtiyaçlar; arşivleme (uygunsa hiyerarşik depolama yönetimi dahil), yedekleme ve geri yükleme; ve veri çoğaltma C. RAID, Depolama Alanı Ağları (SAN), Ağa Bağlı Depolama (NAS) ve Doğrudan Bağlı Depolama (DAS) gibi depolama donanımı bileşenleri tanımlanmış ve mimariye tamamen entegre edilmiştir. D. Veri yönetimi yazılımı yetenekleri tanımlanmış ve mimariye tamamen entegre edilmiştir. Bu, otomatik dosya taşıma ve şeffaf dosya alma gibi öğeleri içerir; hiyerarşik düzeyler arasında geçiş; ve medya kullanımı, hata tespiti ve değiştirilecek medyanın tanımlanması hakkında rapor veren yardımcı programlar 5. Güvenlik, örneğin: a. sağlayan kullanıcı bütünlüğü düzeyi (örneğin, erişim kontrol listeleri) tanımlanmıştır. karşılanması gereken sistem gereksinimleri B. Sistem gereksinimlerinin karşılanmasını sağlayan gerekli şifreleme düzeyi belirlenmiştir. ile ilgili Sayfa 63 / 168 Machine Translated by Google Ek B C. CDS, MLS ve Security Enclave'ler gibi özel güvenlik yeteneklerine duyulan ihtiyaç belirlenmiş ve sistem gereksinimlerinin karşılanmasını sağlamak için depolama sistemine dahil edilmiştir 6. Veri Dağıtım Yöntemleri, örneğin: A. Hem bilgisayarı hem de insanı içerecek şekilde veri alıcılarının tam bir listesi hazırlanmıştır. ajanlar B. Çeşitli alıcılara veri dağıtma yöntem(ler)i tanımlanmıştır. Bu tür bir yöntem, Abone Ol ve Yayınla, Gönder ve Çek ve küresel veya kısıtlı Web tabanlı erişimi içerebilir. C. Veri dağıtım yöntemleri, depolama mimarisine tam olarak entegre edilmiştir ve sistem düzeyindeki gereksinimlerin karşılanmasını sağlayacaktır. 7. İşlevsellik, örneğin: A. Analiz, misyonu desteklemek için gerekli olabilecek işlevselliğin fiziksel yönlerini tam olarak tanımlamıştır b. Desteklenen platform türleri (sunucu ve istemci) ve işletim sistemleri tamamen tanımlanmış C. Veri bağlantısı ve taşıma protokolleri (örn. fiber kanal, sonsuz bant, SWCI) tam olarak tanımlanmış ve sistem mimarisine entegre edilmiş olup, sistem seviyesindeki gereksinimlerin karşılanmasını sağlar D. Spesifik raporlama (örn. kullanım) ve bakım metrikleri (örn. MTBF ve MTTR) tanımlanmıştır. Metrikler ve sistem düzeyinde gereksinimler arasındaki ön eşleme tamamlandı e. Depolama sistemi sağlamlaştırma tasarımı gereksinimleri tanımlanır ve anlaşılır 8. Depolama Sistemi Mimarisi, örneğin: A. Depolama Sistemi Mimarisi, iletişim, işleme kapasitesi gibi unsurları tam olarak ele alır b. Depolama sistemi ihtiyaç türleri belirlenir ve mimariye tam olarak entegre edilir. Bu, merkezi ve dağıtılmış depolama gibi öğeleri içerir; çevrimiçi, yakın hat ve çevrimdışı ihtiyaçlar; arşivleme (uygunsa hiyerarşik depolama yönetimi dahil), yedekleme ve geri yükleme; ve veri çoğaltma c. RAID, Depolama Alanı Ağları (SAN), Ağa Bağlı Depolama (NAS) ve Doğrudan Bağlı Depolama (DAS) gibi depolama donanımı bileşenleri tanımlanmış ve mimariye tamamen entegre edilmiştir. D. Veri yönetimi yazılımı yetenekleri tanımlanmış ve mimariye tamamen entegre edilmiştir. Bu, otomatik dosya taşıma ve şeffaf dosya alma gibi öğeleri içerir; hiyerarşik düzeyler arasında geçiş; ve medya kullanımı, hata tespiti ve değiştirilecek medyanın tanımlanması hakkında rapor veren yardımcı programlar 9. Güvenlik, örneğin: a. sağlayan kullanıcı bütünlüğü düzeyi (örneğin, erişim kontrol listeleri) tanımlanmıştır. karşılanması gereken sistem gereksinimleri B. Sistem gereksinimlerinin karşılanmasını sağlayan gerekli şifreleme düzeyi belirlenmiştir. ile ilgili C. CDS, MLS ve Security Enclave'ler gibi özel güvenlik yeteneklerine olan ihtiyaç belirlenmiş ve sistem gereksinimlerinin karşılanmasını sağlamak için depolama sistemine dahil edilmiştir. Sayfa 64 / 168 Machine Translated by Google Ek B 10. Veri Dağıtım Yöntemleri, örneğin: A. Hem bilgisayarı hem de insanı içerecek şekilde veri alıcılarının tam bir listesi hazırlanmıştır. ajanlar B. Çeşitli alıcılara veri dağıtma yöntem(ler)i tanımlanmıştır. Bu tür yöntemler arasında Abone Ol ve Yayınla, Gönder ve Çek ve küresel veya kısıtlı Web tabanlı erişim yer alabilir. C. Veri dağıtım yöntemleri, depolama mimarisine tam olarak entegre edilmiştir ve sistem düzeyindeki gereksinimlerin karşılanmasını sağlayacaktır. 11. İşlevsellik, örneğin: A. Analiz, görevi desteklemek için gerekli olabilecek işlevselliğin fiziksel yönlerini tam olarak tanımlamıştır. B. Desteklenen platform türleri (sunucu ve istemci) ve işletim sistemleri tamamen tanımlanmış C. Veri bağlantısı ve taşıma protokolleri (örn. fiber kanal, sonsuz bant, SWCI) tam olarak tanımlanmış ve sistem mimarisine entegre edilmiş olup, sistem seviyesindeki gereksinimlerin karşılanmasını sağlar D. Spesifik raporlama (örn. kullanım) ve bakım metrikleri (örn. MTBF ve MTTR) tanımlanmıştır. Metrikler ve sistem düzeyinde gereksinimler arasındaki ön eşleme tamamlandı 20.4.5 Entegre Teknik Risk Yönetimi ve Azaltma SFR'de entegre bir program (teknik, maliyet, program ve performans) RM ve Hafifletme (RM&M) sürecinin temel bir bileşeni olarak teknik risk yönetimi (RM) süreci olgunluk kriterleri örneklerinin kanıtı: A. RM&M için destekleyici veriler aşağıdaki gibi öğeleri kapsayabilir: 1. Program takvimi, teknik ve finansman riski değerlendirme sıralaması, izleme ve dokümantasyon yeterlilik 2. Program düzeyinde ilk beş risk (teknik, performans, maliyet ve zamanlama) 3. Risk ölçümlerinin toplanması, analizi, izlenmesi ve raporlanması için risk yönetimi veri tabanı ve araçları 4. Risk azaltma ve azaltma stratejileri, örneğin: a. Program IMP, IMS ve WBS'ye olan bağımlılıklarla bağlantılı olan kullanım ömrü planları b. Sürekli risk izleme ve gözden geçirme, tanımlama, değerlendirme ve sıralama c. Teknoloji ve üretim hazırlık seviyesi (TRL ve MRL) değerlendirmeleri ve ölçümleri d. Gereksinim risk izleme e. Kritik yazılım sorunlarının yazılım risk yönetimi, örneğin, karmaşıklık, boyut, işlem hızı, verim, programlar, COTS kullanılabilirliği, eski yeniden kullanım uygunluğu ve yazılım geliştirme süreçleri ve araçları F. Takip aşamaları için kapsamlı bir risk değerlendirmesi g. TRL ve MRL değerlendirmeleri, metrikler h. Eşiklerin aşıldığı durumlar için eşikler ve uygun eylem planları B. Risk azaltma stratejileri: 1. Gerçekleştirilebilir ve alternatif eylem yolları belirlenir 2. Programın kabul edilebilir bir riskle PDR'ye ilerlemesine izin vermek için sistemin, segmentin, arayüzün ve programın tüm yönlerinde bir olgunluk derecesi olduğunu gösterin. Sayfa 65 / 168 Machine Translated by Google Ek B Sayfa 66 / 168 Machine Translated by Google Ek C Ek C - Yazılım Gereksinimi ve Mimari İncelemesi (SAR) 30. Yazılım Gereksinimi ve Mimari İncelemesi (SAR) SAR, yazılım gereksinimlerinin, mimarisinin ve test planlama teknik ürünlerinin, yazılım geliştirme süreçlerinin ve yazılım geliştirmenin mevcut durumunun resmi, çok disiplinli bir incelemesidir. SAR, münferit Yazılım Konfigürasyon Öğesi (SWCI) veya ilgili SWCI'lerin bir koleksiyonu için, yüklenici tarafından tanımlandığı ve sözleşme yapan kurum tarafından onaylandığı şekilde tutulacaktır. SAR, SFR'den sonra yapılacaktır. 30.1 Genel SAR, eski Yazılım Spesifikasyonu İncelemesinin (SSR) yerini almıştır ve modern sistemlerin başarılı operasyon ve görev yürütme için karmaşık yazılımlara olan bağımlılığını yansıtacak şekilde revize edilmiştir. Bu sistemler, karmaşık harici ve dahili arayüzlere sahip karmaşık donanım ve yazılım kombinasyonlarını içerir. Genellikle emsalsizdirler (daha önce hiç yapılmamışlardır) ve yüksek güvenilirlik ve bütünlük gereksinimleri vardır. Geliştirilmekte olan yeni sistemlerdeki yazılımın boyutu, 105 ila 107 kaynak kod satırı (SLOC) arasında değişebilir. Sistem satın alma stratejisine yanıt olarak, tedarikçi bir yazılım geliştirme yaşam döngüsü modeli seçer. Bu , tedarikçinin sistemi yalnızca bir kez tasarladığı, oluşturduğu, test ettiği ve teslim ettiği bir şelale modeli veya tedarikçinin artan kapasiteyle sistemin birden çok sürümünü tasarladığı, oluşturduğu, test ettiği ve yinelemeli olarak sunduğu artımlı veya evrimsel bir model olabilir. . SAR'ın yazılım geliştirme yaşam döngüsündeki konumu, incelenmekte olan yazılım için kullanılan yaşam döngüsü modeline bağlıdır. Yazılım her zaman belirli bir yaşam döngüsü modeline göre geliştirilir. Diğer yaşam döngüsü modelleri kullanımda olsa da, en yaygın türler şelale, artımlı ve evrimseldir. Şelale yaşam döngüsü modelinde (Şekil 3), yazılım, yazılım gereksinimleri tanımı, yazılım mimarisi ve ayrıntılı tasarımı, yazılım uygulaması ve yazılım testinin (birim, entegrasyon ve yeterlilik testi) Şekil 3'te gösterildiği gibi yalnızca bir kez gerçekleşir. Şelale yaşam döngüsü modeli söz konusu olduğunda SAR, Şekil 3'te gösterildiği gibi yazılım mimarisi (yüksek seviye) tasarımının tamamlanmasında konumlandırılır. gözden geçirme, şelale yaşam döngüsü modeli kullanılarak geliştirildiğinden, SAR sistem PDR'sinden önce tamamlanacaktır. Artımlı ve evrimsel yaşam döngüsü modellerinde, yazılım bir dizi yapı halinde geliştirilir. bir yapı tamamlanmış yazılımın (veya sistemin) karşılayacağı gereksinimlerin belirli bir alt kümesini karşılayan yazılımın (veya sistemin) bir sürümüdür. İki yaygın yinelemeli yaşam döngüsü modeli türü vardır - artımlı ve evrimsel. Artımlı yaşam döngüsü modelinde , yazılım gereksinimleri ilk olarak Şekil 4'te gösterildiği gibi tanımlanır. Daha sonra yazılım, her yapının önceki yapıya eklediği ve yeteneklerini geliştirdiği bir dizi yapı halinde geliştirilir. Artımlı yaşam döngüsü modelinde, her yapı bir defalık yazılım gereksinimleri değerlendirmesi, yazılım mimarisi ve ayrıntılı tasarımı, yazılım uygulaması ve yazılım testi (birim, entegrasyon ve yeterlilik testi) dizisinden oluşur. Bu nedenle, bu yaşam döngüsü modelinde yazılım gereksinimleri önceden tanımlanırken, yazılım mimari tasarımı, yapımlar ilerledikçe yinelemeli olarak tanımlanır. Bu nedenle SAR, her artımlı yapı için yazılım mimari tasarımının sonunda yinelemeli olarak gerçekleştirilir. İncelenmekte olan yazılım için tüm yazılım gereksinimleri Yapı 1 SAR'da incelenirken, yazılım mimarisi ve diğer bilgiler her yapı ilerledikçe artımlı olarak gözden geçirilir. Sayfa 67 / 168 Machine Translated by Google Ek C Sistem Gereksinimleri Tanımı Sistem tasarımı Yazılım Gereksinimleri Def. Donanım Gereksinimleri Def. Üst Düzey Tasarım Ön Tasarım (Mimari) Detaylı tasarım Detaylı tasarım Yapılışı Uygulama (Kodlama) Ölçek Birim Testi Donanım Entegrasyonu Donanım Kal. Test yapmak Yazılım Entegrasyonu Yazılım Kal. Test yapmak HW/SW Entegrasyonu ve Testi Sistem Yeterlilik Testi Işletme ve bakım Yeniden doğrulama/Yeniden doğrulama SAR'ın konumu Şekil 3. Waterfall Yazılım Geliştirme Yaşam Döngüsü Modeli Sistem Gereksinimleri Tanımı Sistem tasarımı Yazılım Gereksinimleri Def. Donanım Gereksinimleri Def. Yazılım Yapısı 1 Ön Tasarım Yazılım Yapısı 2 Detaylı tasarım Gerileme testi • • • İmalat ve Montaj Ölçek Yazılım Yapısı n Donanım Entegrasyonu Gerileme testi Donanım Kal. Test yapmak HW/SW Entegrasyonu ve Testi Sistem Yeterlilik Testi Her yapı şunlardan oluşur: Işletme ve bakım • Yazılım Gereksinimi Değerlendirme Yeniden doğrulama/Yeniden doğrulama • SW Mimari Tasarım • SW Ayrıntılı Tasarım • Yazılım Uygulaması • Yazılım Birimi, Entegrasyon ve SAR'ın konumu Kalifikasyon Testi Şekil 4. Artımlı Yazılım Geliştirme Yaşam Döngüsü Modeli Evrimsel yaşam döngüsü modeli, artımlı yaşam döngüsü modeline benzer, ancak evrimsel yaşam döngüsü modelinde, yapılar, Şekil 5'te gösterildiği gibi, ana belirtimden yazılıma tahsis edilen gereksinimlere dayalıdır . yazılım gereksinimleri tanımı, yazılım mimarisi ve ayrıntılı tasarımı, yazılım uygulaması ve yazılım testinden (birim, entegrasyon ve yeterlilik testi) oluşan bir defalık diziden oluşur. Dolayısıyla, artımlı ve evrimsel yaşam döngüsü modelleri arasındaki ayrım, yazılım gereksinimlerinin önceden (artımlı) veya her yapı içinde yalnızca o yapı için (evrimsel) tanımlanıp tanımlanmadığına bağlıdır. (Şelale yaşam döngüsü modelinin, yalnızca bir yapıya sahip evrimsel bir yaşam döngüsü modeli olarak düşünülebileceğini unutmayın.). Evrimsel yaşam döngüsü modeli için SAR, yazılımın sonunda yinelemeli olarak gerçekleştirilir. Sayfa 68 / 168 Machine Translated by Google Ek C her yapı için mimari tasarım ve yazılım mimarisi ve diğer bilgiler, her yapı ilerledikçe yinelemeli olarak gözden geçirilir. Yinelemeli yaşam döngüsü modelleri için, her SAR mevcut yapı için yazılımın teknik ürünlerini ve durumunu, önceki yapıların mevcut yapı üzerindeki etkisini ve mevcut yapının sonraki yapılar üzerindeki etkisini gözden geçirecektir. Yinelemeli yaşam döngüsü modelleri için, her SAR, yapıları oluşturmak üzere bir araya gelen SWCI koleksiyonunu ele alacaktır. Sistem Gereksinimleri Tanımı Sistem tasarımı Yazılım Yapısı 1 Donanım Gereksinimleri Def. Yazılım Yapısı 2 Ön Tasarım Gerileme testi • • • Detaylı tasarım İmalat ve Montaj • • • Ölçek Yazılım Yapısı n Donanım Entegrasyonu Donanım Kal. Test yapmak Gerileme testi Her yapı şunlardan oluşur: Sistem Yeterlilik Testi • SW Mimari Tasarım Işletme ve bakım • SW Ayrıntılı Tasarım * HW/SW Entegrasyonu ve Testi • Yazılım Gereksinimi Tanım Yeniden doğrulama/Yeniden doğrulama • Yazılım Uygulaması • Yazılım Birimi, Entegrasyon ve Kalifikasyon Testi SAR'ın konumu Şekil 5. Evrimsel Yazılım Geliştirme Yaşam Döngüsü Modeli Bu üç temel türe ek olarak başka yaşam döngüsü modelleri de vardır ve bu temel türlerin iki veya daha fazlasının kombinasyonları olan yaşam döngüsü modelleri vardır. Yukarıda açıklandığı gibi bu üç yaşam döngüsü modeli için SAR yerleşimi, bu üç temel model dışındaki yaşam döngüsü modelleri ve bu temel modellerin iki veya daha fazlasının kombinasyonları için uygun hale getirilmelidir. Kullanımdaki yazılım yaşam döngüsü model(ler)i, Yazılım Gereksinimleri ve Mimari İnceleme(ler)in yaşam döngüsü model(ler)i içindeki konumu ve SAR(lar)ın diğer ana yazılıma göre konumu arasındaki ilişki Bu standartta tanımlanan gözden geçirmeler (sözleşmeye uygun olarak) Yazılım Geliştirme Planında (SDP) açıklanmıştır. SDP gereksinimleri, Uzay Sistemleri için Yazılım Geliştirme Standardı - Havacılık TOR-2004(3909)-3537, diğer adıyla SMC-S-012'de belirtilmiştir. 30.2 Amaç SAR, SFR'den sonra yapılacaktır. SAR, Yazılım Gereksinimleri Spesifikasyonunda (SRS) ve Arayüz Gereksinim Spesifikasyonlarında (IRS(ler)) ve Yazılım Mimarisi Tanımında (SAD), IAW SMC-S'de belirtildiği gibi bir SWCI gereksinimlerinin ve mimarisinin resmi bir incelemesi olacaktır. -012. SAR öncesinde ve hazırlık aşamasında, geliştirici, sistem gereksinimlerinin analizine, sistem tasarımına ve her bir yazılım öğesi tarafından karşılanacak diğer hususlara dayalı olarak yazılım gereksinimlerini, doğrulama yöntemleri ve seviyeleri ile birlikte tanımlamalı ve kaydetmelidir. her gereksinim ve yazılım öğesi gereksinimleri ile üst gereksinimleri arasındaki izlenebilirlik. İzlenebilirlik çift yönlü olacaktır. Sonuç, Yazılım Geliştirme Planında (SDP) tanımlandığı şekilde, Yazılım Gereksinimleri Spesifikasyonu (SRS) DID'sine ve Arayüz Gereksinimleri Spesifikasyonu (IRS) DID'sine uygulanabilir tüm öğeleri dahil etmektir. Bir yapılandırma öğeleri grubu için, her bir yapılandırma öğesini ayrı ayrı ele alan bir toplu SAR, böyle bir yaklaşım sözleşme yapan kurum için avantajlı olduğunda tutulabilir. Amacı, SRS'lerin, IRS'lerin ve Operasyonel Konsept Tanımının (OCD) yeterliliğini sözleşme makamına göstererek ön SWCI tasarımı için tahsis edilen temeli oluşturmaktır. Sayfa 69 / 168 Machine Translated by Google Ek C SAR'ın amaçları aşağıdakileri belirlemektir: A. Yazılım gereksinimleri ve mimari tasarım, üst düzey gereksinimleri karşılamak için yeterlidir. yazılıma tahsis edilen gereksinimler B. Yazılım gereksinimleri ve mimari tasarım, devam etmek için yeterince olgunlaşmıştır. bağımlı yazılım ve sistem geliştirme faaliyetleri C. Yazılım süreçleri, sistem gereksinimlerini ve operasyonel ihtiyaçları karşılamak için ihtiyaç duyulan yazılımı geliştirmek için yeterince tanımlanmış, olgun ve etkilidir ve programın kapsamı ve karmaşıklığına uygundur d. Yazılım test planları, yazılım gereksinimlerinin hedef ortamda doğrulandığını göstermek için yazılım ürünlerinin kapsamlı bir şekilde test edilmesini sağlamak için yeterince sağlamdır. Yazılım geliştirme ve test ortamları kurulur ve yazılım geliştirme ve test gereksinimlerini ve programlarını karşılamak için yeterli yetenek ve kapasiteye sahiptir f. Yazılım geliştirme riski yönetilebilir g. Yazılım geliştirme maliyetleri ve programları, program maliyetleri ve programları ile tutarlıdır. 30.3 İncelenecek Öğeler Yüklenici, incelenmekte olan yazılım için sözleşme yapan kurum tarafından incelenmek üzere aşağıdaki öğeleri sunacaktır: A. Gereksinimler 1. Yazılıma tahsis edilen üst düzey (ana) gereksinimler 2. Yazılım gereksinimleri ve yazılım arabirim gereksinimleri 3. Yazılımla ilgili harici ve bölümler arası veya öğe arabirim gereksinimleri 4. Yazılımdan yazılıma ve yazılımdan donanıma arabirim gereksinimlerine sahip ICD'ler B. Operasyonel Kavramlar 1. Yazılım operasyonel kavramları C. Yazılım Mimari Tasarımı 1. Yazılım mimari tasarım açıklaması 2. Üst düzey bilgisayar sistemi donanım-yazılım mimari tasarım açıklaması D. Mühendislik Analizleri 1. Yazılım mühendisliği analizleri, ticaret çalışmaları, modelleme ve simülasyon sonuçları 2. Donanımdan yazılıma mühendislik analizleri, donanım ve yazılım ticaret çalışmaları, modelleme ve Simulasyon sonuçları E. Entegrasyon ve Doğrulama 1. Yazılım ana yapı planı (gereksinimlerin, işlevlerin ve mimari bileşenlerin yapılara tahsisi) 2. Yazılım yeterlilik testi planları F. İzlenebilirlik 1. Aşağıdakiler arasında çift yönlü izlenebilirlik: a. Yazılıma tahsis edilen üst düzey gereksinimler (arayüz gereksinimleri dahil) ve yazılım gereksinimleri (yazılım arayüzü gereksinimleri dahil) B. Yazılım gereksinimleri (yazılım arayüzü gereksinimleri dahil) ve yazılım mimarisi bileşenleri Sayfa 70 / 168 Machine Translated by Google Ek C C. Yazılım gereksinimleri (yazılım arayüzü gereksinimleri dahil) ve yazılım yeterlilik testleri arasındaki izlenebilirlik d. Gereksinimler ve doğrulama yöntemleri arasında izlenebilirlik ve doğrulama entegrasyonu seviyeler e. Yapılar ve yazılım gereksinimleri, yazılım mimarisi bileşenleri arasında izlenebilirlik, ve yazılım yeterlilik testleri G. Risk Yönetimi 1. Tanımlama, önceliklendirme ve risk işleme planları (azaltma veya diğer teknikler) ve durum dahil olmak üzere yazılım risk bilgileri H. Maliyetler ve Programlar 1. Yazılım boyutu, efor, maliyet, program ve personel tahminleri 2. Yazılım Kaynakları Veri Raporlama: İlk Geliştirici Raporu ve Veri Sözlüğü (SRDR-I) 3. Yazılım Kaynakları Veri Raporlama: Tamamlanan tüm derlemeler için Nihai Geliştirici Raporu ve Veri Sözlüğü (SRDR-F) 4. Yazılım programları 5. IMS dahil olmak üzere daha yüksek seviyeli çizelgeler 6. Yaşam döngüsü maliyeti (LCC) ve bağımsız değişken olarak maliyet (CAIV) çalışmalarında yapılan güncellemeler SRR'de her bir yazılım mimarisi konseptini desteklemek için sunulmuştur, örneğin: A. LCC ve CAIV modellemesi ve analizleri uygulanır ve her bir yazılım mimarisi konseptiyle ilişkilendirilir; örneğin, öngörülen program geliştirmeyi, tamamlanan işletim ve sürdürme maliyetlerini ve ayrıca diğer "harici" sistemlere yönelik tahmini maliyet etkilerini gösteren maliyet modelleri B. Geçerli ticari çalışmaların yapıldığını gösteren LCC ve CAIV metodolojisi sunulmaktadır. yürütülen I. Mühendislik ve Yönetim Planları 1. Yazılım Geliştirme Planı (SDP) 2. Yazılımla ilgili diğer program planları (örneğin, Sistem Mühendisliği Yönetim Planı, Risk Yönetim Planı, Entegre Ana Plan, Konfigürasyon Yönetim Planı, Kalite Güvence Planı) 3. Sistem (donanım ve yazılım) özel mühendislik planları (örneğin, güvenilirlik, güvenlik, desteklenebilirlik, güvenlik (bilgi güvencesi) ve insan sistemleri entegrasyon planları) 4. Yazılım mühendisliği ortamının planları ve durumu 5. Test yatakları, test tesisleri, donanım, yazılım, simülatörler ve diğer test araçları dahil olmak üzere yazılım test ortamlarının planları ve durumu J. Metrikler ve Teknik Performans Ölçüleri 1. Yazılım ölçüm raporları 2. Yazılımla ilgili TPM raporları 3. Yazılım sorunu ve eksiklik raporu durumu Sayfa 71 / 168 Machine Translated by Google Ek C 30.4 SAR "Kabul Kriterleri" SAR'da, Sistem Mühendisliği Yönetim faaliyetlerinin tüm ana program öğeleri ve risk faktörleri dikkate alınacaktır. SAR'ın temel beklentisi, gözden geçirmenin, değişiklik kontrolü altına alınabilecek onaylanmış bir yazılım gereksinimi ve mimari temel çizgisi ile sonuçlanması ve onaylanan temelin maliyet, program ve performans gereksinimleri kısıtlamaları dahilinde uygulanabileceğinin belirlenmesidir. SAR için hazırlanırken ve programlanırken, yüklenici, tüm geçerli mühendislik faaliyetleriyle birlikte, sözleşmeyle özel olarak hazırlanmış aşağıdaki asgari, ancak her şey dahil olmayan "Kabul Kriterleri" listesini, sözleşmeyi yapan kurumu tatmin edecek şekilde gösterecektir. : A. Gereksinimler 1. Yazılıma tahsis edilen üst düzey gereksinimler eksiksiz ve istikrarlıdır 2. Yazılım gereksinimleri (yazılım arabirimi gereksinimleri dahil), seçilen yazılım yaşam döngüsü modeline dayalı olarak yazılım geliştirme planında belirtilen eksiksizlik düzeyine göre belirtilmiştir 3. Yazılım gereksinimleri (yazılım arayüzü gereksinimleri dahil) doğru, eksiksiz, tutarlı, uygulanabilir, doğrulanabilir ve açık ve net bir şekilde belirtilmiş 4. Yazılım gereksinimleri (yazılım arayüzü gereksinimleri dahil) takip edilir ve tamamen ebeveyn gereksinimlerini uygulamak 5. Yazılım gereksinimleri, sistemden ve yazılımdan türetilen gerekli gereksinimleri içerir. mimari, sistem operasyonel kavramları, ticari çalışmalar veya tasarım kararları 6. Yazılım arabirimi gereksinimleri dahil olmak üzere her yazılım gereksinimi, belirtilen bir veya daha fazla geçerli doğrulama yöntemine ve doğrulama düzeyine sahiptir ve bu yöntemler ve düzeyler, gereksinimi tam olarak doğrulamak için yeterlidir B. Operasyonel Kavramlar 1. Yazılım operasyonel kavramları, sistem ve yazılım mimarileri ile tutarlı bir yazılım perspektifinden (örn. başlatma, başlatma, kapatma, işlemci yük devretme, artıklık yönetimi, kurtarma ve geri yükleme) nominal ve nominal olmayan senaryoları içerir. 2. Yazılım operasyonel kavramları, harici arabirim sistemleriyle bilgi alışverişini içerir 3. Yazılım operasyonel kavramları, operasyonel iş yükleri için senaryoları içerir 4. Yazılım operasyon kavramları, sistem operasyonel kavramlarıyla tutarlıdır C. Mimari ve Tasarım 1. Yazılım mimarisi, yazılımda istenen bütünlük düzeyine göre tanımlanmıştır. seçilen yazılım yaşam döngüsü modeline dayalı geliştirme planı 2. Fiziksel, mantıksal, gelişimsel, süreç ve davranışsal (kullanıcı) görünümler dahil olmak üzere yazılım mimarisi görünümleri doğru, eksiksiz, tutarlı, açık ve nettir 3. Geliştirme dışı öğeler (NDI) (örn. COTS, GOTS ve yeniden kullanım yazılımı) tamamen yazılım mimarisinin bileşenlerine entegre 4. Geliştirmeyle ilgili olmayan öğeler (NDI) (örneğin, COTS, GOTS ve yeniden kullanım yazılımı) dahil olmak üzere yazılım mimarisi, yazılıma tahsis edilen üst düzey gereksinimlerin, yazılım gereksinimlerinin ve yazılım arayüzü gereksinimlerinin karşılanmasını sağlayacaktır. 5. Her bir yazılım öğesinin tasarımı, tutarlı bir şekilde yazılım birimleri düzeyinde detaylandırılmıştır. yazılım geliştirme planı ve seçilen yazılım yaşam döngüsü modeli ile 6. Her bir yazılım öğesinin tasarımı açık, doğru, eksiksiz, tutarlı ve nettir ve aşağıdakileri yeterince ele alır: a. Tüm harici ve dahili arayüzlerin üst düzey tasarımı Sayfa 72 / 168 Machine Translated by Google Ek C B. Tüm dosyaların, veritabanlarının, paylaşılan belleğin vb. üst düzey tasarımı ve bunların depolanması ve erişimi yöntemler C. Kullanıcı arayüzü ekranlarının ve insan ve sistem etkileşimlerinin üst düzey tasarımı d. Yazılım öğesinin her birimi için kaynak (örn. COTS, değiştirilmemiş yeniden kullanım, değiştirilmiş yeniden kullanım veya yeni geliştirilen kod) ve kullanılacak programlama dil(ler)i e. Seçilen COTS yazılım ürünleri ve kurulum ve konfigürasyon tasarım kararları 7. Her bir yazılım öğesinin üst düzey tasarımı, geçerli tüm standartları (örneğin, arayüz standartları, grafik kullanıcı arayüzü (GUI) standartları) uygun şekilde uygular. 8. Yazılım mimarisi, açık sistem standartlarının kullanımını yeterince ele alır ve uygulanabilir birlikte çalışabilirlik ile ilgili tüm gereklilikleri karşılar 9. Yazılım mimarisi, uçtan uca işlemeyi yeterince ele alır (zaman çizelgeleri ve kapasite) 10. Yazılım mimarisi, operasyonel veri tabanı yönetimini ve kontrolünü yeterince ele alır. yazılıma tahsis edilen üst düzey gereksinimler, yazılım gereksinimleri ve karşılanması gereken yazılım arayüzü gereksinimleri 12. Yazılım mimarisi, her biri için uygun işlevsel ve performans gereksinimlerini karşılar durum ve mod 13. Mimari, entegre donanım-yazılım da dahil olmak üzere desteklenebilirliği yeterince ele alır teşhis, arıza tespiti, izolasyon, yerelleştirme, geri yükleme ve onarım 14. Yazılım mimarisi, güvenilirliği, sürdürülebilirliği ve kullanılabilirliği yeterince ele alır bilgisayar donanım ve yazılım alt sistemlerine tahsis edilen gereksinimler D. Mühendislik Analizi 1. Mühendislik analizleri, modeller ve simülasyonlar, seçilen bilgisayar kaynakları (donanım ve yazılım) ile birlikte yazılım mimarisinin Temel Performans Parametrelerini (KPP'ler) ve yönlendirici gereksinimleri karşılayacağını yeterince göstermektedir. 2. Güvenilirlik, sürdürülebilirlik ve Kullanılabilirlik analizleri, yazılım mimarisi ve seçilen bilgisayar kaynakları (donanım ve yazılım) ile tutarlıdır ve uygun şekilde yazılımın katkısını içerir. 3. Güvenlik, bilgi güvencesi ve insan sistemleri entegrasyon analizleri, yazılım mimarisi ve seçilen bilgisayar kaynakları (donanım ve yazılım) ile tutarlıdır ve uygun şekilde yazılımın katkısını içerir 4. Mühendislik analizleri ve ticari araştırmalar, yazılımı yeterince destekler NDI (yeniden kullanım, COTS ve GOTS yazılım bileşenleri) ile ilgili mimari tasarım kararları ve seçilen altta yatan, destekleyici bilgisayar kaynaklarını (donanım ve yazılım) uygun şekilde göz önünde bulundurun 5. İnsan sistemleri entegrasyonu mühendislik analizleri ve ticaret çalışmaları (örn. çalışabilirlik, operatör iş yükü analizi), yazılım mimarisinin ve seçilen bilgisayar kaynaklarının (donanım ve yazılım) operatörlerin gerekli rolleri yerine getirmeleri için yeterliliğini gösterir. gerekli zaman çizelgeleri 6. Ön performans analizi, yazılım mimarisinin, seçilen bilgisayar kaynaklarıyla (donanım ve yazılım) birlikte, yaşam döngüsünün bu noktası için yeterli marjlarla performans gereksinimlerini karşıladığını gösterir. 7. Mühendislik analizleri ve ticari araştırmalar, seçilen bilgisayar kaynakları (donanım ve yazılım) ile birlikte yazılım mimarisinin bilgisayar kaynak marjı gereksinimlerini karşılamak için yeterliliğini göstermektedir. Sayfa 73 / 168 Machine Translated by Google Ek C 8. Yukarıdaki tüm analizler, seçilen donanımdaki mevcut yazılımın (örn. prototipler, önceki yapılar, NDI) gerçek performansını dikkate alır. 9. Yazılım E'de uygulanacak algoritmaların yeterliliğini göstermek için mühendislik modelleri ve simülasyonlar kullanılmıştır. Entegrasyon ve Doğrulama 1. Yazılım yeterlilik testi planları, Seçilen yazılım yaşam döngüsü modeline dayalı Yazılım Geliştirme Planı 2. Yazılım yeterlilik test planları geçerli, eksiksiz, kararlı, yazılım mimarileri ve daha yüksek seviyeli test planları ile tutarlı ve yazılım gereksinimleri ve yazılım arayüzü gereksinimleri için test yöntemleri ve test seviyeleri için yeterlilik gereklilikleri ile tutarlıdır. 3. Yazılım gereksinimleri, tamamen yazılım yeterlilik testinde açıklanan testlere tahsis edilmiştir. nerede doğrulanacaklarını planlar 4. Ana yazılım oluşturma planı eksiksiz, uygulanabilir, yürütülebilir ve yazılım gereksinimleri, yazılım mimarisi, yazılım yeterlilik testi planları ve üst düzey çizelgelerle tutarlıdır. F. İzlenebilirlik 1. Tüm izlenebilirlik bilgileri doğru, çift yönlü ve yazılıma, yazılım gereksinimlerine, yazılım arayüz gereksinimlerine, yazılım mimari bileşenlerine ve yazılım yeterlilik test planlarına tahsis edilen üst düzey gereksinimlerle tutarlıdır. 2. Tüm izlenebilirlik bilgileri, Yazılımda tanımlanan eksiksizlik düzeyine göre tanımlanır. Seçilen yaşam döngüsü modeline dayalı Kalkınma Planı G. Risk Yönetimi 1. Yazılım risk değerlendirmesi, uygun olduğu şekilde aşağıdaki yazılım risklerini içerir: A. Yazılım boyutu ve karmaşıklığına bağlı riskler B. Yazılıma tahsis edilen gereksinimlerle ilgili riskler c. Sistemin yazılım yönleri ve yazılım mimarileri ile ilgili riskler d. NDI seçimi ve kullanımına ilişkin riskler (COTS, yeniden kullanım, GOTS) e. Bilgi işlem kaynaklarının (örn. işlemciler, önbellek, bellek, veri yolları ve ağlar) seçimi ve kullanımıyla ilgili riskler f. Bilgi işlem kaynakları için büyüme marjlarıyla ilgili riskler g. Yazılım programları ile ilgili riskler h. Yazılım geliştirme, entegrasyon ve doğrulama süreçleri ve araçlarına ilişkin riskler i. Veritabanlarının doldurulması, güncellenmesi, kontrolü ve doğrulanması ile ilgili riskler J. Yazılım ve bilgisayar donanımı teknolojisi ile ilgili riskler 2. Sağlam bir yazılım risk yönetimi planı, Yazılım Geliştirme Planının bir parçasıdır ve program Risk Yönetim Planı ile entegredir. 3. Yazılım risk yönetimi süreci de dahil olmak üzere etkili bir program risk yönetimi sürecinin işlediği kanıtlanmıştır 4. Etkili yazılım risk işleme planları mevcuttur ve risk işleme faaliyetleri yürütülmektedir. planlara uygun olarak gerçekleştirilen H. Maliyetler ve Programlar 1. Yazılım maliyet modelleri, gerçek verilerle (hem mevcut projeden hem de geçmişten) kalibre edildi ve yazılım maliyetini güncellemek ve tahminleri planlamak için kullanıldı. Sayfa 74 / 168 Machine Translated by Google Ek C 2. Karmaşıklık ve diğer parametreler gibi gerçekçi yazılım maliyeti faktörleri ve varsayımlar belgelenir, belgelenen proje verileriyle doğrulanır ve güncel maliyet ve program tahminlerini geliştirmek için yazılım maliyet modellerinde kullanılır 3. Yazılım boyutu tahminleri, geçmişe dayalı olarak desteklenebilir, ve yazılım ve arayüz gereksinimleri ve yazılım mimarisi ile tutarlı 4. Yazılım maliyeti ve program tahminleri, tahmin riskini karşılamak için yeterli marja sahiptir zamanın bu noktasına uygun 5. Yazılım çizelgeleri, IMS dahil olmak üzere daha yüksek seviyeli çizelgelerle tutarlıdır. I. Mühendislik ve Yönetim Planları 1. SDP, IMP, sistem mühendisliği yönetim planı ve diğerleriyle tutarlıdır. yönetim ve mühendislik planları 2. SDP, tüm yazılım geliştirme yaşam döngüsünü ele alır. 4. SDP, uygulanabilir ve uygun olan seçilmiş yazılım geliştirme yaşam döngüsü modellerini tanımlar. programın kapsamı ve karmaşıklığı için ve tüm ekip üyeleri tarafından tutarlı bir şekilde kullanılır 5. Yaşam döngüsü boyunca kullanım için yazılım süreçleri, standartları, prosedürleri ve sözleşmeleri belgelendi, doğrulandı ve SDP'ye dahil edildi 6. Mevcut ve planlanan yazılım mühendisliği ortamları, gözden geçirilen yazılım için tüm yazılım ekibi üyeleri genelinde sistem mühendisliği ortamlarıyla entegre olur 7. Yazılım geliştirme ve test ortamları kurulur ve yazılım geliştirme ve test gereksinimlerini ve programlarını karşılamak için yeterli yetenek ve kapasiteye sahiptir. 8. Yüklenici, yazılım süreçlerinin, standartlarının, prosedürlerinin ve yaşam döngüsündeki bu noktaya uygun olarak sözleşmeler izleniyor J. Metrikler ve Teknik Performans Ölçüleri 1. Yazılım metrikleri, program ve mühendislik yönetimi için bilgi ihtiyaçlarını karşılamak için yeterlidir ve metrik deneyiminden bugüne kadar öğrenilen dersleri içerir 2. Yazılım metrikleri toplanmakta, analiz edilmekte, raporlanmakta ve yönetim ve teknik karar verme için kullanılmaktadır. yaşam döngüsünde bu noktaya uygun olarak risk yönetimi 3. Aşağıdakilerle belirtilen temel sorunları ele almak için yeterli düzeltici eylemler tanımlanmıştır: belgelenmiş eşiklerin dışında kalan yazılım ölçümleri 4. TPM'ler toplanmakta, analiz edilmekte, rapor edilmekte ve işlemciler, bellek, depolama ve giriş ve çıkış kanalları ve ağları gibi tüm kritik bilgisayar kaynaklarının kullanımının yönetilmesi için kullanılmaktadır. 5. TPM'ler toplanıyor, analiz ediliyor, raporlanıyor ve yazılımla ilgili KPP'leri yönetmek için kullanılıyor ve yanıt süresi ve zaman çizelgesi gereksinimleri dahil olmak üzere sürüş gereksinimleri 6. Aşağıdakilerle belirtilen temel sorunları ele almak için yeterli düzeltici eylemler tanımlanmıştır: belgelenmiş eşiklerin dışında olan yazılım TPM'leri 7. Yüklenici, eşiklerin dışındaki metrikler veya TPM'ler için düzeltici olduğunu göstermiştir. eylemler başlatıldı, yönetildi ve kapanışa kadar izlendi 8. Yazılım sorunu ve eksiklik raporu durumu, belgelenmiş sorunlara yönelik çözümlerin uygulanmasında ve doğrulanmasında yeterli ilerleme kaydedildiğini ve belgelenen sorunların önem derecelerine göre ele alındığını gösterir. Sayfa 75 / 168 Machine Translated by Google Ek C 30.5 İnceleme Sonrası Eylem SAR'ı tamamladıktan sonra yüklenici, Gözden Geçirme Tutanaklarının kopyalarını yayınlayacak ve dağıtacaktır. Sözleşmeyi yapan kurum, SAR'ın tamamlandığını resmen kabul eder. Sayfa 76 / 168 Machine Translated by Google Ek D Ek D - Ön Tasarım İncelemesi (PDR) 40. Ön Tasarım İncelemesi (PDR) PDR, incelenmekte olan ön sistem ve yapılandırma öğesinin (CI) veya işlevsel olarak ilgili son öğe tasarımı grubunun ayrıntılı ve kritik tasarıma geçmek için yeterince olgun olup olmadığını değerlendirmek için yürütülen çok disiplinli bir teknik ürün ve SE sürecidir, örneğin: A. Tanımlandığı şekliyle Yetenek Geliştirme Belgesi (CDD) ile tutarlıdır B. Program maliyeti, bütçe, program, risk, kullanıcı ve diğer kısıtlamalar dahilinde belirtilen performans gereksinimlerini karşılayabilir C. Sistemdeki her yapılandırma öğesi için performans belirtimlerinde tam olarak ele alınır ve tahsis edilen temel D. İşlevsel temel çizgisindeki her işlev, aşağıdakilerden oluşan bir veya daha fazla sistem CI'ye tahsis edilmiştir: donanım ve yazılım öğeleri ve çıktıları Karmaşık sistemler için, her bir alt sistem veya konfigürasyon öğesi için bir dizi PDR yürütülmeli ve bu da genel bir sistem PDR'sine yol açmalıdır. Yazılım öğeleri için, seçilen yaşam döngüsü model(ler)ine dayanan yazılım geliştirme planına (SDP) göre bir dizi SAR yürütülecektir (bkz. Ek C). Bireysel incelemeler yapıldığında, genel sistem PDR'sinin vurgusu, genel sistem tasarım gereksinimlerinin yanı sıra konfigürasyon öğesi işlevsel ve fiziksel arayüz tasarımına odaklanmalıdır. PDR, seçilen yaşam döngüsü model(ler)ine dayalı olarak SDP'de belirtilen ölçüde donanım, insan ve yazılım ön tasarımlarının eksiksiz olup olmadığını ve Entegre Ürün Ekibinin ayrıntılı tasarım ve test prosedürünü başlatmaya hazır olup olmadığını belirler. gelişim. Her bir PDR, sistem, segment, alt sistem ve CI'nin teknik kapsamı ve riskinin gözden geçirilmesi için uyarlanacak ve Sistem Mühendisliği Planının ayrılmaz bir parçası haline getirilecektir. PDR, yalnızca tüm önemli donanım tasarımı sorunları çözüldüğünde ve ayrıntılı donanım tasarımı üzerinde çalışmaya başlandığında yürütülecektir. Yazılım için tasarım sorunları, seçilen yaşam döngüsü model(ler)ine dayalı olarak SDP'de belirtilen ölçüde ve SAR ve yazılım oluşturma incelemeleri tarafından çözülecektir. 40.1 Genel PDR'ler, SRR ve SFR'de temel alınan alt sistem veya CI gereksinimlerinin segmente, alt sisteme ve CI'ye tahsis edilen tüm sistem gereksinimlerini doğru ve eksiksiz bir şekilde uyguladığını değerlendirmek için yapılacaktır. PDR ayrıca segment, alt sistem ve CI gereksinimlerinin sistem tasarımıyla uyumlu olup olmadığını da belirler. Spesifikasyon ağacındaki her bir CI veya CI kümesi için bir PDR tutulur. Bireysel CI PDR'leri şunları sağlamalıdır: A. CI mimarisi tamamlandı b. CI geliştirme belirtimi tamamlandı veya geliştirme belirtimi onaylandı c. Tahsis edilen ana hat tamamlandı veya tahsis edilen ana hat onaylandı d. Yazılım gereksinimleri ve mimarisi, seçilen yaşam döngüsü model(ler)ine dayalı olarak SDP'de belirtilen ölçüde tamamlanmıştır. Tüm donanım CI'larının tamamlanmasından ve donanım CI PDR'lerinin toplanmasından sonra bir sistem PDR'si tutulacaktır. SDP'de belirtilen tüm yazılım SAR'larının tamamlanmasından ve bireysel PDR'ler ve yazılım SAR'ları yürütüldükten sonra, genel sistem PDR'sinin vurgusu aşağıdakilere odaklanacaktır: A. Yapılandırma öğesi işlevsel ve fiziksel arayüz tasarımının yanı sıra genel sistem tasarım gereksinimleri b. Donanım, insan ve yazılım ön tasarımlarının olgunluğu c. Tasarımın, yüklenicinin ayrıntılı tasarım ve test prosedürü geliştirmeye başlamaya hazır olduğu noktaya kadar ilerlediğini göstermek için sistem ve EI tasarımının olgunluğu Sayfa 77 / 168 Machine Translated by Google Ek D D. İlerleme, teknik yeterlilik ve risk çözümü (teknik, maliyet ve program bazında) seçilen tasarım yaklaşımının e. Donanım Yapılandırma Öğesi (HWCI) geliştirme belirtiminin uyumluluğu performans ve mühendislik uzmanlık gereksinimleri F. Her bir EI tanımının temel alındığı ve her bir EI için seçilen üretim yöntemleri ve süreçleriyle ilişkili teknik riski değerlendirdiği derece G. Konfigürasyon öğesi ile diğer ekipman, tesis, bilgisayar yazılımı ve personel öğeleri arasındaki fiziksel ve işlevsel arayüzlerin varlığı ve uyumluluğu h. Seçilen yaşam döngüsü model(ler)ine dayalı olarak SDP'de belirtilen ölçüde, Yazılım Yapılandırma Öğelerinin (SWCI'ler) ilerlemesinin, tutarlılığının ve teknik yeterliliğinin değerlendirilmesi, örneğin: (1) Seçilen üst düzey yazılım tasarımı ve test yaklaşımı (2) Yazılım gereksinimleri ile ön tasarım arasındaki uyumluluk (3) Operasyonun ön versiyonu ve destek belgeleri Ben. Gereksinimlerin akran incelemelerinin sonuçları ve ön tasarım belgeleri j. Alt sistem gereksinimlerinin, alt sistem ön tasarımının, meslektaş incelemelerinin sonuçlarının ve geliştirme ve test planlarının ayrıntılı tasarım ve test prosedürü geliştirmeye ilerlemek için tatmin edici bir temel oluşturduğunun belirlenmesi PDR ayrıca aşağıdakileri de teyit eder: A. Ayrıntılı sistem tasarımı yaklaşımı (insan, ürün ve sürecin entegre bir bileşimi olarak) çözümler) tahsis edilen işlevsel temeli karşılar B. Kalan riskler, kapatma planları ve sistem, alt bileşenler veya destek unsurları için bir temel tasarım oluşturulmasıyla azaltılır. C. Teknoloji, geliştirmenin devam etmesi için yeterince olgun (en az 5 TRL) veya alternatif teknolojiler birincil olarak kabul edilmelidir 40.2 Amaç PDR'nin amacı, alt sistem gereksinimleri kümesini değerlendirmek ve alt sisteme tahsis edilen tüm sistem gereksinimlerini doğru ve eksiksiz bir şekilde uygulayıp uygulamadıklarını belirlemektir. Ek olarak, alt sistem gereksinimlerinin sistem tasarımıyla uyumlu olup olmadığı ve geliştirme ve test planlarının ayrıntılı tasarım ve test prosedürü geliştirmeye devam etmek için tatmin edici bir temel oluşturduğu belirlenmelidir. Spesifik olarak, PDR'nin amacı kritik, sistem genelindeki sorunları ele almak ve çözmektir, örneğin: A. Her Donanım Konfigürasyon Öğesi (HWCI) ve her SWCI için seçilen yaşam döngüsü model(ler)ine dayalı olarak SDP'de belirtildiği şekilde bir temel tasarım oluşturun b. Seçilen tasarım yaklaşımının ilerlemesini, teknik yeterliliğini ve risk çözümünü (teknik, maliyet ve program bazında) değerlendirin C. Performans ve mühendislik uzmanlığı ile tasarım yaklaşımı uyumluluğunu belirleyin her yapılandırma öğesi geliştirme belirtiminin gereksinimleri D. Tanım derecesini değerlendirin ve seçilenle ilişkili teknik riski değerlendirin. üretim yöntemleri ve süreçleri e. Konfigürasyon öğeleri ve diğer ekipman, tesis, bilgisayar yazılımı ve personel öğeleri arasındaki fiziksel ve işlevsel arayüzlerin varlığını ve uyumluluğunu belirleyin F. SWCI'lar için bu inceleme aşağıdakilere odaklanacaktır: Sayfa 78 / 168 Machine Translated by Google Ek D (1) Seçilen zirvenin ilerlemesi, tutarlılığı ve teknik yeterliliğinin değerlendirilmesi seviye tasarımı ve test yaklaşımı (2) Yazılım gereksinimleri ile ön tasarım arasındaki ve işletim ve destek belgelerinin ön versiyonundaki uyumluluk 40.3 Amaç PDR'nin amacı, Yüklenici ve Satın Alma ajansı için: A. İşlevsel taban çizgisindeki (FBL) değişiklikleri gözden geçirin B. İşlevsel mimariyi gözden geçirin ve onaylayın C. Fiziksel hiyerarşiyi gözden geçirin ve onaylayın d. Öğeler arasındaki ve öğeler ile diğer sistemler, tesisler ve personel arasındaki arayüzlerin eksiksizliği ve uyumluluğu da dahil olmak üzere her bir konfigürasyon öğesi için tahsis edilen temeli gözden geçirin ve onaylayın e. FBL kaynağından tahsis edilene kadar iki yönlü izlenebilirliği gözden geçirin ve onaylayın. temel ve geri F. Tahsis edilen temelin sistem gereksinimlerini karşılayabildiğini gözden geçirin ve onaylayın ve doğrulayın g. Sistem geliştirme için güncellenmiş risk değerlendirmesinin geçerliliğini gözden geçirin ve onaylayın ve gösteri H. Mimarilerdeki her öğe ve temeldeki her gereksinim için performans, maliyet, program ve risk arasındaki temeli ve dengeyi gözden geçirin ve doğrulayın Ben. Yüklenicinin sistem tarafından tahsis edilen temelinin güncellenmiş maliyet analizi gereksinimleri açıklamasını (CARD) desteklediğini gözden geçirin ve doğrulayın j. Sistem ve yazılım kritik yolu da dahil olmak üzere güncellenmiş program zamanlamasını gözden geçirin ve doğrulayın sürücüler k. Onaylanmış SWCI'yı gözden geçirin ve onaylayın Ek olarak, her prototip üzerinde (uygulanabilir ve her geliştirme programına özel olarak) aşağıdakiler için bir değerlendirme yapılacaktır: A. Seçilen tasarım yaklaşımının ilerlemesini, teknik yeterliliğini ve risk çözümünü değerlendirin b. Gelişen FBL ve mimari ile uyumunu belirleyin c. Tahsis edilen taban çizgisinin fiziksel ve işlevsel ile uyumluluğunu gösterin. arayüzler ve diğer öğeler, tesisler ve personel 40.4 PDR “Kabul Kriterleri” PDR'de, program risk faktörleri olan tüm ana sistem mühendisliği yönetim unsurları ve faaliyetleri dikkate alınır. "Tamamlanma", yazılımla ilgili olarak kullanıldığında, faaliyetin veya ürünün, seçilen yaşam döngüsü model(ler)ine dayalı olarak SDP'de belirtilen ölçüde tamamlandığını belirtir. PDR'nin amacı aşağıdakileri tespit etmektir: A. Donanım işlevsel ayrışımı tamamlandı b. Doğru, kapsamlı bir tahsis temel çizgisi onaylandı c. Donanım temel tasarımı oluşturuldu d. Yazılım mimari tasarımı SDP tabanlı olarak belirtilen ölçüde tamamlanmıştır. seçilen yaşam döngüsü model(ler)inde Bir PDR'nin hazırlanmasında ve programlanmasında, yüklenici, sözleşme makamını tatmin edecek şekilde aşağıdakileri gösterecektir: Sayfa 79 / 168 Machine Translated by Google Ek D A. Yüklenici, gereksinimler kriter öğelerini uygun şekilde ele almıştır. B. Uygulanabilir tüm mühendislik faaliyetleri, c kriterini desteklemek için uygun şekilde yürütülmüştür. Uygulanabilir bir teknik ve program risk yönetimi stratejisi, ihale makamının memnuniyeti D. Etkin ve verimli teknik ilerleme, tüm maliyetlerin, programların ve teknik performans gereklilikleri PDR “Kabul Kriterleri” aşağıdaki beş ana kategori altında düzenlenecektir: 1. Sistem Mühendisliği ve Mimarisi Geliştirme (40.4.1) 2. Sistem, Segment ve Alt Sistem Tasarımı (40.4.2) 3. Sistem Doğrulama ve Doğrulama (40.4.3) 4. Mühendislik Disiplinleri ve Uzmanlık Mühendisliği (40.4.4) 5. Entegre Teknik Risk ve Azaltma (40.4.5) Bu gözden geçirme, yüklenicinin temel ve üzerinde anlaşmaya varılan PDR “Kabul Kriterleri”ni destekleyen teknik çabasının nesnel kanıtı olacaktır, örneğin: a) Teknik çaba ve tasarımın durumu, operasyonel test başarısını gösteriyor mu? (operasyonel olarak uygun ve etkili)? b) Açıklandığı şekliyle ön tasarım, Yetenek Geliştirme Belgesini karşılayabilir mi? c) Ayrıntılı tasarımı mümkün kılmak için sistem tarafından tahsis edilen temel oluşturulmuş ve belgelenmiş mi? uygun yapılandırma yönetimi ile devam etmek için? d) Programın başarılı olması için yeterli süreçler ve ölçümler mevcut mu? e) İnsan entegrasyonu tasarım faktörleri gözden geçirildi mi ve gerektiğinde genel sistem tasarımı? f) Geliştirme testi ve operasyonel test için riskler biliniyor ve yönetilebilir mi? g) Program çizelgesi yürütülebilir mi (teknik ve maliyet riskleri)? h) Programda uygun personel bulunuyor mu? i) Program mevcut bütçe ve onaylanan sistem tahsisi ile yürütülebilir mi? temel? j) Güncellenen maliyet tahmini mevcut bütçeye uygun mu? k) Ön tasarım, üretim bütçesi dahilinde üretilebilir mi? l) Güncellenmiş maliyet analizi gereksinimleri açıklaması, onaylanmış tahsis edilen gereksinimlerle tutarlı mı? temel? m) Onaylanan tahsis edilmiş temeldeki yazılım işlevselliği, güncellenenle tutarlı mı? yazılım ölçümleri ve kaynak yüklü program? n) CDR'ye devam etmek için doğrulama planları ve kaynakları mevcut mu? Birincil PDR verileri, bu öğeleri belgeleyen veya gösteren Karar Veri Tabanıdır (DDB). 40.4.1 Sistem Mühendisliği ve Mimari Geliştirme PDR'de Sistem Mühendisliği ve Mimari Geliştirme gereksinimleri olgunluk kriterleri örneklerinin kanıtı: A. Sistem Mühendisliği İnceleme Kriterleri 1. Tahsis edilen sistem, segment, alt sistem ve bileşen gereksinimleri eksiksiz, uygulanabilir, doğrulanabilir ve açıkça belirtilmiş, örneğin: Sayfa 80 / 168 Machine Translated by Google Ek D A. Ön Sistem Tasarımı, Tahsis Edilen Gereksinimlerle ilişkilendirilir ve buna yansıtılır temel B. Sistemin, segmentlerin, alt sistemlerin ve bileşenlerin ön tasarımı, sistem mimarisi görünümleri ve açıklamaları ile ilişkilendirilir ve İşlevsel ve Tahsis Edilen Ana Çizgilere kadar izlenebilir. C. Ön tasarım, üretim, entegrasyon, operasyonlar, bakım, eğitim, askerden arındırma ve imha için zaman çizelgeleri ve kapasiteler dahil olmak üzere sistem, segmentler, alt sistemler ve bileşen mimarileri için uçtan uca işleme yeteneklerini dikkate alır. D. Sistem, segmentler, alt sistemler ve bileşenler için ön tasarım verileri (örn. çizimler, spesifikasyonlar vb.) tamamlandı ve konfigürasyon kontrolü altına alındı e. Sistem için uçtan uca veri akışı tamamlandı f. Ön tasarım HW ve SW prototipleri ile bunların analizleri ve sonuçları belgelenir ve konfigürasyon kontrolü altına alınır G. Tüm dış bağımlılıklar tanımlanır ve belgelenir 2. Sistem Gereksinimleri Fonksiyonel Ayrıştırma Tamamlandı, örneğin: a. Sistemden segmente ve segmentten segmente gereksinim akışı ve türetilmesi alt sistem eksiksiz ve izlenebilir (TBD, TBS ve TBR yok) B. Alt sistemden bileşene gereksinim akışı ve türetilmesi tamamlandı ve izlenebilir (tüm TBD'ler, TBS'ler, TBR'ler ve ertelemeler tanımlanır) C. Segmentler arası ve alt sistemler arası arayüzler için gereksinim akışı ve türetilmesi eksiksizdir ve izlenebilirdir (tüm TBD'ler, TBS'ler, TBR'ler ve ertelemeler tanımlanır) D. Sistem, segmentler ve alt sistemler için tasarımdan tahsis edilen gereksinimler özel mühendislik tarafından doğrulanır e. Sistem, segmentler, alt sistemler, donanım bileşenleri ve segmentler arası ve alt sistemler arası arayüzler için fonksiyonel akış blok şemaları (FFBD'ler) tamamlanır ve üst ve alt seviye tahsis edilen gereksinimler arasında akış aşağı ve izlenebilirlik gösterilir F. Sistem ve segment, alt sistem ve bileşen tasarım özellikleri aşağıdadır. önemli TBD'ler veya açık öğeler olmadan yapılandırma yönetimi g. Ön uzun vadeli üretim gereklilikleri geliştirilir ve belgelenir 3. Oluşturulan tahsis edilen temel, onaylı Misyon ve Sisteme dayalıdır ve bunlara göre izlenebilirdir İşlevsel Ana Çizgiler, örneğin: a. Tahsis edilen temel, donanım hiyerarşisindeki tüm ürünler için fiziksel hiyerarşi ve tasarımdan işlevsel performans gerekliliklerine uygundur B. Sistem fonksiyonel ve performans gereksinimleri tüm sistem segmentlerine, alt sistemlere ve bileşenlere tahsis edilir, örneğin sistem, segment, alt sistem ve bileşen düzeyinde tahsis performans analizleri tamamlanır ve kabul edilen ticari sonuçlara göre izlenebilir C. Birlikte çalışabilirlik fonksiyonel performans gereksinimleri tüm sisteme, segmente, ve alt sistem ön tasarımları B. Birlikte Çalışabilirlik Mimarisi 1. Sistem tasarımının operasyonel mimariyi karşıladığını gösterin 2. Sistem tasarımı, tüm operasyonel düğümleri (OV-2) ve ilgili bağlantıyı tanımlar, örneğin, uydular, yer antenleri, komuta ve kontrol ekipmanı, görev verisi kullanıcı ekipmanı vb. Sayfa 81 / 168 Machine Translated by Google Ek D 3. Sistem tasarımı, organizasyona gerekli bilgileri sağladığını gösterir. OV-4 tarafından açıklanan sistem operatörleri ve kullanıcılar arasındaki ilişkiler 4. Sistem tasarımı, tüm operasyonel faaliyetleri destekleyen sistemleri ve alt sistemleri tanımlar. edinimden OV-5 tarafından açıklanan EOL işlemlerine kadar tüm yaşam döngüsü 5. Sistem tasarımı, operasyonel faaliyetler ile sistem arasında izlenebilirliği sağlayabilmektedir. fonksiyonlar (SV-5) 6. Sistem tasarımı, iç ve dış sistemler arasında gerekli olan eksiksiz bir veri alışverişi setini yansıtır. harici arayüzler (SV-6) 7. Sistem tasarım arabirimleri, TV-1'de gösterilen DISR birlikte çalışabilirlik standartlarını içerir; tüm benzersiz arayüzler, veri formatları, vb. sözleşmeyi yapan kurum tarafından onaylanmıştır 8. Sistem tasarımı NCOW-R, KIP Uyumluluğu ve IA Uyumluluğu C ile uyumludur. Tüm tasarım ticari çalışmaları, tahsis edilenleri destekleyen LCC ve CAIV analiz sonuçlarını içerir. teknik ve işlevsel temeller 1. LCC ve CAIV analizlerinin sonuçları, tahsis edilen performans parametrelerinin maliyet 2. Planlanan ve onaylanan program geliştirme, işletme ve sürdürme maliyetlerini temsil eden LCC ve CAIV modelleri, diğer "harici" sistemlere yönelik maliyet etkileri dahil olmak üzere temel alınır program geliştirme ve işletme ve sürdürme maliyetleri ile diğer “harici” sistemlere yönelik tahmini maliyet etkileri 4. LCC ve CAIV metodolojisi sunulur ve geçerli ticaret çalışmalarının yapıldığını gösterir. yürütülen D. Sistem entegrasyonu ve doğrulama fonksiyonel performans gereklilikleri, tüm segmentler, alt sistemler ve bileşenler 1. Segment, alt sistem ve bileşen düzeyinde doğrulama planlaması, doğrulama hedefleri, doğrulama türleri, seviyeleri ve sıralaması, yerleri ve toplanacak doğrulama verileri için gerekçe ile tamamlanır 2. Segment, alt sistem ve bileşen düzeyinde entegrasyon ve test planlaması, test hedefleri, test türü, seviyeleri ve sırası, test yerleri ve türetilecek test verileri için gerekçe ile tamamlanır 3. Sistem entegrasyonu ve doğrulama için süreç ve prosedürler geliştirilir 4. Segment, alt sistem ve bileşen entegrasyonu ve doğrulama için ön süreç ve prosedürler tanımlanır 5. Segment, alt sistem ve bileşen düzeyindeki çapraz referans gereksinimleri temel alınır ve tamamlanmış E. Sistem, segment, alt sistem ve bileşen düzeyinde arayüzler temel alınmıştır 1. Ön hazırlık dahili (segmentten segmente, alt sistemden alt sisteme ve bileşenden bileşen) arayüzleri tasarlanır ve konfigürasyon kontrolü altına alınır 2. Dış arayüzler (sistem, sistem sistemleri ve sistem ailesi) tasarımı tamamlandı ve konfigürasyon kontrolüne alındı 3. HWCI ile diğer ekipman, yazılım ve diğer öğeler arasındaki tüm fiziksel ve işlevsel arabirimler bellenim ve tesisler tanımlanır ve belgelenir 4. SWCI ile diğer yapılandırma öğeleri (hem dahili hem de harici) arasındaki tüm arayüzler, tanımlanmış ve belgelenmiş Sayfa 82 / 168 Machine Translated by Google Ek D F. Tahsis edilen ayrıştırma, her HWCI ve SWCI için tamamlanır 1. HWCI'ler ve SWCI'lar için ayrışma, gereksinimler ve işlevsel temel çizgilere göre izlenebilir 2. Tüm HWCI'ler ve SWCI'lar için tahsis edilen ayrıştırma, yapılandırma kontrolü altındadır, örneğin, gereksinimler ve işlevsel temel hatlardaki tüm değişiklikler tanımlanır, izlenir ve belgelenir 3. Ön hazırlık tüm HWCI'ler için fiziksel ((aka) ürün olarak da bilinir) temeli geliştirilmiştir ve SWCI'ler G. Sistem performansı (tasarım) spesifikasyonu, tahsis temel çizgisine göre izlenebilir; örneğin, segment, alt sistem ve bileşen spesifikasyonları geliştirilir ve sistem performans spesifikasyonuna göre izlenebilir 40.4.2 Sistem, Segment ve Alt Sistem Tasarımı Sistem, Segment ve Alt Sistem Tasarım Kavramlarının PDR'deki olgunluk kriteri örnekleri: A. Sistem, segment, alt sistem ve bileşen ön tasarımı tamamlandı ve temel alındı. 1. Ön tasarım, tüm hususlar arasında izlenebilirliği gösterir, yani: A. Tahsis edilen gereksinimler arasında, mühendislik ticaret çalışması sonuçları, teknoloji seçimleri ve teknik, programatik, zamanlama ve maliyet riskleri B. Ön tasarımın yeterliliği devam eden mühendislik kullanılarak kanıtlanmıştır. ilgili tüm özel mühendislik disiplinlerini dikkate alan analizler, örneğin: (1) Mühendislik analizleri, sistem bölümleri, alt sistemler ve bileşenler için donanım ve yazılım öğelerine tahsis edilen gereksinimlerin ayrışmasını yeterince destekler (2) Mühendislik analiz sonuçları, tasarımın CDR'ye devam et 2. Ön tasarımın izlenebilir olduğunu ve tahsis edilen tüm kritiklerle ilişkili olduğunu gösterin. Gereksinimler 3. Segment, alt sistem ve bileşende uygun marjlar ve ödenekler belirlenir seviyeler 4. Tasarım geliştirme planlaması tamamlanır ve temel alınır, örneğin, ön tasarım çizimleri konfigürasyon kontrolü altındadır 5. Bölümler arası ve bölümler arası ve alt sistemler için İşlevsel Akış Blok Diyagramları (FFBD'ler) dahil olmak üzere ön elektrik, mekanik ve işlevsel performans şemaları mevcuttur. 6. Ön GSE tarafından tanımlanan ve ön tasarım konseptleri, sistemin işlevsel ve tahsis edilen gereksinim temel çizgilerine ve sistem mimarisine göre izlenebilir şekilde geliştirilir 7. Sistemin kritik bileşenleri tanımlanır B. C4I tahsisleri, bölümler, alt sistemler ve bileşenler 1. Tahsisler, savaş yönetimi ve bilgi teknolojisi (BT) ihtiyaçlarını, bağımlılıkları ve sistem bölümleri, alt sistemler ve sistem, sistemler sistemi ve sistem ailesi arasındaki karşılıklı ilişkileri içerir. 2. Tahsisler, C4I birlikte çalışabilirliğini, birbirine bağlanabilirliğini, desteklenebilirliğini, senkronizasyonunu ve yeterlilik C. Ön tasarım, tehdit senaryoları ve tehdit ortamı parametreleriyle ilişkilendirilir, örneğin: tehdit senaryosu operasyonel ve çevresel tahsisler, tüm segmentler, alt sistemler ve bileşenler için izlenebilir ön tasarıma dahil edilir Sayfa 83 / 168 Machine Translated by Google Ek D D. Çevresel, örneğin, doğal, termal, nem, taşıma parametreleri, ön tasarım E. Ön tasarıma dahil edilen çevresel tahsisler, tüm segmentler, alt sistemler ve bileşenler için izlenebilir olmalıdır. F. Güvenilirlik, kullanılabilirlik, sürdürülebilirlik ve test edilebilirlik (RAM&T) tahsis edilen gereksinimler ön tasarıma dahil edilir, örneğin, RAM&T tahsisleri segmentlere, alt sistemlere ve bileşenlere kadar izlenebilir G. Sistemin operasyonel sürdürülmesi temel performans parametreleri, tüm ana sistem ve program gereklilikleri dahil olmak üzere ön tasarıma dahil edilir, örneğin, LCC sürdürme modeli ön tasarımla ilişkilendirilir H. Sistem risk modelindeki risk azaltma çözümleri, ön verilerle izlenebilir ve bunlarla ilişkilendirilebilir. tasarım I. Devam Eden Endüstriyel Üs (IB) değerlendirme sonuçları, ön tasarımla ilişkilendirilir; yeni risk alanlarına (SFR'de tanımlanmayan) öncelik verilir ve kaynaklar ve program gereklilikleri dahil olmak üzere azaltma süreçleri tanımlanır, örneğin: 1. IB değerlendirme verileri (örn. DMSMS [Dimishing Manufacturing Sources and Material Shortages], parçaların eskimesi), tanımlanmış ve örtük tasarım risk alanları ile ilişkilidir 2. Azaltma stratejileri, kaynaklar ve program dahil olmak üzere planlanır ve uygulanır Gereksinimler J. Tahsis edilen anahtar performans gereklilikleri, tüm ana sistemler için ön sistem tasarımına kadar izlenebilir. alt sistemler ve bileşenler, örneğin: 1. Tüm ana alt sistem ve bileşen tahsisleri ön tasarıma dahil edilir 2. Anahtar parametreler ve bilgiler (SFR'de geliştirilen ve değerlendirilen) her biri için uygulanır ana alt sistem ve bileşen ön tasarımı, örneğin: a. Başlıca performans parametreleri dahil edilmiştir b. Kritik teknolojiler geliştirme aşamasındadır c. Kritik tasarım ve üretim gereksinimleri ve zorlukları (SFR'de tanımlanmıştır) ön tasarım ile ilişkili Not: Aşağıdaki örnekler, PDR'de ele alınması beklenen veri türlerine ve ayrıntı düzeyine açıklık getirmeyi amaçlamaktadır. Yüklenicinin, ön sistem tasarımını ve bunun teknik, maliyet ve program parametrelerini etkin bir şekilde değerlendirmek ve değerlendirmek için gerekli olan, geliştirilmekte olan sistem tipine uygun alt sistemleri ve bileşenleri ve her bir alt sistem ve bileşen için uygun kriterleri belirlemesi amaçlanmaktadır. tasarımın bilinen arıza modlarından tanımlama ve kurtarmayı içerdiğini gösterin, yani: Elektrik Gücü için: • Ön Elektrik Güç Dağıtım Sistemi (EPDS) performans gereksinimleri, özellikleri ve işletim kriterleri, başlangıç güç bütçeleri, izin verilen marjlarla toplam güç talebi ve çalışma modları (sıklık ve süre) dahil olmak üzere tanımlanır. • Dikkate alınan güç kaynağı kaynaklarının tip(ler)inin, özel teknolojilerinin ve topolojilerinin ön seçimi ve değerlendirilmesi • Ön pil (veya enerji depolama) güç gereksinimleri tanımlanır ve çalışma modları tanımlanır (sıklık ve süre) • Pil ömrü gereksinimleri (BOL ve EOL) ve pil seçimini veya tasarımını etkileyebilecek diğer benzersiz gereksinimler • Aday pil hücresi teknolojileri belirlenir ve pil mimarileri tanımlanır Sayfa 84 / 168 Machine Translated by Google Ek D Yazılım için: • Ek C, bölüm 30.4 SAR "Kabul Kriterleri"nde (A, B, C, D, F, G, H, I ve J paragrafları) ayrıntıları verilen yazılım için "Kabul Kriterleri", SDP'de belirtilen ölçüde karşılanmıştır. seçilen yaşam döngüsü model(ler)ine göre. 40.4.3 Sistem, Segment ve Alt Sistem Doğrulama ve Onaylama Sistem, Segment ve Alt Sistem Tasarım Kavramlarının Kanıtı V&V gereksinimleri PDR'deki olgunluk kriterleri örnekleri: A. Sistem, Segment, Alt Sistem ve donanım Bileşeni V&V yaklaşımları, ön tasarım 1. Ön tasarım, ana sistem, segment, alt sistem ve donanımın bileşene tahsis edilen gereksinimler doğrulanabilir ve doğrulanabilir, örneğin: a. V&V yaklaşımları, sistemlerin ön tasarım adres sistemi, sistem, segment, alt sistem ve donanım bileşen seviyeleri için geliştirilmiştir. B. V&V yaklaşımları, analitik, modelleme ve simülasyon ile test süreçlerini ve ön tasarım prosedürleri C. V&V süreçleri ve prosedürleri, yeni teknoloji, doğrulama ve kalifikasyon teknik uygulamalarını, sistem düzeyinde gösterimleri ve testleri, harici kuruluşlardan ve/veya tesislerden gerekli desteği ve ön tasarım için kaynak gereksinimlerini ele alır d. Ön tasarım için V&V süreçleri ve prosedürleri kanıtlanmış, referanslı uygulamalar e. Güncellenen alt sistem ve bileşen VCRM'leri eksiksizdir ve sistem ve segmente tahsis edilmiş gereksinimler ile dahili ve harici arabirim tahsis edilmiş gerekliliklerle uyumludur, örn.: (1) Segment, alt sistem ve bileşen VCRM'leri sistem VCRM'sine göre izlenebilir (2) Güncellenen alt sistem ve bileşen VCRM'leri temel alınmıştır ve yapılandırma aşamasındadır yönetmek (3) Sistem, segment, alt sistem ve donanım bileşeni VCRM'lerindeki V&V yöntemleri, sistemi ve segmentini, alt sistemini ve donanım bileşenini doğrulamak için yeterlidir F. Yazılım testinin ve kalifikasyon planlarının tamamlanması ve gereksinimlerin testlere tahsisi, Ek C, 30.4 SAR "Kabul Kriterleri" paragraf E'de detaylandırılmıştır. B. Ön tasarım için sistem işletim fonksiyonları ve ortamları, yüklenicinin operasyon konsepti (OpsCon) ve tahsis edilen temel 1. Sistem V&V test ortamı tahsislerinin sistem tarafından izlenebilir olduğunu gösterin ön tasarım için performans spesifikasyonu 2. Ön tasarımın başlangıçta tanımlanan tüm tahsis edilmiş ve fiziksel çevresel parametreler, doğrulama yaklaşımları ve süreçlerle ilişkilendirildiğini ve bunlarla izlenebilir olduğunu gösterin C. DT&E öğeleri ön tasarım D ile ilişkilendirilir. OT&E tahsis edilen gereksinimler ön tasarım E'ye dahil edilir. Ön tasarıma dayalı olarak seçilen test yatakları ve test tesisleri, sistem, segment, alt sistem ve arayüz gereksinimleri doğrulamasını gerçekleştirmek için yeterli kabul edilir, örneğin: kritik donanım ve yazılım öğeleri için, V&V kullanımının tedarik edilmesi ve/veya programlanması için düzenlemeler kaynaklar (simülatörler, test yatakları, test tesisleri) gösterilmiştir. Sayfa 85 / 168 Machine Translated by Google Ek D temsili sistemi, segmenti, alt sistem modellerini ve simülasyonları gerçek dünya ortamlarına ve tahsis edilen gereksinimlere bağlamak için karşılaştırmalı test verileri gösterilir Ön tasarım için G. V&V risk yaklaşımları, süreçleri ve prosedürleri geliştirilir. SFR'de belirlenen teknoloji eksikliklerine dayalı olanlar da dahil olmak üzere H. V&V testi eksiklikleri, ön tasarım ve değerlendirilen etki ile ilişkilidir I. V&V kaynak gereksinimleri dahil olmak üzere SFR'de sistem risk modeline geliştirilen ve entegre edilen risk azaltma yaklaşımları, ön tasarımla ilişkilendirilir. Yazılım risk yönetimi faaliyetleri, Ek C paragraf 30.4 SAR “Kabul Kriterleri” paragraf G'de detaylandırılmıştır. Örneğin : 1. Anahtar performans gereksinimleri 2. Anahtar performans parametreleri 3. Eski sistemlerin, bileşenlerin ve teknolojinin kullanımı 4. Yeni tasarımların kullanımı A. Parçalar, Malzemeler ve Süreçler (PM&P) 1. PM&P tahsis edilen gereksinimler ön tasarıma dahil edilir 2. Parça performansını etkileyen ortamlar ve çevresel parametreler ön tasarıma dahil edilir 3. Risk değerlendirmelerini, uzun vadeli kalemleri, teknolojileri, tedarik kaynaklarını ve parçaların ortak kalite seviyelerini (yani güvenilirliği) ele alan ön tasarım için parça mühendisliği tasarım analizleri tamamlanır. 4. Ön tasarım analizlerinin sonuçları, ön parça listesinin geliştirilmesinde kullanılır. B. Test ve Değerlendirme (T&E) 1. İlk T&E planlaması, tüm test hedeflerini, test ortamlarını ve test kaynaklarını tahsis edilen gereksinimlerle ilişkilendiren ön tasarıma kadar izlenebilir. 2. Seçilen T&E yaklaşımları, ön tasarımla ilişkilidir, örneğin: A. Test yaklaşımları, sistemi, segmentleri, alt sistemleri ve bileşenlere tahsis edilmiş gereksinimleri doğrulamak için ön test süreçlerine ve prosedürlerine dönüştürülür. B. T&E süreçleri ve prosedürleri, her bir belirli test öğesi için özellikleri, etkililiği/etkileri ve marjları yakalar 3. Test ortam(lar)ı, işlemler, gerçekleştirilecek prosedürler, veri toplama gereklilikleri, dokümantasyon, analiz yöntemleri ve başarılı-kalıcı (örn. , başarı) kriterleri C. Hayatta Kalma ve Savunmasızlık 1. Ön tasarıma dahil edilen hayatta kalma ve güvenlik açığı tehdit tahsisleri, beklenen tehdit kategorileri, tehdit ortamları ve bunların olay 2. Sistem ve tehdit etkileşim analizleri tamamlandı; tehdit marjları belirlenir ve ön tasarım için temellendirilmiş 3. Beka kabiliyeti tasarım çözümleri, bilinen her bir tehdidi azaltmak için ön tasarımla ilişkilendirilir ve ön tasarıma dahil edilir. D. Çevresel Güvenlik ve İş Sağlığı (ES&OH) Sayfa 86 / 168 Machine Translated by Google Ek D 1. Yaşam döngüsü çevresel tahsisleri, ön tasarıma dahil edilir 2. PDR Program Odaklı ES&OH Değerlendirmesi (PESHE) uyum hedefleri için derlenen veriler, operasyonel ortamların karşılıklı ilişkilerinin ve karşılıklı bağımlılığının değerlendirilmesi de dahil olmak üzere ön tasarımla ilişkilendirilir. 3. Tehlikeli madde yönetimi ve kirlilik önleme süreçleri ve prosedürleri geliştirildi ve ön tasarımla ilişkilendirildi 4. Kritik insan sağlığı ve güvenliği faktörleri ön tasarımla ilişkilendirildi E. Kütlesel Özellikler 1. PDR için kütlesel özellik marjları (ortalama veya karmaşık) belirlenir ve izin verilen büyüme tahsisleri ve metrikler dahil olmak üzere ön tasarımla ilişkilendirilir 2. Hesaplanan ağırlık artışı, ağırlık merkezi ve atalet momenti parametreleri ön tasarıma tahsis edilir F. Sistem Güvenliği Mühendisliği (SSE) İletişim Güvenliği (COMSEC), Bilgi Güvencesi (IA) ve Program Koruması (PP): 1. SSE, COMSEC, IA ve PP güvenlik gereksinimleri tahsis edilir ve ön tasarım IAW Savunma Bakanlığı ve AF politikaları, direktifleri ve sistem spesifikasyonlarına dahil edilir 2. Program koruma karşı önlemlerinin uygulanması ele alınır 3. Güncellenen tehdit, güvenlik açığı, risk ve karşı önlem değerlendirmelerine dayalı SSE, COMSEC, IA ve PP gereklilikleri ön tasarımda ele alınır 4. Bilgi Güvencesi gereklilikleri ön sistem tasarımına dahil edilmiştir. DIACAP kullanan belgelendirme ve akreditasyon gereklilikleri ve programları 5. SSE, COMSEC, IA ve PP uygulaması ve sürdürülmesi için program temel maliyetleri güncellendi G. Birlikte Çalışabilirlik 1. Tahsis edilen sistem ve görev birlikte çalışabilirlik gereklilikleri, ön tasarım 2. DISR'ye dahil edilmesi onaylanan yeni ve benzersiz standartlardan tahsis edilen gereksinimler (yani, yeni veri formatları, karşılıklı bağımlılık, veri alışverişi protokolleri ve şemaları, Ethernet alternatifleri) ön tasarımla ilişkilendirilir ve bu tasarıma dahil edilir 3. Tüm karşılıklı ilişkiler ve karşılıklı bağımlılık için tahsis edilen birlikte çalışabilirlik gereksinimleri, ön tasarıma dahil edilir H. Güvenilirlik ve Sürdürebilirlik (R&M) 1. R&M tahsis edilen gereksinimler ön tasarıma dahil edilir 2. R&M analiz sonuçları ön tasarımla ilişkilendirilir, örneğin: A. Çevresel ve termal stresi uygulamak için yaklaşımlar ve süreçler geliştirilir ön tasarım için tarama (ESS ve TSS) B. Paketleme, Taşıma, Depolama ve Taşınabilirlik (PHS&T) R&M programında çevresel olarak tahsis edilen gereksinimler, ön tasarıma dahil edilir 3. Uygun seviyede ön sistem tasarımı için donanımsal FMECA gerçekleştirin (örn. kutu pim seviyesi veya parça-parça seviyesi), örneğin: A. Donanım FMECA seviyesinin sonuçlar için amaçlanan kullanımla tutarlı olduğunu gerekçelendirin b. Donanım FMECA'sının ekipmanın fiziksel yapısıyla tutarlı olduğunu gösterin ve analiz devre şemaları ile desteklenir Sayfa 87 / 168 Machine Translated by Google Ek D C. Zemin testi ve operasyon için varsayılan arıza modlarını tespit etmeye yönelik yöntemleri tanımlayın ve başarısızlığı azaltmak için olası araçları belirleyin d. Kritik öğeler listesi ve tek noktalı hatalar listesi hazırlayın e. Sistem güvenilirliği dahil olmak üzere tüm güvenlik sorunlarını ve ilgili analizleri uygun şekilde tanımlayın EOL imhası için I. EMI ve EMC 1. Elektromanyetik girişim kontrol süreçleri ve prosedürleri ön hazırlık için geliştirilmiştir. tasarım 2. Dahili ve harici EMI ve EMC tahsis edilmiş gereksinimler, ön tasarım 3. EMI duyarlılığı tahsis edilen gereksinimler ve kısıtlamalar, ön tasarım 4. EMI ve EMC kritik çevresel özellikler ve hassas unsurlar, ön tasarımla ilişkilendirilir J. İnsan Sistemleri Entegrasyonu (HSI) 1. Operatörler, kullanıcılar, bakımcılar, ve destekleyiciler ön tasarıma dahil edilmiştir 2. Kullanılabilirlik, idame ettirilebilirlik, işletilebilirlik ve/veya desteklenebilirlik, sistem işlevsel gereksinimlerinden ayrıştırılan tahsis edilen gereksinimler, ön tasarıma dahil edilir 3. Operasyonel personel, iş yükü ve tahsis edilen beceri düzeyi gereksinimleri ön tasarıma dahil edilmiştir, örneğin, kullanıcı arabirimi CONOPS'taki senaryolarla tutarlıdır K. İmalat ve Üretilebilirlik 1. Üretim ve üretilebilirlik yaklaşımları ve süreçleri geliştirilir ve ön tasarım 2. Ön tasarım için seçilen üretilebilirlik yaklaşımları, imalatın seçilen süreçler ön tasarımı destekler L. Yaşam Döngüsü Lojistiği 1. Desteklenebilirlik tahsis edilen gereksinimler ön tasarıma dahil edilir 2. Tasarım arayüzü, tedarik desteği, test ekipmanı, insan gücü ve personel, eğitim ve öğretim ekipmanı, PHS&T, tesisler, bilgisayar kaynakları dahil olmak üzere sistem seviyesindeki lojistik unsurlar ön tasarımla ilişkilendirilir , teknik veriler ve bakım planlaması 3. Lojistik Yönetim Bilgileri (LMI), tahsis edilenleri desteklemek için tamamlanır ve doğrulanır. ön tasarım için temel M. Sistem Güvenliği 1. Sistem güvenliğine tahsis edilen gereksinimler ön tasarıma dahil edilir 2. Segment ve alt sistem tehlike analizleri tamamlanır ve ön tasarımın test edilmesi, çalıştırılması ve bertaraf edilmesi için öncelikli güvenlik tehlikelerinin güncellenmiş dengeli bir listesi oluşturulur 3. Kritik insan sağlığı ve güvenliği faktörleri, ön tasarımla ilişkilendirilir 4. Temel alınan tehlikeli madde listesi (SFR'de derlenir ve önceliklendirilir) ön tasarımla ilişkilendirilir ve gerektiği şekilde güncellenir N. Kontaminasyon Kontrolü 1. Ön tasarım için kontaminasyon kontrol süreçleri ve prosedürleri geliştirilir. Sayfa 88 / 168 Machine Translated by Google Ek D 2. Malzeme gaz çıkışı anket sonuçları (SFR'den) aşağıdakilerle ilişkilendirilir ve gerektiğinde güncellenir: ön tasarım O. Kalite Güvencesi 1. Kalite ve ürün güvencesi tahsis edilen gereksinimler, ön tasarımla ilişkilendirilir ve ön tasarıma dahil edilir 2. Ön hazırlık için doğrulama, muayene ve test süreçleri ve prosedürleri geliştirilir. tasarım P. Çevresel Hususlar 1. Çevresel çalışma sonuçları (SFR'den) ön tasarım ile ilişkilendirilir 2. Ön çalışma için çevresel test ve değerlendirme yaklaşımları ve süreçleri geliştirilir tasarım 3. Güvenilirlik-çevresel tahsis gereklilikleri ön tasarıma dahil edilmiştir S. Yazılım 1. Yazılım Mühendisliği Disiplininin Kanıtı ve Uzmanlık Mühendisliği tanımlama ve değerlendirme olgunluk kriterleri Ek C, 30.4 SAR “Kabul Kriterleri”nde detaylandırılmıştır. R. Veri Depolama (Güvenlik, Erişim, Dağıtım ve Teslimat) 1. Depolama sistemi kapasitesi, esnekliği, ölçeklenebilirliği ve ön tasarım olgunluğu, örneğin: A. Analiz, gerekli güvenilirlik, sürdürülebilirlik ve kullanılabilirlik özelliklerini tanımlar. depolama sistemleri ortamları B. Sistem tasarım ömrünü ele alan kapasite, esneklik ve genişletilebilirlik parametreleri tamamen tanımlanmıştır C. Anahtar sistem bileşenleri tam olarak tanımlanmıştır. Depolama ortamı donanım ve yazılım yetenekleri ve türleri de dahil olmak üzere yedeklilik planları mevcuttur ve tam olarak tanımlanmıştır. D. Depolama sistemi yönetimi ve performans optimizasyonu ihtiyaçları (uygun bölümleme ve adreslenebilirlik sağlamak için yazılım yönetim araçları dahil) tamamen belirlenir e. Analiz, depolama sisteminin çalışması gereken işletim ortamlarını tam olarak belirlemiştir. Ele alınması gereken sertleştirme yönlerinin tanımlanması tam olarak açıklanmıştır. 2. Depolama Sistemi Mimarisi, örneğin: a. Depolama Sistemi Mimarisi, iletişim ve işleme kapasitesi dahil olmak üzere öğeleri tam olarak ele alır b. Depolama sistemi ihtiyaç türleri belirlenir ve mimariye tam olarak entegre edilir. Bu, merkezi ve dağıtılmış depolama gibi öğeleri içerir; çevrimiçi, yakın hat ve çevrimdışı ihtiyaçlar; arşivleme (uygunsa hiyerarşik depolama yönetimi dahil), yedekleme ve geri yükleme; ve veri çoğaltma. C. RAID, Depolama Alanı Ağları (SAN), Ağa Bağlı Depolama (NAS) ve Doğrudan Bağlı Depolama (DAS) gibi depolama donanımı bileşenleri tanımlanmış ve mimariye tamamen entegre edilmiştir. D. Veri yönetimi yazılımı yetenekleri tanımlanmış ve mimariye tamamen entegre edilmiştir. Bu, otomatik dosya taşıma ve şeffaf dosya alma gibi öğeleri içerir; hiyerarşik düzeyler arasında geçiş; ve medya kullanımı, hata tespiti ve değiştirilecek medyanın tanımlanması hakkında rapor veren yardımcı programlar. 3. Güvenlik, örneğin: Sayfa 89 / 168 Machine Translated by Google Ek D A. sağlayan kullanıcı bütünlüğü düzeyi (örneğin, erişim kontrol listeleri) tanımlanmıştır. karşılanması gereken sistem gereksinimleri B. Sistem gereksinimlerinin karşılanmasını sağlayan gerekli şifreleme düzeyi belirlenmiştir. ile ilgili C. CDS, MLS ve Security Enclave'ler gibi özel güvenlik yeteneklerine duyulan ihtiyaç belirlenmiş ve sistem gereksinimlerinin karşılanmasını sağlamak için depolama sistemine dahil edilmiştir 4. Veri Dağıtım Yöntemleri, örneğin: A. Hem bilgisayarı hem de insanı içerecek şekilde veri alıcılarının tam bir listesi hazırlanmıştır. ajanlar B. Çeşitli alıcılara veri dağıtma yöntem(ler)i tanımlanmıştır. Bu tür yöntemler arasında Abone Ol ve Yayınla, Gönder ve Çek ve genel veya kısıtlı Web tabanlı erişim yer alabilir. C. Veri dağıtım yöntemleri, depolama mimarisine tam olarak entegre edilmiştir ve sistem düzeyindeki gereksinimlerin karşılanmasını sağlayacaktır. 5. İşlevsellik, örneğin: A. Analiz, misyonu desteklemek için gerekli olabilecek işlevselliğin fiziksel yönlerini tam olarak tanımlamıştır b. Desteklenen platform türleri (sunucu ve istemci) ve işletim sistemleri tamamen tanımlanmış C. Veri bağlantısı ve taşıma protokolleri (örn. fiber kanal, sonsuz bant, SWCI) tam olarak tanımlanmış ve sistem mimarisine entegre edilmiş olup, sistem seviyesindeki gereksinimlerin karşılanmasını sağlar D. Spesifik raporlama (örn. kullanım) ve bakım metrikleri (örn. MTBF ve MTTR) tanımlanmıştır. Metrikler ve sistem düzeyinde gereksinimler arasındaki ön eşleme tamamlandı. 40.4.5 Entegre Teknik Risk Yönetimi ve Azaltma Entegre bir programın (teknik, maliyet, zaman çizelgesi ve performans) temel bir bileşeni olarak önerilen sistem tasarımı için, tanımlanmış risk öğelerinin ve unsurlarının artan düzeyde uygunluğu ve olgunluğu ile teknik risk yönetimi (RM) süreç kriterlerinin kanıtı sağlanır. ) PDR için RM ve Azaltma (RM&M) süreci. A. RM&M verileri, PDR düzeyinde olgunluğu destekler, örneğin: 1. Teknik ve performansı, maliyeti ve programı etkileyen önemli program düzeyinde riskler 2. Risk metriklerinin toplanması, analizi, izlenmesi ve raporlanması için risk yönetimi veri tabanı ve araçları 3. Risk azaltma ve azaltma stratejileri, bunlarla bağlantılı yakma planları Program IMP, IMS ve WBS'ye bağımlılıklar 4. Sürekli risk izleme ve gözden geçirme, belirleme, değerlendirme ve sıralama 5. Teknoloji ve üretim hazırlık düzeyi (TRL ve MRL) değerlendirmeleri ve ölçütleri 6. Gereksinim risk değerlendirme ölçütleri 7. Yazılım sorunlarının kritik risk yönetimi, ör. karmaşıklık, boyut, işlem hızı, verim, programlar, COTS kullanılabilirliği, eski yeniden kullanım uygunluğu ve yazılım geliştirme süreçleri ve araçları 8. Takip aşamaları için kapsamlı bir risk değerlendirmesi 9. TRL ve MRL değerlendirmeleri ve ölçümleri Sayfa 90 / 168 Machine Translated by Google Ek D 10. Eşikler ve eşiklerin aşıldığı durumlar için uygun eylem planları 11. Risk azaltma stratejileri uygulanabilir ve alternatif eylem yolları belirleniyor B. Sistemin, segmentin, arayüzün ve programın tüm yönlerinde kanıtlanmış bir RM&M derecesi mevcuttur kabul edilebilir bir riskle CDR'ye ilerlemeye izin vermek Sayfa 91 / 168 Machine Translated by Google Ek D Sayfa 92 / 168 Machine Translated by Google Ek E Ek E - Kritik Tasarım İncelemesi (CDR) 50. Kritik Tasarım İncelemesi (CDR) CDR multidisipliner bir teknik üründür. SE süreçleri normal olarak yeni Sistem Geliştirme ve Gösterim (SDD) sırasında, incelenmekte olan özellik ağacındaki sistem ve konfigürasyon öğesinin veya bir toplama ve işlevsel olarak ilgili CI grubunun üretime, gösterime ve teste devam etmek için yeterince olgun olup olmadığını değerlendirmek için yapılır. örneğin: bir. Program maliyeti, bütçe, program, risk ve diğer kullanıcı kısıtlamaları dahilinde belirtilen performans gereksinimlerini karşılayabilir B. Spesifikasyon ağacındaki her son öğe için işlevsel taban çizgisinden en düşük seviyeli CI'ye kadar gereksinimlerin akışı tamamlandı ve her yapılandırma öğesi ayrıntılı tasarımında yakalandı C. Sistemin son tasarımı, sistemdeki her yapılandırma öğesi için ürün özelliklerinde yer alır. sistem temeli D. Ürün temelindeki her CI, ayrıntılı ürün spesifikasyonunda ve tasarım belgelerinde ele alınmıştır. e. CI belirtimleri ve ilgili donanım çizimleri, konfigürasyon öğelerinin üretimi F. İncelenmekte olan tüm yazılım öğeleri için yazılım mimarisi ve ayrıntılı tasarımı tamamlandı SDP'de belirtilen ölçüde, seçilen yaşam döngüsü model(ler)ine dayalı olarak Karmaşık sistemler için, her bir alt sistem veya konfigürasyon öğesi için bir dizi CDR yürütülür ve bu da genel bir sistem CDR'sine yol açar. Bireysel incelemeler yapıldığında, genel sistem CDR'sinin vurgusu, genel sistem ayrıntılı tasarım gereksinimlerinin yanı sıra konfigürasyon öğesi işlevsel ve fiziksel arayüz tasarımına odaklanmalıdır. CDR, donanım, insan ve yazılımın (seçilen yaşam döngüsü model(ler)ine dayalı olarak SDP'de belirtilen ölçüde) nihai ayrıntılı tasarımların tamamlanıp tamamlanmadığını ve Entegre Ürün Ekibinin sistem fabrikasyonunu, demonstrasyonunu başlatmaya hazır olup olmadığını belirler. ve test edin. Her bir CDR, sistemin, segmentin, alt sistemin, CI'nin teknik kapsamı ve riskinin gözden geçirilmesi için uyarlanacak ve Sistem Mühendisliği Planını güncellemek için kullanılacaktır. 50.1 Genel Bir CDR, nihai teslim edilebilir donanım EI(ler) üretiminin devam etmesine izin verecek şekilde "yap-uygulama" temel çizgisine ulaşıldığında yürütülecektir. Pratik bir kural, imalat ve donanımın, yapım çizimlerinin ve ilgili talimatların %75 ila %90'ının tamamlanmış olması ve tüm kritik bileşen (örn. kritik güvenlik öğeleri ve kritik uygulama öğeleri) çizimlerinin %100'ünün tamamlanmış olmasıdır. . Sistem CDR'si, aşağıdakileri değerlendirmek için fabrikasyon, üretim ve kodlama sürümünden önce yürütülecektir: A. Donanım Ürün Spesifikasyonunda, Arayüz Tasarım Doküman(lar)ında, IDD(ler)inde ve mühendislik çizimlerinde yansıtıldığı şekliyle detaylı tasarım çözümleri, Sistem Spesifikasyonu tarafından belirlenen gereklilikleri karşılar b. Her bir yapılandırma öğesiyle ilişkili genel tasarım ve üretim riskleri, program maliyeti ve zaman çizelgesi dahilinde yönetilebilir. C. Tüm tasarım öğeleri, minimum olarak teknolojiye hazırlık düzeyi 6'ya (TRL 6) ve üretime hazırlık düzeyi 6'ya (MRL 6) ilerlemiştir. Sayfa 93 / 168 Machine Translated by Google Ek E Yazılım için, CDR, inceleme altındaki EI'deki tüm yazılımlar için yazılımın durumunu ve yazılım riskini değerlendirir. Yazılım için CDR'ye geçmeye hazır olma durumu aşağıdakiler tarafından belirlenir: a. SAR'ların sonuçları (yani, Ek C'ye göre SAR "Kabul Kriterleri"nin karşılanması) İncelenmekte olan yazılım için CDR'den önce düzenlenen B. Seçilen yaşam döngüsü model(ler)ine dayalı olarak, SDP'nin CDR tarafından bu tür bir tamamlamayı belirttiği tüm yazılım yapıları için ayrıntılı tasarımın tamamlanması 50.2 Amaç CDR'nin amacı, kritik ayrıntılı tasarım sorunlarını ele almak ve çözmektir, örneğin: A. Tasarım detaylarının, alt sisteme tahsis edilen tüm sistem gereksinimlerini doğru ve eksiksiz bir şekilde uygulayıp uygulamadığını ve nihai alt sistem gereksinimlerinin nihai sistem ayrıntılı tasarımına kadar izlenebilirliğinin sağlanıp sağlanmadığını belirleyin. B. Gereksinimler ve nihai ayrıntılı tasarımla ilgili akran incelemeleri tarafından elde edilen bulgunun doğrulanması dokümantasyon ayrıntılı tasarımda ele geçirildi ve uygulandı C. İncelenmekte olan CI'nin ayrıntılı tasarımının, CI geliştirme spesifikasyonlarının performans ve mühendislik uzmanlığı gereksinimlerini karşıladığını belirleme D. Yapılandırma öğesi ve diğer öğeler arasında ayrıntılı tasarım uyumluluğu oluşturun. ekipman, tesisler, bilgisayar yazılımı ve personel e. Üretilebilirliği ve CI risk alanlarını değerlendirin (teknik, maliyet ve program bazında) f. Kritik ve uzun vadeli HWCI ürün spesifikasyonlarını ve yazılımı gözden geçirin kritik yazılım işlevselliği için ayrıntılı tasarım G. HWCI ve SWCI tasarım çözümlerinin ayrıntılı tasarımının, performansının ve test özelliklerinin kabul edilebilirliğini belirleyin, örneğin: (1) Operasyon ve destek belgelerinin yeterliliğini belirleyin (2) Öne çıkan ve çözülmemiş sapmaları, feragatleri ve ertelemeleri gözden geçirin ( 3) Uygulanabilir olduğu şekilde güncellenmiş tasarım bilgileri h. Karşılaşılan sorunlar ve çözümler de dahil olmak üzere şirket içi testler sırasında elde edilen sonuçları değerlendirin uygulanan veya önerilen Ben. Sistem donanımı üzerinde yapılan üretilebilirlik analizlerinin sonuçlarını değerlendirmek j. En son maliyet tahminlerinin (geliştirme, üretim ve destek) tutarlı olduğunu doğrulayın detaylı tasarım ile k. Alt sistem gereksinimlerinin, alt sistemin ayrıntılı tasarımının ve test planlarının akran incelemelerinin sonuçlarının, sistem üretimi, gösterimi ve testine ilerlemek için tatmin edici bir temel oluşturduğunu onaylayın. 50.3 Hedef CDR'nin amacı, Yüklenici ve Satın Alma ajansının aşağıdakileri gözden geçirmesi ve değerlendirmesidir: A. Oluşturulmalarından bu yana işlevsel temel çizgi, mimari ve tahsis edilen temel çizgideki değişikliklerin durumu b. Öğeler arasındaki ve öğeler ile diğer sistemler, tesisler ve personel arasındaki arayüzlerin eksiksizliği ve uyumluluğu da dahil olmak üzere her konfigürasyon öğesi için tasarım temel çizgisi C. Gereksinimler ve nesnel, kapsamlı, nicel tasarım işlemleri açısından tasarım temelindeki her bir öğenin temeli Sayfa 94 / 168 Machine Translated by Google Ek E D. Seçilen sistemdeki her bir öğe için performans, maliyet, program ve risk arasındaki denge tasarım temeli e. İşlevsel ve tahsis temel çizgilerinin kaynağından son kullanıcıya kadar iki yönlü izlenebilirlik taban çizgisi ve arka tasarım F. Tasarım temel çizgisinin sözleşme gerekliliklerini karşılayabileceğinin doğrulanması g. Alt sistem ayrıntılı tasarımlarının aşağıdakileri belirlemek için değerlendirilmesi: (1) Kullanıcıya tahsis edilen tüm sistem gereksinimlerini doğru ve eksiksiz bir şekilde uygulayıp uygulamadıkları, alt sistem (2) Nihai alt sistem gereksinimlerinin nihai sistem detaylı tasarımına kadar izlenebilirliğinin sağlanıp sağlanmadığı bakımlı H. Gereksinimler ve nihai ayrıntılı tasarım dokümantasyonu hakkındaki meslektaş incelemelerinin sonuçları, en son maliyet tahminlerine (geliştirme, üretim ve destek) eklenir ve ayrıntılı tasarımla tutarlıdır. Ben. Test planları, sistem fabrikasyonuna ilerlemek için tatmin edici bir temel oluşturur, gösteri ve test CDR'nin tamamlanması şunları sağlayacaktır: A. Yerleşik bir sistem ürün temeli b. Sistem Geliştirme ve Gösterim için güncellenmiş bir risk değerlendirmesi C. Yüklenicinin sistem tarafından tahsis edilen temel çizgisinin, güncellenmiş maliyet analizi gereksinimleri açıklaması (CARD) ile tutarlı olduğunun doğrulanması d. Üretim, test ve yazılım dahil olmak üzere güncellenmiş bir program geliştirme programı geliştirme kritik yol sürücüleri e. Bu aşama için geçerli güncellemeleri olan onaylı bir SWCI Ek olarak, her prototip üzerinde aşağıdakiler için bir inceleme yapılacaktır: A. Ayrıntılı tasarımın ilerlemesini, teknik yeterliliğini ve risk çözümünü değerlendirin b. Öğe ve diğer öğeler, sistemler, tesisler ve personel arasındaki fiziksel ve işlevsel arayüzlerin uyumluluğu da dahil olmak üzere gelişen işlevsel mimari ve tahsis edilen temel ile uyumunu belirleyin. Not: Bir yapılandırma öğesi, donanım ve yazılım öğelerinden oluşabilir ve uçak gövdesi gibi öğeleri içerebilir. 50.4 CDR "Kabul Kriterleri" CDR'de, program risk faktörleri olan tüm ana sistem mühendisliği yönetim unsurları ve faaliyetleri dikkate alınır. CDR'nin amacı aşağıdakileri tespit etmektir: A. Her CI için tahsis temel çizgisi onaylandı B. Fiziksel (ürün olarak da bilinir) temel onaylandı c. Bir tasarım yayın temel çizgisi oluşturulmuş ve temel alınmıştır. Yazılım için, bu temel değerler, seçilen yaşam döngüsü model(ler)ine dayalı olarak SDP'de belirtilen ölçüde tamamlanmıştır. Bir CDR'nin hazırlanmasında ve programlanmasında, yüklenici, sözleşme makamını tatmin edecek şekilde aşağıdakileri gösterecektir: a. Tüm gereksinimler kriter öğeleri ele alınır b. Uygulanabilir tüm mühendislik faaliyetleri, kriteri desteklemek için uygun şekilde yürütülmüştür. C. Her kriter başarılı bir şekilde gerçekleştirilmiş sayılacaktır d. Uygulanabilir bir teknik ve program risk yönetimi stratejisi mevcuttur Sayfa 95 / 168 Machine Translated by Google Ek E e. Etkin ve verimli teknik ilerleme, tüm maliyetlerin, programların ve teknik performans gereksinimleri F. CDR hedefleri karşılanır ve veriler inceleme için hazırdır ve karar veritabanında bulunur CDR “Kabul Kriterleri” aşağıdaki beş ana kategori altında düzenlenecektir: 1. Sistem Mühendisliği ve Mimari Geliştirme (50.4.1) 2. Sistem, Segment ve Alt Sistem Tasarımı (50.4.2) 3. Sistem Doğrulama ve Doğrulama (50.4.3) 4. Mühendislik Disiplinleri ve Uzmanlık Mühendisliği (50.4.4) 5. Entegre Teknik Risk ve Azaltma (50.4.5) Bu gözden geçirme, yüklenicinin temel ve üzerinde anlaşmaya varılan CDR “Kabul Kriterlerini” destekleyen teknik çabasının nesnel bir kanıtı olacaktır, örneğin: a) Teknik çaba ve tasarımın durumu, operasyonel test başarısını gösteriyor mu? (operasyonel olarak uygun ve etkili)? b) Ayrıntılı tasarım, açıklandığı şekliyle, Yetenek Geliştirme Belgesini veya herhangi bir taslak Yetenek Üretim Belgesi mevcut mu? c) Donanım üretimi ve yazılım geliştirmenin uygun konfigürasyon yönetimi ile devam etmesini sağlamak için sistem ürün temeli oluşturulmuş ve belgelenmiş mi? Yani, yazılım ürünü temel çizgisi, seçilen yaşam döngüsü model(ler)ine dayalı olarak SDP'de belirtilen ölçüde tamamlandı mı? d) Ayrıntılı tasarım, İnsan Sistemleri Entegrasyonu (HSI) gerekliliklerini karşıladı mı? e) Programın başarılı olması için yeterli süreçler ve ölçümler mevcut mu? f) Geliştirme testi ve operasyonel test için riskler biliniyor ve yönetilebilir mi? g) Program çizelgesi yürütülebilir mi (teknik ve maliyet riskleri)? h) Programda uygun personel bulunuyor mu? i) Program, mevcut bütçe ve onaylanmış ürün temeli ile yürütülebilir mi? j) Detaylı tasarım, üretim bütçesi dahilinde üretilebilir mi? k) Kritik Güvenlik Öğeleri ve Kritik Uygulama Öğeleri tanımlanmış mı? l) Güncellenen maliyet tahmini mevcut bütçeye uygun mu? m) Yazılım geliştirmenin tamamlanma programları, CDR sırasındaki yazılım tasarımının durumu ile tutarlı mı? n) Sistem performansı, montajı, maliyeti, güvenilirliği veya emniyeti üzerinde en fazla etkiye sahip olan temel ürün özellikleri belirlendi mi? o) Anahtar özellikleri etkileyen kritik üretim süreçleri tanımlanmış mı? ve tasarım toleranslarını karşılama yetenekleri belirlendi mi? p) Kritik üretim süreçleri için süreç kontrol planları geliştirildi mi? q) Bu incelemeyle ilişkili tüm IMP ve IMS görevleri başarıyla kapatıldı mı ? Program yöneticisi, üretimin devam etmesine izin verecek şekilde donanım temel çizgisine ulaşıldığında CDR'yi yürütecektir. Sayfa 96 / 168 Machine Translated by Google Ek E 50.4.1 Sistem Mühendisliği ve Mimarisi Geliştirme Sistem Mühendisliği ve Mimarisi Kanıtı Geliştirme gereksinimleri olgunluk kriterleri örnekleri CDR'de: A. Her bir CI için tahsis edilen sistem, segment, alt sistem ve bileşen ve fiziksel gereksinimler eksiksiz, uygulanabilir, doğrulanabilir ve açıkça belirtilmiş olmalıdır. 1. Kritik Sistem Tasarımı, Tahsis Edilen ve Fiziksel Temel Çizgiler ile ilişkilidir ve bunlara yansıtılır, örn. sistemin, segmentin, alt sistemin ve bileşenin kritik tasarımı, sistem mimarisi görünümleri ve açıklamalarıyla ilişkilendirilir, tüm temel çizgilere kadar izlenebilir ve konfigürasyon kontrolü altında sürdürülür 2. Üretim, entegrasyon, operasyonlar, bakım ve eğitim için sistem, segment, alt sistem ve donanım bileşeni mimarilerinin (zaman çizelgeleri ve kapasiteler dahil) uçtan uca işleme kapasitesi doğrulanır ve temel alınır, örneğin: a. Sistemin, bölümlerin, alt sistemlerin ve bileşenlerin kritik tasarımı, sistemi ve bileşenlerini üretmek, doğrulamak, entegre etmek, konuşlandırmak, eğitmek, işletmek, desteklemek, sürdürmek ve elden çıkarmak için gerekli tüm ek ürünleri tanımlamak için genişletilmiş fiziksel hiyerarşiyi dikkate alır. ve kullanım ömrü boyunca bileşenler b. Nihai teknik tasarım, tüm oluşturma (çizimler ve işleme ve montaj talimatları dahil), satın alma veya doğrulama (tasarım kalifikasyonu ve teslimat kabul doğrulamaları ile işçilik testleri dahil); entegre etme, devreye alma (operasyonel hazırlığın doğrulanması dahil), eğitme, çalıştırma (teknik siparişler ve işletim talimatları dahil), destek ve sürdürme (bakım ve destek testleri dahil) ve/veya elden çıkarma gereksinimleri karşılayan her ürün (devlet malı hariç) için gereksinimler, tahsis edilen fonksiyonel ve fiziksel temeller 3. Sistem, segmentler, alt sistemler ve bileşenler için nihai tasarım verileri (örn. çizimler, spesifikasyonlar vb.), onları oluşturan öğelere kadar tamamlanır ve birim seviyeleri, örneğin, fiziksel hiyerarşinin her bir öğesi ve bileşeni için ve her bir ek sistem ürünü veya ayrı olarak üretilen, tedarik edilen, kaleme alınan (kılavuzlar ve diğer yazılı ve çizilmiş ürünler söz konusu olduğunda) ürünlerin entegre gruplaması için ayrılabilir dokümantasyon mevcuttur. , doğrulanmış, entegre edilmiş, konuşlandırılmış, eğitilmiş, çalıştırılmış, desteklenmiş veya elden çıkarılmış ve müşterinin gerektirdiği şekilde diğerleri 4. Her tasarım çözümü veya tasarım yayın temel çizgisinin diğer unsuru için kaynak gereksinimi ve değiş tokuş veya diğer temel, karar veri tabanında yakalanır ve B öğesiyle ilişkilendirilir. Sistem Gereksinimleri Tahsisi tamamlandı ve tüm CI'ler için doğrulandı 1. Gereksinim akışı ve alt sistemlerden bileşen öğelerine ve birim seviyelerine kadar türetme tamdır ve izlenebilirdir (hiçbir TBD, TBS, TBR veya erteleme tanımlanmamıştır) 2. Tasarım ve kullanıma hazır (OTS) spesifikasyonlar, üretim tarafından tamamlanır ve doğrulanır, doğrulama ve operasyon organizasyonları ve özel mühendislik grupları tarafından 3. Nihai fonksiyonel akış blok şemaları (FFBD'ler), tahsis edilen üst ve alt seviyeler arasında akışı ve izlenebilirliği gösteren sistem, segmentler, alt sistemler ve tüm arayüzler (dahili ve harici) için donanım bileşeni, öğe ve birim düzeyine kadar tamamlanır. Gereksinimler 4. Sistem bileşeni, öğe ve birim tasarım özellikleri yapılandırma aşamasındadır önemli TBD'ler veya açık öğeler olmadan yönetim 5. Nihai üretim gereksinimleri geliştirildi ve belgelendi Sayfa 97 / 168 Machine Translated by Google Ek E C. Fiziksel Referans Çizgisi oluşturulmuştur ve onaylı Misyon, Sistem İşlevsel ve Tahsis Temelleri. 1. Fiziksel temel, fiziksel hiyerarşideki her bir ürün için tahsis edilmiş ve türetilmiş tüm tasarım gereksinimleri ve tasarım kısıtlamalarını içerir 2. Sistemin fiziksel gereksinimleri tüm sistem bölümlerine, alt sistemlere ve donanıma dağıtılır bileşenler 3. Sistem, segment, alt sistem, donanım ve bileşen düzeyinde fiziksel analizler, öğe ve birim düzeyine kadar tamamlanır ve kabul edilen ticari sonuçlara (tasarım seçenekleri) göre izlenebilir 4. Birlikte çalışabilirlik fiziksel gereksinimleri tüm sisteme, segmente, alt sisteme, donanıma tahsis edilir bileşen ve harici arayüz kritik tasarımları 5. Fiziksel temel, CONOPS ve yüklenicinin OpsCon D. Baseline (BL) ile uyumludur 1. Yaşam döngüsü maliyet analizi sonuçları, fiziksel parametrelerin maliyete duyarlılığını içerir 2. Nihai onaylanmış program geliştirme, işletme ve sürdürme maliyetlerini temsil eden maliyet modelleri temel alınır ve diğer sistemlere olan maliyet etkilerini içerir 3. Yaşam döngüsü maliyeti ve sistem performansı ticari araştırmalarından elde edilen sonuçlar korunur ve değişiklikler için gerekçe belirlenir E. Sistem entegrasyonu ve doğrulama fiziksel gereksinimleri, bileşen, öğe ve birim düzeyine kadar dağıtılır 1. Bileşen, unsur ve birim düzeyinde doğrulama planlaması, doğrulama hedefleri, doğrulama türleri, seviyeleri ve sıralaması, yerleri ve toplanacak doğrulama verileri için gerekçe ile tamamlanır 2. Bileşen, öğe ve birim düzeyinde entegrasyon ve test planlaması, test hedeflerinin gerekçesi, test türü, seviyesi ve sırası, test yerleri ve türetilecek test verileri ile tamamlanır 3. Sistem entegrasyonu için süreçler ve prosedürler tamamlanır ve doğrulama, örneğin nihai süreçler ve prosedürler doğrulanır ve parça, alt sistem ve bileşen entegrasyonu ve öğe ve birim seviyelerine kadar doğrulama için temellendirilir. 4. Segment, alt sistem ve bileşen düzeyinde çapraz referans gereksinimleri tamamlanır ve öğe ve birim seviyelerine kadar temel alınır. F. Sistem, Segment, Alt Sistem ve Bileşen seviyesinde arayüzler tamamlandı 1. Nihai dahili arabirim tasarımı (bileşenden bileşene, birimden birime) tamamlandı 2. Nihai harici arabirim tasarımı (sistem, sistemler sistemi ve sistem ailesi) tamamlandı G. Her bir HWCI ve SWCI için fiziksel açıklamalar ve parametreler tamamlanmıştır. 1. HWCI'ler ve SWCI'lar için fiziksel temel, gereksinimlere göre izlenebilir, işlevsel ve tahsisat temelleri 2. Tüm HWCI'lar ve SWCI'lar için fiziksel temel, yapılandırma kontrolü altındadır; örneğin, gereksinimlerdeki, işlevsel ve tahsis ana hatlarındaki tüm değişiklikler tanımlanır, izlenir ve belgelenir H. Sistem performansı (tasarım) spesifikasyonu, tahsis edilen ve fiziksel temel çizgilere göre izlenebilir, örneğin bileşen, eleman ve birime kadar tüm spesifikasyonlar geliştirilir ve sistem performans spesifikasyonuna göre izlenebilir I. Tasarım Yayın Temel Çizgisi, kritik tasarım için tanımlanır ve işlevsel, tahsis edilmiş ve fiziksel temel çizgilere göre izlenebilir 1. Nihai bir tasarım yayın temel çizgisini desteklemek için yeterli bilgi mevcuttur (örn. tasarım çizimleri, tasarım spesifikasyonları, test ve analiz verileri). Sayfa 98 / 168 Machine Translated by Google Ek E 2. Tasarım yayın temel çizgisi, takaslara ve planlamaya, izleme, kararlara ve kontrole dayalı olarak yinelemeli olarak geliştirildi; her nihai tasarım seçimini desteklemek için yeterli takaslar yapıldı 3. Fiziksel (ürün olarak da bilinir) yapılandırma temeli, tahsis edilen temelde gereksinimlerin karşılandığını doğrulamak ve entegre sistemin kullanıcıların ihtiyaç duyduğu yetenekleri karşıladığını doğrulamak için geliştirme ürünlerini oluşturmak veya satın almak ve ardından entegre etmek için kullanılır. J. Uzun vadeli üretim spesifikasyonlarının geliştirilmesi tamamlandı ve temel alındı 1. Üretim spesifikasyonları, tahsis edilen ve fiziksel temel çizgilere göre izlenebilir 2. Kritik üretim (mağaza) çizimleri, İmalat ve Montaj, Entegrasyon ve Test (F/A, I&T) süreçler ve prosedürler temel alınır ve konfigürasyon kontrolü altına alınır K. Geliştirmeye bağlı olmayan yazılım ve donanım öğeleri (NDI) (örn. COTS, GOTS ve yeniden kullanım yazılımı) sisteme ek kısıtlamalar getirmediğinden emin olmak için gözden geçirilir 50.4.2 Sistem, Segment ve Alt Sistem Tasarımı CDR'de Sistem, Segment ve Alt Sistem Tasarım Kavramlarının Kanıtı olgunluk kriteri örnekleri: A. Sistem, segment, alt sistem ve bileşen kritik tasarımı (eleman ve birim seviyelerine kadar) tamamlandı 1. Kritik tasarım, tüm hususlar arasında izlenebilirlik gösterir: tahsis edilen ve fiziksel gereksinimler, mühendislik ticari çalışma sonuçları, teknoloji seçimleri ve teknik, programatik, zaman çizelgesi ve maliyet riskleri, örneğin: a. Kritik tasarımın yeterliliği devam eden mühendislik kullanılarak kanıtlanmıştır. ilgili tüm uzmanlık mühendislik disiplinlerini göz önünde bulundurarak analizler B. Mühendislik analizleri, bileşen, eleman ve birim seviyelerine kadar donanım ve yazılım yapılandırma öğeleri için fiziksel (ürün olarak da bilinir) gereksinimleri yeterince destekler. C. Mühendislik analizi sonuçları, tasarımın ilerlemeye hazır olduğunu yeterince gösterdi üretime D. Kritik tasarım yeteneklerini ve çözümlerini destekleyen mühendislik analizi, modelleme ve simülasyon sonuçları doğrulanır ve temel alınır 2. Kritik tasarımın izlenebilir olduğunu ve tüm kritik tahsis edilmiş ve fiziksel gereksinimlerle ilişkili olduğunu gösterin 3. Segmentler ve alt sistemler için tahsis temelinden türetilen fiziksel gereksinimler, bileşen, öğe ve birim düzeyinde eksiksiz ve optimal bir sentezi temsil eder gereksinim tasarımı 4. Segmentte, alt sistemde, ve bileşen seviyeleri elemanlarına ve birimlerine kadar 5. Tasarım geliştirme planlaması yürütülür ve izlenir, örneğin, konfigürasyon kontrolü (PDR'de) altına alınan kritik tasarım çizimleri korunur ve değişiklikler destekleyici gerekçelerle belgelenir 6. Bileşen elemanlarına ve birim seviyelerine kadar bölümler arası ve içi bölümler ve alt sistemler için işlevsel akış blok diyagramları (FFBD'ler) dahil olmak üzere nihai elektriksel, mekanik ve işlevsel performans şemaları mevcuttur. 7. Yer Destek Ekipmanı (ortak, özel, uçuş ve uçuş dışı test destek ekipmanı ve araçları dahil) seçimleri temel alınır ve ilk tasarımlar tamamlanır, örneğin: a. GSE yap ya da satın al kararları temel alınır b. İlk GSE Donanım Tahsis Listesi (HAL) tamamlandı Sayfa 99 / 168 Machine Translated by Google Ek E 8. Devlet tarafından sağlanan ekipman (GFE) ve yardımcı test donanımı doğrulanır ve amaçlanan kullanımları için temel alınır B. C4I fiziksel ve yazılım tahsisleri (seçilen yaşam döngüsü modellerine dayalı olarak SDP'de belirtilen ölçüde), sistem karşılıklı ilişkileri ve karşılıklı bağımlılığa ek olarak segmentler, alt sistemler ve donanım bileşenleri genelinde kritik tasarıma dahil edilir: 1. Fiziksel tahsisler, savaş yönetimi ve bilgi teknolojisi (BT) ihtiyaçlarını, bağımlılıkları ve sistem bölümleri, alt sistemler ve sistem ile sistemler sistemi ve sistem ailesi arasındaki arayüzleri içerir. 2. Fiziksel tahsisler, C4I birlikte çalışabilirliğini, birbirine bağlanabilirliğini, desteklenebilirliğini sağlar, senkronizasyon ve yeterlilik C. Kritik tasarımla ilişkilendirilen tehdit senaryoları ve tehdit ortamı parametreleri, örneğin tehdit senaryosu, kritik tasarıma dahil edilen operasyonel ve çevresel tahsisler, öğelerine ve birim seviyelerine kadar tüm segmentlere, alt sistemlere ve bileşenlere kadar izlenebilir. D. Kritik tasarımla ilişkilendirilen çevresel (örneğin, doğal, termal, nem, taşıma) parametreler, örneğin, çevresel tahsisatlar kritik tasarıma dahil edilir ve tüm segmentlere, alt sistemlere ve bileşen ve birim seviyelerine kadar izlenebilir E. Tahsis edilen güvenilirlik, kullanılabilirlik, bakım yapılabilirlik ve test edilebilirlik (RAM&T) gereksinimleri kritik tasarıma dahil edilmiştir, örneğin RAM&T tahsisleri, donanım için öğelerine ve birim seviyelerine ve yazılım için SWCI'ye kadar segmentlere, alt sistemlere ve bileşenlere kadar izlenebilir F • Sistemin operasyonel olarak sürdürülmesi temel performans parametreleri, tüm ana sistem ve program gereksinimleri ve PDR'de sunulan güncellenmiş LCC ve CAIV modelleme ve analiz çalışmaları dahil olmak üzere kritik tasarıma dahil edilir, örneğin: 1. LCC ve CAIV modellemesi ve analizleri, her HW ve SW tasarımı için uygulanır ve ilişkilendirilir. yanı sıra diğer "harici" sistemlere yönelik tahmini maliyet etkileri G. LCC sürdürme modeli, kritik tasarımla ilişkilendirilir H. Sistem risk modelindeki risk azaltma çözümleri, kritik tasarımla izlenebilir ve ilişkilendirilebilir tasarım I. Devam Eden Endüstriyel Temel değerlendirme sonuçları, kritik tasarımla ilişkilendirilir; yeni risk alanlarına (PDR'de tanımlanmayan) öncelik verilir ve kaynaklar ve program gereklilikleri dahil olmak üzere hafifletme süreci/süreçleri tanımlanır 1. IB değerlendirme verileri (örn. DMSMS, parçaların eskimesi), tanımlanmış ve örtük tasarım ve üretim risk alanları 2. Azaltma stratejileri, kaynaklar ve program dahil olmak üzere planlanır ve uygulanır Gereksinimler J. Tahsis edilen anahtar performans gereksinimleri, tüm ana alt sistemler ve bileşenler için kritik sistem tasarımına kadar izlenebilir 1. Tüm ana alt sistem ve bileşen tahsisleri, kritik tasarıma dahil edilir 2. Anahtar parametreler ve bilgiler (PDR'de geliştirilen ve değerlendirilen) her biri için uygulanır ana alt sistem ve bileşen kritik tasarımı, örneğin: a. Başlıca performans parametreleri dahil edilmiştir b. Kritik teknolojiler geliştirme aşamasındadır c. Kritik tasarım ve üretim gereksinimleri ve zorlukları (SFR'de tanımlanmıştır) kritik tasarımla ilişkili Sayfa 100 / 168 Machine Translated by Google Ek E Not: Aşağıdaki örnekler, CDR'de ele alınması beklenen veri türleri ve ayrıntı düzeyine açıklık getirmeyi amaçlamaktadır. Yüklenicinin, geliştirilmekte olan sistem tipine uygun alt sistemleri ve bileşenleri ve kritik sistem tasarımını, teknik, maliyet ve program parametrelerini etkili bir şekilde değerlendirmek ve değerlendirmek için gerekli olan her bir alt sistem ve bileşen için uygun kriterleri belirlemesi amaçlanmaktadır. tasarımın, PDR'de tanımlanan tüm arıza modları için kurtarma modlarını içerdiğini gösterin, örneğin: Elektrik Gücü için: • Başlangıç güç bütçeleri, izin verilen marjlarla toplam güç talebi ve çalışma modları (sıklık ve süre) dahil olmak üzere Elektrik Güç Dağıtım Sistemi (EPDS) performans gereksinimleri, özellikleri ve işletim kriterleri tanımlanır. • Güç kaynağı kaynaklarının tip(ler)inin seçimi ve değerlendirilmesi ile birlikte dikkate alınmaktadır. kendilerine özgü teknoloji ve topoloji • Pil (veya enerji depolama) güç gereksinimleri tanımlanır ve çalışma modları tanımlanır (sıklık ve süre) • Pil ömrü gereksinimleri (BOL ve EOL) ve pil seçimini veya tasarımını etkileyebilecek diğer benzersiz gereksinimler tanımlanmıştır. • Pil hücresi teknolojileri tanımlanır ve pil mimarileri tanımlanır Yazılım için: • Yazılım için Ek C, Bölüm 30.4'te ayrıntıları verilen "Kabul Kriterleri", örneğin SAR "Kabul Kriterleri" (A, B, C, D, F, G, H, I ve J paragrafları) belirtilen ölçüde karşılanır seçilen yaşam döngüsü model(ler)ine dayalı olarak SDP'de. 50.4.3 Sistem, Segment ve Alt Sistem Doğrulama ve Validasyon Sistem, Segment ve Alt Sistem tasarım kavramlarının kanıtı CDR'deki doğrulama ve doğrulama (V&V) gereksinimleri olgunluk kriteri örnekleri: A. Sistem, Segment, Alt Sistem ve Bileşen V&V yaklaşımları için geliştirilen Sistem, Segment ve Alt Sistem kritik tasarım 1. Kritik tasarım, ana sistem, segment, alt sistem ve bileşene tahsis edilmiş gereksinimlerin doğrulanabileceğini ve onaylanabileceğini gösterir, örneğin: a. V&V yaklaşımları, sistemlerin kritik tasarım adres sistemi, sistem, parça/alt sistem ve öğe ve birim seviyelerine kadar bileşen B. V&V yaklaşımları, kritik tasarım için analitik, modelleme ve simülasyon ve test süreçleri ve prosedürlerini içerir. C. V&V süreçleri ve prosedürleri, yeni teknoloji, doğrulama ve kalifikasyon teknik uygulamalarını, sistem düzeyinde gösterimleri ve testleri, harici kuruluşlardan ve/veya tesislerden gerekli desteği ve kritik tasarım için kaynak gereksinimlerini ele alır d. Kanıtlanmış, referans alınan uygulamalara dayalı kritik tasarım için V&V süreçleri ve prosedürleri e. Güncellenen alt sistem ve bileşen VCRM'leri eksiksizdir ve sistem ve segmente tahsis edilmiş gereklilikler ve dahili/harici arabirim tahsis edilmiş gerekliliklerle uyumludur, örneğin: (1) Bileşenler öğesi ve birim VCRM'leri sistem/segment/alt sisteme göre izlenebilir VCRM'ler (2) Güncellenen segment/alt sistem/bileşen VCRM'leri temel alınmıştır ve yapılandırma yönetimi altındadır (3) Sistemdeki V&V yöntemleri ve segment/alt sistem/bileşen VCRM'leri, sistemi ve segmentlerini/alt sistemlerini/bileşenlerini öğe/birim seviyelerine kadar doğrulamak için yeterlidir Sayfa 101 / 168 Machine Translated by Google Ek E B. Kritik tasarım için sistem operasyonel işlevleri ve ortamları, yüklenicinin operasyon konsepti (OpsCon) ve tahsis edilen ve fiziksel temeller. 1. Sistem V&V test ortamı tahsislerinin, kritik tasarım için sistem performans spesifikasyonuna göre izlenebilir olduğunu gösterin 2. Kritik tasarımın, tahsis edilen tüm kritik ve fiziksel çevresel parametreler, V&V yaklaşımları ve süreçleri C. DT&E öğeleri kritik tasarımla ilişkilendirilir D. OT&E tahsis edilir ve fiziksel gereksinimler kritik tasarıma dahil edilir E. Kritik tasarıma dayalı olarak test yatak(lar)ı ve test tesisleri seçilir sistem, segment/alt sistemi gerçekleştirmek için yeterli kabul edilir ve arayüz gereksinimlerinin doğrulanması, örneğin, kritik donanım ve yazılım öğelerinin tedarik edilmesi ve programlanması, V&V kaynakları olarak (örneğin, simülatörler, test yatakları, test tesisleri) eksiksiz ve yerinde olmalıdır. F. Kritik tasarım için bugüne kadar toplanan test gereklilikleri ve test verileri, spesifikasyonlar ve V&V çapraz referans matrisleri (VCRM'ler) aracılığıyla operasyonel gerekliliklere göre izlenebilir, örneğin, temsili sistem/segment/alt sistem modellerini ve aşağı simülasyonları sabitlemek için karşılaştırmalı test verilerinin kullanımı öğe ve birim seviyelerine gerçek dünya ortamlarına ve tahsis edilmiş ve fiziksel gereksinimler gösterilir G. Kritik tasarım için V&V risk yaklaşımları, süreçleri ve prosedürleri geliştirilir. Teknoloji eksikliklerine dayalı olanlar da dahil olmak üzere H. V&V test eksiklikleri PDR'de belirlenir ve kritik tasarım ve değerlendirilen etki ile ilişkilidir I. Risk azaltma yaklaşımları geliştirilir ve kritik tasarımla ilişkilendirilen kaynak gereksinimleri de dahil olmak üzere sistem risk modeline entegre edilir. Örneğin : 1. Temel performans gereksinimleri 2. Temel performans parametreleri 3. Eski sistemlerin/bileşenlerin/teknolojinin kullanımı 4. Yeni tasarımların kullanımı A. Parçalar, Malzemeler ve Süreçler (PM&P) 1. PM&P tahsis edildi ve fiziksel gereksinimler kritik tasarıma dahil edildi 2. Parça performansını etkileyen ortamlar ve çevresel parametreler, kritik tasarım 3. Parçaların risk değerlendirmelerini, teknolojilerini, tedarik kaynaklarını ve ortak kalite seviyelerini (yani güvenilirliği) ele alan kritik tasarım için parça mühendisliği tasarım analizleri tamamlanır, örneğin nihai kritik parçaları geliştirmek için kullanılan kritik tasarım analizlerinin sonuçları ve uzun vadeli ürün listesi tamamlandı B. Test ve Değerlendirme (T&E) 1. Nihai T&E planlaması, tüm test hedeflerini ilişkilendiren kritik tasarımla izlenebilir, test tahsis edilen gereksinimler için ortamlar ve test kaynakları 2. T&E yaklaşımları (PDR'de seçilen) doğrulanır ve kritik tasarımla ilişkilendirilir, örneğin: A. PDR'de geliştirilen temel test süreçleri ve prosedürlerinin, tahsis edilen sistemi, segmentleri ve alt sistemleri ve fiziksel gereksinimleri ve arabirimleri bileşen öğelerine ve birimlerine kadar doğrulayabildiğini gösterin Sayfa 102 / 168 Machine Translated by Google Ek E B. Temel T&E süreçleri ve prosedürleri, öğelerine ve birim seviyelerine kadar her bir test öğesinin özelliklerini, etkililiğini/etkinliklerini ve marjlarını yakalar. 3. Kritik tasarım için test/doğrulama veri toplama, azaltma ve analiz süreçleri, test ortam(lar)ı, gerçekleştirilecek işlemler ve prosedürler, veri toplama gereksinimleri, dokümantasyon, analiz yöntemleri ve geçiş dahil olmak üzere doğrulanır ve temel alınır. başarısız (yani başarı) kriterleri C. Beka Kabiliyeti ve Hassasiyet 1. Kritik tasarımın, tüm beklenen tehdit kategorileri, tehdit ortamları ve bunların meydana gelme olasılıkları için ön tasarıma dahil edilen hayatta kalma ve güvenlik açığı tehdit tahsislerini yakaladığını gösterin 2. Sistem/tehdit etkileşiminin, yerleşik ve temel alınan tehdidi analiz ettiğini gösterin PDR'deki marjlar, kritik tasarım için hala yeterli ve eksiksiz 3. Beka kabiliyeti tasarım çözümleri, bilinen her bir tehdidi azaltmak için gösterilen kritik tasarımla ilişkilendirilir ve bu tasarıma dahil edilir. D. Çevresel Güvenlik ve İş Sağlığı (ES&OH) 1. Yaşam döngüsü çevresel tahsisleri, kritik tasarıma dahil edilir 2. CDR Programatik ES&OH Değerlendirmesi (PESHE) uyum hedefleri için derlenen veriler, iç ve dış operasyonel ortamların değerlendirmesi dahil olmak üzere kritik tasarımla ilişkilendirilir 3. Tehlikeli madde yönetimi ve kirlilik önleme süreçleri ve prosedürleri doğrulanır ve kritik tasarıma dayalı 4. Kritik insan sağlığı ve güvenliği faktörleri temel alınır ve kritik tasarıma dahil edilir E. Kütlesel Özellikler 1. CDR için belirlenen kütle özellikleri marjları (ortalama veya karmaşık), kritik izin verilen büyüme tahsisleri ve ölçümleri dahil olmak üzere tasarım 2. Hesaplanan ağırlık artışı, ağırlık merkezi ve atalet momenti parametreleri kritik tasarım F. Sistem Güvenliği Mühendisliği (SSE), İletişim Güvenliği (COMSEC), Bilgi Güvencesi (IA) ve Program Koruması (PP): 1. Gereksinimler, kritik tasarım IAW DoD/AF politikalarına, direktiflerine ve sistem özelliklerine dahil edilmiştir, örneğin, program koruma planlaması tamamlanmış ve Milestone Decision Authority (MDA) onayı için hazırdır 2. Kritik tasarım için uygulanan sistem güvenlik konsepti ve spesifikasyonu, nihai bir temel güvenlik testi ve değerlendirme süreçleri ve prosedürlerini içerir 3. Tehdit, güvenlik açığı, risk değerlendirmeleri ve uygulanan temel koruma önlemleri güvenilir tesisler tamamlandı 4. Kritik tasarım ve belgelendirme ve akreditasyona dahil edilen Bilgi Güvencesi kontrolleri gereksinimler DIACAP'ın ardından sonuçlandırılır 5. Sistemin uygulanması ve sürdürülmesi için SSE, COMSEC, IA ve PP için program temel maliyetleri güncellenir G. Birlikte çalışabilirlik 1. Tahsis edilen ve fiziksel sistem ve görev birlikte çalışabilirlik gereksinimleri, kritik tasarım Sayfa 103 / 168 Machine Translated by Google Ek E 2. DISR'ye dahil edilmesi onaylanan yeni/benzersiz standartlardan tahsis edilen ve fiziksel gereksinimler (yani, yeni veri formatları, karşılıklı bağımlılık, veri değişim protokolleri/şemaları, Ethernet alternatifleri) kritik tasarımla ilişkilendirilir ve bu tasarıma dahil edilir 3. Tüm karşılıklı ilişkiler için tahsis edilmiş ve fiziksel birlikte çalışabilirlik gereksinimleri ve karşılıklı bağımlılık kritik tasarıma dahil edilmiştir H. Güvenilirlik ve Sürdürebilirlik (R&M) 1. Tahsis edilen R&M ve fiziksel gereksinimler kritik tasarıma dahil edilir 2. R&M analiz sonuçları kritik tasarımla ilişkilendirilir, örneğin: A. PDR'de Çevresel/Termal Stres Taramasının (ESS/TSS) uygulanması için geliştirilen yaklaşımlar ve süreçler doğrulanır ve kritik tasarım için temel alınır B. R&M programında Paketleme, Taşıma, Depolama ve Taşınabilirlik (PHS&T) çevresel tahsisli ve fiziksel gereksinimler, kritik tasarıma dahil edilir 3. Donanım FMECA'sını ve RMA&D Tahmin Analizlerini güncelleyin (nihai Güvenilirlik dahil Nihai tasarım için Gerilme Analizi – varsa yazılımla), örneğin: a. Kritik öğeler listesini ve tek noktalı hatalar listesini güncelleyin b. Tüm güvenlik sorunlarını ve ilgili analizleri uygun şekilde güncelleyin c. FMECA, tasarım uygulamasının etkilerini, örneğin, parçaların yakınlığı, konum tel demetleri vb. I.EMI/EMC 1. PDR'de geliştirilen elektromanyetik girişim kontrol süreçleri ve prosedürleri doğrulanır ve kritik tasarım için temellendirilmiş 2. Dahili ve harici EMI/EMC tahsis edilmiş ve fiziksel gereksinimler, kritik tasarım 3. EMI duyarlılığı tahsis edilir ve fiziksel gereksinimler ve kısıtlamalar, kritik tasarım 4. Ön tasarımın EMI/EMC kritik çevresel özelliklerinin ve hassas öğeler kritik tasarımla ilişkilendirilir J. İnsan Sistemleri Entegrasyonu (HSI) 1. Operatörler, kullanıcılar için tahsis edilen kullanıcı arayüzü donanımı/yazılımı ve fiziksel gereksinimler, bakımcılar ve destekleyiciler kritik tasarıma dahil edilmiştir 2. Kullanılabilirlik, bakım yapılabilirlik, çalıştırılabilirlik ve/veya desteklenebilirlik fiziksel gereksinimlerinin ayrıştırılması sistemden tahsis edilen gereksinimler kritik tasarıma dahil edilir 3. Operasyonel personel, iş yükü ve beceri düzeyi tahsis edilir ve fiziksel gereksinimler belirlenir kritik tasarıma dahil edildi K. İmalat ve Üretilebilirlik 1. Üretim ve üretilebilirlik yaklaşımlarının ve süreçlerinin geliştirildiğini gösterin ve kritik tasarımla ilişkili 2. Kritik tasarım için doğrulanan ve temel alınan üretilebilirlik prosedürleri ve yöntemleri, PDR'de seçilen üretim süreçlerinin kritik tasarımı desteklediğini gösterir. Sayfa 104 / 168 Machine Translated by Google Ek E L. Yaşam Döngüsü Lojistiği 1. Desteklenebilirlik tahsis edilir ve fiziksel gereksinimler kritik tasarıma dahil edilir 2. Tasarım arayüzü, tedarik desteği, test ekipmanı, insan gücü ve personel, eğitim ve öğretim ekipmanı, PHS&T, tesisler dahil olmak üzere sistem seviyesindeki lojistik unsurlar kritik tasarımla ilişkilendirilir , bilgisayar kaynakları, teknik veriler ve bakım planlaması 3. Lojistik Yönetim Bilgisi (LMI), kritik tasarım M için Tahsis ve Fiziksel temelleri desteklemek üzere tamamlanır ve doğrulanır. Sistem Güvenliği 1. Sistem güvenliği tahsis edilir ve fiziksel gereksinimler, kritik tasarıma dahil edilir 2. Segment/alt sistem tehlike analizleri tamamlanır ve güncellenmiş öncelikli güvenlik listesi kritik tasarımın test edilmesi, çalıştırılması ve bertaraf edilmesi için belirlenen tehlikeler 3. Kritik insan sağlığı ve güvenliği faktörleri temel alınır ve kritik tasarıma dahil edilir 4. Temel alınan tehlikeli madde listesi (PDR'de derlenir ve önceliklendirilir), kritik tasarımla ilişkilendirilir ve kritik tasarım için gerektiği şekilde güncellenir N. Kontaminasyon Kontrolü 1. PDR'de geliştirilen kontaminasyon kontrol süreçleri ve prosedürleri doğrulanır ve kritik tasarım 2. Malzeme gaz çıkışı anket sonuçları (PDR'den) aşağıdakilerle ilişkilendirilir ve gerektiğinde güncellenir: kritik tasarım O. Kalite Güvencesi 1. Tahsis edilen kalite/ürün güvencesi ve bunlarla ilişkilendirilen ve bunlara dahil edilen fiziksel gereksinimler kritik tasarım 2. PDR'de geliştirilen doğrulama, muayene ve test süreçleri ve prosedürleri doğrulanır ve kritik tasarım için temellendirilmiş P. Çevresel Hususlar 1. Çevresel çalışma sonuçları (PDR'den) aşağıdakilerle ilişkilendirilir ve gerektiğinde güncellenir: kritik tasarım 2. Kritik tasarım için çevresel test ve değerlendirme yaklaşımları ve süreçleri geliştirilir 3. Güvenilirlik-ısıl tahsis gereklilikleri kritik tasarıma dahil edilir S. Yazılım 1. Gereksinimler a. Yazılım gereksinimleri (yazılım arayüzü gereksinimleri dahil), seçilen yazılım yaşam döngüsü modeline dayalı olarak yazılım geliştirme planında belirtilen eksiksizlik düzeyine göre belirtilmiştir. B. Yazılım gereksinimleri (yazılım arayüzü gereksinimleri dahil) doğru, eksiksiz, tutarlı, uygulanabilir, doğrulanabilir ve açık ve net bir şekilde belirtilmiş olmalıdır. C. Yazılım gereksinimleri (yazılım arayüzü gereksinimleri dahil) takip edilir ve tamamen ebeveyn gereksinimlerini uygulamak D. Yazılım gereksinimleri, sistemden ve yazılım mimarisinden, sistem işletim konseptlerinden, ticaret araştırmalarından veya tasarım kararlarından türetilen gerekli gereksinimleri içerir. Sayfa 105 / 168 Machine Translated by Google Ek E 2. Yazılım arayüzü gereksinimleri dahil olmak üzere her yazılım gereksinimi, belirtilen bir veya daha fazla geçerli doğrulama yöntemine ve doğrulama düzeyine sahiptir ve bu yöntemler ve düzeyler, gereksinimi tam olarak doğrulamak için yeterlidir A. Ek C, bölümler 30.4 SAR "Kabul Kriterleri"nde (paragraf A, B, C, D, F, G, H, I ve J) ayrıntılı olarak açıklanan yazılım için "Kabul Kriterleri", SDP tabanlı seçilen yaşam döngüsü model(ler)inde B. Yazılım operasyonel kavramları, sistem ve yazılım mimarileri ile tutarlı bir yazılım perspektifinden (örn. başlatma/ başlatma, kapatma, işlemci yük devretme, artıklık yönetimi, kurtarma/geri yükleme) nominal ve nominal olmayan senaryoları içerir. C. Yazılım operasyonel kavramları, harici arabirim ile bilgi alışverişini içerir sistemler D. Yazılım operasyonel kavramları, operasyonel iş yükleri için senaryolar içerir, örn. Yazılım operasyonel kavramları, sistem operasyonel kavramlarıyla tutarlıdır 3. Mimari ve Tasarım a. Yazılım mimarisi, seçilen yazılım yaşam döngüsü modeline dayalı olarak, yazılım geliştirme planında istenen bütünlük düzeyine göre tanımlanmıştır. B. Fiziksel, mantıksal, gelişimsel, süreç ve davranışsal (kullanıcı) görünümler dahil olmak üzere yazılım mimarisi görünümleri doğru, eksiksiz, tutarlı, açık ve nettir c. Geliştirme dışı öğeler (NDI) (örn. COTS, GOTS ve yeniden kullanım yazılımı), yazılım mimarisinin bileşenlerine tamamen entegre edilmiştir. D. Geliştirme dışı öğeler (NDI) (örneğin, COTS, GOTS ve yeniden kullanım yazılımı) dahil olmak üzere yazılım mimarisi, yazılıma tahsis edilen üst düzey gereksinimlerin, yazılım gereksinimlerinin ve yazılım arabirimi gereksinimlerinin karşılanmasını sağlayacaktır. e. Her bir yazılım öğesinin tasarımı, yazılım geliştirme planı ve seçilen yazılım yaşam döngüsü modeli f ile tutarlı olarak yazılım birimleri düzeyinde detaylandırılmıştır. Her bir yazılım öğesinin tasarımı açık, doğru, eksiksiz, tutarlı ve nettir ve aşağıdakileri yeterince ele alır: (1) Tüm harici ve dahili arabirimlerin ayrıntılı tasarımı (2) Tüm dosyaların, veritabanlarının, paylaşılan belleğin vb. ayrıntılı tasarımı . ve bunların depolaması ve erişimi yöntemler (3) Kullanıcı arayüzü ekranlarının ve insan/sistem etkileşimlerinin ayrıntılı tasarımı (4) Yazılım öğesinin her birimi için kaynak (örn. COTS, değiştirilmemiş yeniden kullanım, değiştirilmiş yeniden kullanım veya yeni geliştirilen kod) ve programlama dil(ler)i kullanılan (5) Seçilen COTS yazılım ürünleri ve kurulum/konfigürasyon tasarım kararları (6) COTS'yi entegre etmek ve yazılım ürünlerini yeniden kullanmak için ayrıntılı yapıştırma kodunun tasarımı birbirleri ile ve yeni geliştirilen kod ile (7) Hem matematiksel hem de prosedürel algoritmalar dahil olmak üzere yazılım birimleri için ayrıntılı algoritma tasarımları (8) Yazılım öğelerinin dinamik yapısının ayrıntılı tasarımı (örneğin, süreçler/görevler, yürütme kontrolü akışı, öncelikler, sıralama, sürecin dinamik oluşturulması/silinmesi) (9) Özel durum işleme ve kurtarma yöntemlerinin ayrıntılı tasarımı (10) Kullanılacak Uygulama Programlama Arayüzleri (API'ler) (hem standartlaştırılmış API'ler hem de Bu sistem için benzersiz olarak tanımlanan API'ler) Sayfa 106 / 168 Machine Translated by Google Ek E G. Her bir yazılım öğesinin tasarımı, geçerli tüm standartları (örn. standartları, grafik kullanıcı arabirimi (GUI) standartları) H. Güncellenmiş yazılım mimarisi ve tasarımı, açık sistemlerin kullanımına yeterince hitap eder standartlar ve uygulanabilir birlikte çalışabilirlik ile ilgili tüm gereklilikleri karşılar Ben. Güncellenmiş yazılım mimarisi ve tasarımı, öğeler ve harici ve dahili arayüzler genelinde operasyonlar, bakım ve eğitim için uçtan uca işlemeyi (zaman çizelgeleri ve kapasite dahil) yeterince ele alır. J. Güncellenmiş yazılım mimarisi ve tasarımı, operasyonel veri tabanını yeterince ele alıyor yönetim ve kontrol k. Seçilen bilgi işlem kaynaklarındaki (örneğin, işlemciler, önbellek, bellek, veri yolları ve ağlar) yapılan güncellemeler, güncellenen sistem ve yazılım mimarilerine uygun şekilde dahil edilir ve tahsis edilen öğe, alt sistem, yazılım ve arayüz gereksinimlerinin karşılanmasını sağlar. l. Güncellenmiş yazılım mimarisi ve detaylı tasarım, uygun fonksiyonel ve her durum ve mod için performans gereksinimleri M. Güncellenmiş yazılım mimarisi ve ayrıntılı tasarım, bilgisayar donanımı ve yazılımı açısından beka ve dayanıklılık gereksinimlerini yeterince karşılar. Güncellenmiş yazılım mimarisi ve ayrıntılı tasarım, hata yönetimi ve entegre donanım-yazılım tanılama, hata algılama, izolasyon, yerelleştirme, geri yükleme ve onarım dahil olmak üzere desteklenebilirliği yeterince ele alır. o. Güncellenmiş yazılım mimarisi ve ayrıntılı tasarım, bilgisayar donanımına ve yazılım alt sistemlerine tahsis edilen güvenilirlik, güvenilirlik, sürdürülebilirlik ve kullanılabilirlik gereksinimlerini yeterince karşılar. 4. Mühendislik Analizi A. Güncellenmiş mühendislik analizleri, modelleri ve/veya simülasyonları, seçilen bilgisayar kaynakları (donanım ve yazılım) ile birlikte yazılım mimarisinin ve ayrıntılı tasarımın, Anahtar Performans Parametrelerini (KPP'ler) ve yönlendirici gereksinimleri karşılayacağını yeterince göstermektedir b. Güncellenmiş güvenilirlik, bakım yapılabilirlik ve kullanılabilirlik analizleri, yazılım mimarisi ve ayrıntılı tasarım ve seçilen bilgisayar kaynakları (donanım ve yazılım) ile tutarlıdır ve uygun şekilde yazılımın katkısını içerir C. Güncellenmiş güvenlik, bilgi güvencesi ve insan sistemleri entegrasyon analizleri, yazılım mimarisi ve ayrıntılı tasarım ve seçilen bilgisayar kaynakları (donanım ve yazılım) ile tutarlıdır ve uygun şekilde yazılımın katkısını içerir D. Güncellenmiş mühendislik analizleri ve ticaret çalışmaları, NDI (yeniden kullanım, COTS ve GOTS yazılım bileşenleri) hakkında yazılım mimarisini ve ayrıntılı tasarım kararlarını yeterince destekler ve seçilen altta yatan, destekleyici bilgisayar kaynaklarını (donanım ve yazılım) uygun şekilde dikkate alır. e. Güncellenmiş insan sistemleri entegrasyonu mühendislik analizleri ve ticaret çalışmaları (örn. çalışabilirlik, operatör iş yükü analizi), yazılım mimarisinin ve ayrıntılı tasarımın ve operatörlerin şirket içinde gerekli rolleri yerine getirmeleri için seçilen bilgisayar kaynaklarının (donanım ve yazılım) yeterliliğini göstermektedir. gerekli zaman çizelgeleri F. Güncellenmiş performans analizi, seçilen bilgisayar kaynakları (donanım ve yazılım) ile birlikte yazılım mimarisinin ve ayrıntılı tasarımın, yaşam döngüsünün bu noktası için yeterli marjlarla performans gereksinimlerini karşıladığını gösterir. Sayfa 107 / 168 Machine Translated by Google Ek E G. Güncellenmiş mühendislik analizleri ve ticari çalışmalar, seçilen bilgisayar kaynakları (donanım ve yazılım) ile birlikte yazılım mimarisinin ve ayrıntılı tasarımın, bilgisayar kaynak marjı gereksinimlerini karşılamak için yeterliliğini göstermektedir h. Yukarıdaki tüm analizler, mevcut yazılımın gerçek performansını dikkate alır (örn. seçilen donanımda prototipler, önceki yapılar, NDI) Ben. Yazılım 5'te uygulanacak algoritmaların yeterliliğini göstermek için güncellenmiş mühendislik modelleri ve simülasyonlar kullanılmıştır. Entegrasyon ve Doğrulama A. Güncellenen yazılım entegrasyonu ve kalifikasyon testi planları ve prosedürleri, seçilen yazılım yaşam döngüsü modeline dayalı olarak Yazılım Geliştirme Planında belirtilen eksiksizlik düzeyine göre tanımlanmıştır. B. Yazılım yeterlilik test planları ve prosedürleri geçerli, eksiksiz, kararlı, yazılım mimarisi, ayrıntılı tasarım ve daha yüksek seviyeli test planları ile tutarlı ve yazılım gereksinimleri ve yazılım arayüzü gereksinimleri için test yöntemleri ve test seviyeleri için yeterlilik gereklilikleri ile tutarlıdır. C. Yazılım gereksinimleri, doğrulanacakları yazılım yeterlilik testi planlarında açıklanan testlere tamamen tahsis edilir. D. Yazılım entegrasyonu, entegrasyon prosedürlerine göre, seçilen yaşam döngüsü modeline göre SDP tarafından belirtilen seviyeye kadar gerçekleştirilmiştir. e. Yazılım gereksinimleri doğrulama durumu belgelenir ve yapılandırma yönetilir. Durum, sistemden yazılıma kadar tüm gereksinim seviyeleri için kısmen doğrulanmış gereksinimlerin durumu da dahil olmak üzere bugüne kadar doğrulama sonuçlarını doğru bir şekilde yansıtır. Doğrulama durumu, uygun yeterlilik testi sonuçlarına kadar izlenir (örn. muayene, analiz, test veya demonstrasyon raporları) f. Ana yazılım oluşturma planı eksiksiz, uygulanabilir, yürütülebilir ve yazılım gereksinimleri, yazılım mimarisi, yazılım yeterlilik test planları ve daha yüksek seviye çizelgelerle tutarlıdır. 6. İzlenebilirlik a. Tüm yazılım izlenebilirlik bilgileri doğrudur, çift yönlüdür ve yazılıma, yazılım gereksinimlerine, yazılım arayüz gereksinimlerine, yazılım mimarisine ve ayrıntılı tasarım bileşenlerine ve yazılım yeterlilik test planlarına ve prosedürlerine tahsis edilen üst düzey gereksinimlerle tutarlıdır. B. Yazılım izlenebilirlik bilgisi, Seçilen yaşam döngüsü modeline dayalı Yazılım Geliştirme Planı 7. Risk Yönetimi A. Güncellenmiş risk değerlendirmesi, uygun olduğu şekilde aşağıdaki yazılım risklerini içerir: 1) Yazılım boyutu ve karmaşıklığı ile ilgili riskler 2) Yazılıma tahsis edilen gereksinimlerle ilgili riskler 3) Yazılım mimarisi ve tasarımıyla ilgili riskler 4) NDI (COTS, yeniden kullanım, GOTS) seçimi ve kullanımıyla ilgili riskler 5) Bilgi işlem kaynaklarının (örn. işlemciler, önbellek, bellek, otobüsler ve ağlar) 6) Bilgi işlem kaynakları için büyüme marjlarıyla ilgili riskler 7) Yazılım programları ile ilgili riskler Sayfa 108 / 168 Machine Translated by Google Ek E 8) Yazılım geliştirme, entegrasyon ve doğrulama süreçleri ve araçlarına ilişkin riskler 9) Veritabanlarının doldurulması, güncellenmesi, kontrolü ve doğrulanması ile ilgili riskler 10) Yazılım ve bilgisayar donanımı teknolojisi ile ilgili riskler 11) Yazılım güvenilirliği, sürdürülebilirliği ve kullanılabilirliği ile ilgili riskler 12) İnsan sistemleri entegrasyonu, güvenlik ve bilgi güvencesiyle ilgili riskler 13) Güncellenen yazılım risk yönetimi planı, güncellenen SDP'nin bir parçasıdır ve entegre edilmiştir güncellenmiş sistem risk yönetimi planı ile 14) Etkin yazılım risk yönetim planları mevcut ve planlara uygun olarak risk yönetim faaliyetleri yürütülüyor 8. Maliyetler ve Programlar A. Yazılım maliyet modelleri, gerçek verilerle (hem mevcut projeden hem de geçmiş geçmişten) kalibre edildi ve yazılım maliyetini güncellemek ve tahminleri planlamak için kullanıldı. B. Karmaşıklık ve diğer parametreler gibi gerçekçi yazılım maliyet sürücüleri ve varsayımlar belgelenir, belgelenen proje verileriyle doğrulanır ve güncel maliyet ve program tahminlerini geliştirmek için yazılım maliyet modellerinde kullanılır c. Güncellenmiş yazılım boyutu tahminleri desteklenebilir, geçmişe dayalıdır ve yazılım ve arabirim gereksinimleri ile yazılım mimarisi ve ayrıntılı tasarımla tutarlıdır d. Yazılım maliyeti ve program tahminleri, tahmin riskini karşılamak için yeterli marja sahiptir zamanın bu noktasına uygun e. Güncellenen yazılım çizelgeleri, IMS f dahil olmak üzere daha yüksek seviyeli çizelgelerle tutarlıdır. Güncellenen yaşam döngüsü maliyet tahmini, yazılım desteğini yeterince içerir g. COTS entegrasyonu ve yenileme, ekran tanımı, bilgi tabanı ve veritabanı popülasyonu gibi tüm yazılım görevleri, güncellenen yaşam döngüsü maliyet tahminlerine dahildir H. Güncellenen yaşam döngüsü maliyet tahmini, yazılım mimarisiyle tutarlıdır ve ayrıntılı tasarım 9. Mühendislik ve Yönetim Planları A. Güncellenen SDP, güncellenen IMP, SEMP ve diğer yönetim ve mühendislik planları b. Güncellenen SDP, tam yazılım geliştirme yaşam döngüsünü ele alır c. Güncellenen SDP, tüm yazılım ekibi üyelerini kapsayan, etki alanına uygun ve programın kapsamı ve karmaşıklığına uygun entegre bir süreçler, metodolojiler, araçlar ve ortamlar setini tanımlar. D. Güncellenen SDP, uygulanabilir, program kapsamı ve karmaşıklığına uygun ve tüm ekip üyeleri arasında tutarlı bir şekilde kullanılan seçilmiş yazılım geliştirme yaşam döngüsü modellerini açıklar. e. Yaşam döngüsü boyunca kullanım için güncellenmiş yazılım süreçleri, standartları, prosedürleri ve sözleşmeleri belgelenir, doğrulanır ve SDP f ile tutarlıdır. Yazılım geliştirme ve test ortamları, tüm ekip üyeleri genelinde sistem mühendisliği ortamlarıyla entegre olur G. Yazılım geliştirme ve test ortamları kurulur ve yazılım geliştirme ve test gereksinimlerini ve programlarını karşılamak için yeterli yetenek ve kapasiteye sahiptir. h. Yüklenici, yaşam döngüsünün bu noktasına uygun olarak yazılım süreçlerinin, standartlarının, prosedürlerinin ve sözleşmelerinin takip edildiğini göstermiştir. Sayfa 109 / 168 Machine Translated by Google Ek E Ben. CDR için yazılımla ilgili IMP başarıları, hedeflerini başarıyla karşıladı. başarı kriterleri 10. Metrikler ve Teknik Performans Ölçüleri A. Seçilen yazılım metrikleri için güncellenmiş tanımlar belgelenmiştir, açık ve doğrudur ve düzeltici eylemi tetiklemek için makul eşikleri içerir B. Güncellenmiş yazılım ölçümleri, program ve mühendislik yönetimi için bilgi ihtiyaçlarını karşılamak için yeterlidir ve bugüne kadar ölçüm deneyiminden öğrenilen dersleri içerir c. Yazılım ölçütleri, yaşam döngüsünün bu noktasına uygun olarak toplanıyor, analiz ediliyor, raporlanıyor ve risk yönetimi de dahil olmak üzere yönetim ve teknik kararlar için kullanılıyor. D. Belgelenmiş eşik değerlerin dışında kalan yazılım ölçümleri tarafından belirtilen temel sorunları ele almak için yeterli düzeltici eylemler tanımlanmıştır. e. TPM'ler toplanmakta, analiz edilmekte, raporlanmakta ve işlemciler, bellek, depolama ve giriş/çıkış kanalları ve ağları gibi tüm kritik bilgisayar kaynaklarının kullanımını yönetmek için kullanılmaktadır. F. TPM'ler toplanmakta, analiz edilmekte, raporlanmakta ve yanıt süresi ve zaman çizelgesi gereksinimleri dahil olmak üzere yazılımla ilgili KPP'lerin ve sürüş gereksinimlerinin yönetilmesi için kullanılmaktadır g. Belgelenmiş eşik değerlerin dışında kalan yazılım TPM'leri tarafından belirtilen temel sorunları ele almak için yeterli düzeltici eylemler tanımlanmıştır. H. Yüklenici, eşiklerin dışındaki metrikler veya TPM'ler için düzeltici eylemlerin başlatıldığını, yönetildiğini ve kapanışa kadar takip edildiğini göstermiştir i. Yazılım sorunu/ eksiklik raporu durumu, belgelenmiş sorunlara yönelik çözümlerin uygulanmasında ve doğrulanmasında yeterli ilerleme kaydedildiğini ve belgelenen sorunların önem derecelerine göre ele alındığını gösterir. R. Veri Depolama (Güvenlik, Erişim, Dağıtım ve Teslimat) 1. Depolama Sistemi Yeteneği/Esneklik/Ölçeklenebilirlik, kritik tasarım olgunluğu, örn.: A. Analiz, gerekli güvenilirlik, sürdürülebilirlik ve kullanılabilirlik özelliklerini tanımlar. depolama sistemleri ortamları B. Sistem tasarım ömrünü karşılayan kapasite, esneklik ve genişletilebilirlik parametreleri tanımlanır gereksinimler c. Temel sistem bileşenleri tanımlanır d. Yedekleme planları, depolama ortamı donanım ve yazılım yetenekleri de dahil olmak üzere tanımlanır ve türleri e. Depolama sistemi yönetimi ve performans optimizasyonu (yazılım yönetimi dahil) uygun bölümleme/adreslenebilirlik sağlamak için araçlar) tanımlanır F. Analiz, sağlamlaştırma da dahil olmak üzere depolama sistemi için operasyonel ortamları tanımladı seviyeler 2. Depolama Sistemi Mimarisi, örneğin: a. İletişim ve işleme dahil olmak üzere Depolama Sistemi Mimarisi tanımlanır kapasite B. Depolama sistemi gereksinimlerinin türleri tanımlanır ve mimariye tamamen entegre edilir, örneğin, merkezi ve dağıtılmış depolama; çevrimiçi, yakın hat ve çevrimdışı ihtiyaçlar; arşivleme (uygunsa hiyerarşik depolama yönetimi dahil), yedekleme ve geri yükleme; ve veri çoğaltma Sayfa 110 / 168 Machine Translated by Google Ek E C. RAID, Depolama Alanı Ağları (SAN), Ağa Bağlı Depolama (NAS) ve Doğrudan Bağlı Depolama (DAS) gibi depolama donanımı bileşenleri tanımlanmış ve mimariye entegre edilmiştir D. Veri yönetimi yazılımı yetenekleri tanımlanır ve mimariye entegre edilir, örneğin, otomatik dosya taşıma ve şeffaf dosya alma; hiyerarşik düzeyler arasında geçiş; ve medya kullanımı, hata tespiti ve değiştirilecek medyanın tanımlanması hakkında rapor veren yardımcı programlar 3. Güvenlik, örneğin: a. Kullanıcı bütünlüğü düzeyi (örn. erişim kontrol listeleri) tanımlanır B. Şifreleme düzeyi tanımlanır c. CDS, MLS ve Security Enclave'ler gibi özel güvenlik yetenekleri tanımlanır. 4. Veri Dağıtım Yöntemleri, örneğin: a. Hem bilgisayar hem de insan aracılarını içeren tam bir veri alıcı listesi tanımlanır b. Tanımlanan çeşitli alıcılara veri dağıtma yöntemi/yöntemleri, örn. Abone Ol/Yayınla, Bas/Çek ve küresel veya kısıtlı Web tabanlı erişim c. Veri dağıtım yöntemleri tanımlanır ve depolama mimarisine entegre edilir 5. İşlevsellik, örneğin: A. Analiz, görevi destekleyen işlevselliğin fiziksel yönlerini tanımladı B. Desteklenen platform türleri (sunucu/istemci) ve işletim sistemleri tanımlanır C. Veri bağlantısı/taşıma protokolleri (örn. fiber kanal, sonsuz bant, SWCI) tanımlanır ve sistem mimarisine entegre edilir d. Spesifik raporlama (örn. kullanım) ve bakım metrikleri (örn. MTBF/MTTR) tanımlanır e. Metrikler ile sistem düzeyinde gereksinimler arasındaki eşleme tamamlandı 50.4.5 Entegre Teknik Risk Yönetimi ve Azaltma Belirlenen risk öğelerinin/ unsurlarının artan doğruluk ve olgunluk düzeyi ile teknik risk yönetimi (RM) süreç kriteri örneklerinin kanıtı, entegre bir risk yönetiminin temel bir bileşeni olarak önerilen sistem tasarımı için sağlanır. CDR için program (teknik, maliyet, program ve performans) RM ve Azaltma (RM&M) süreci, örneğin: A. PDR'de yürürlükte olduğu gösterilen ve uygulanan risk azaltma süreçleri ve prosedürleri de dahil olmak üzere sağlam risk işleme planları kullanılıyor , kritik tasarım 1 için gerekli olduğu şekilde sürdürülür ve güncellenir. Risk işleme planları, eyleme geçmek için eşikleri içerir ve uygun önlemler alınmıştır. eşikler aşıldığında alınır 2. Risk azaltma süreçleri ve prosedürleri uygulanabilir ve alternatif eylem yolları belirleniyor. tanımlanmış 3. Risk işleme planları, sistemin, segmentin, karşılıklı bağımlılığın ve programın tüm yönlerindeki risk derecesinin, nihai öğelerin ayrıntılı tasarımına geçmek için kabul edilebilir olduğunu gösterir. B. PDR tarafından geliştirilen entegre sistem düzeyinde risk azaltma yaklaşımları ve süreçleri doğrulandı ve kritik tasarım için temel alınır ve aşağıdaki gibi öğeleri kapsayabilir: 1. Program düzeyindeki önemli riskler (teknik/performans, maliyet ve program) 2. Risk metriklerinin toplanması, analizi, izlenmesi ve raporlanması için risk yönetimi veri tabanı/araçları 3. Program IMP/EYS ve WBS'ye bağımlılıklarla bağlantılı risk azaltma/azaltma stratejileri, yakma planları 4. Sürekli risk izleme/inceleme, tanımlama, değerlendirme ve sıralama Sayfa 111 / 168 Machine Translated by Google Ek E 5. Teknoloji ve üretime hazırlık seviyesi (TRL ve MRL) değerlendirmeleri ve ölçütleri 6. Gereksinim risk değerlendirme ölçütleri 7. Yazılım sorunlarının kritik risk yönetimi, ör. karmaşıklık, boyut, işlem hızı, verim, çizelgeler, COTS kullanılabilirliği, eski yeniden kullanım uygunluğu, ve yazılım geliştirme süreçleri ve araçları 8. Sonraki aşamalar için kapsamlı bir risk değerlendirmesi 9. TRL ve MRL değerlendirme metrikleri Sayfa 112 / 168 Machine Translated by Google Ek F Ek F - Teste Hazırlık İncelemesi (TRR) 60. Teste Hazırlık İncelemesi (TRR) TRR, yüklenicinin bir EI için resmi bir doğrulama testi etkinliği başlatmaya hazır olduğunu doğrulamak için çok işlevli ve çok disiplinli bir inceleme ve süreç değerlendirmesidir. 60.1 Genel Her resmi doğrulama testi olayının başında bir TRR yürütülecektir. TRR, EI gerekliliklerini doğrulamak için test prosedürleri hazırlandıktan ve test prosedürlerinin başarılı bir provası yapıldıktan sonra ve herhangi bir resmi "kayıt için çalışma" başlamadan önce yapılmalıdır. “Prova”nın alternatifi veya uyarlanması ve ardından “kayıt için çalışma”nın uyarlanması olarak, bir test prosedürünün ilk çalıştırmasını aynı anda gerçekleştirirken doğrulamak (kırmızı çizgi) için çok disiplinli bir test prosedürü doğrulama ekibinin kullanılması kabul edilebilir. "kayıt için koş." TRR, yüklenici tarafından tanımlandığı veya uygun hale getirildiği ve sözleşmeyi yapan kurum tarafından onaylandığı şekilde, tek bir EI veya ilgili EI'lerin bir koleksiyonu için tutulacaktır. 60.2 Hedefler TRR'nin amacı, yüklenicinin bir veya daha fazla EI için resmi bir doğrulama testi etkinliği başlatmaya hazır olup olmadığını belirlemektir. Bu, aşağıdakilerin bir değerlendirmesini içerir: a. EI, teste başlamak için yeterince olgun B. Test verileriyle birlikte test prosedürleri, aşağıdakileri doğrulamak için yeterince sağlamdır: gereksinimler c. Test prosedürleri başarılı bir şekilde prova edilmiştir d. Disiplinli test süreçleri mevcuttur e. Test personeli mevcuttur ve roller ve sorumluluklar açıkça tanımlanmıştır 60.3 İncelenecek Öğeler Yüklenici, incelenmekte olan EI(ler) için sözleşme yapan kurum tarafından incelenmek üzere aşağıdaki öğeleri sunacaktır: A. Gereksinimler 1. EI gereksinimlerinin bu resmi doğrulama etkinliğinde doğrulanması planlanmaktadır 2. Bu EI gereksinimlerinde CDR'den beri onaylanan herhangi bir değişiklik 3. Gerekli doğrulama yöntemleri (Muayene (I), Analiz (A), Gösterim (D), Test (T)) ve her EI gereksinimi için doğrulama seviyelerinin bu resmi doğrulama etkinliğinde doğrulanması planlanmaktadır. B. Tasarım 1. CDR'den bu yana EI tasarımında meydana gelen ve EI doğrulamasını etkileyen herhangi bir değişiklik test yapmak C. Test Planları 1. CDR'den bu yana EI test planında meydana gelen herhangi bir değişiklik D. Test Prosedürleri 1. Düzenlenecek resmi doğrulama olayı için test senaryoları ve test prosedürleri; sınırlı: A. Test kurulum prosedürleri b. Test yürütme prosedürleri c. Veri yakalama prosedürleri Sayfa 113 / 168 Machine Translated by Google Ek F D. Veri analizi prosedürleri 2. Test prosedürleriyle birlikte kullanılacak test verilerinin açıklaması 3. Karşılaşılan anormallikler ve gereksinimlerin doğrulanmasıyla ilgili olası sorunlar da dahil olmak üzere prova çalışmalarının sonuçları. Test prosedürünün yeterlilik incelemelerinin kanıtı veya test prosedürünün meslektaş incelemeleri, eğer yaklaşım, kayıt için çalıştırma yaklaşımıyla eşzamanlı olarak test prosedürünün onaylanmasını içeriyorsa, "provaya" alternatif olarak sözleşme ile uyarlanmışsa kabul edilebilir. VE. İzlenebilirlik 1. Yürütülecek test durumları ve test prosedürleri ile gereklilikler arasındaki izlenebilirlik her biri tarafından doğrulanacak F. EI'nin Açıklaması 1. Test edilen EI donanımının ve yazılımının açıklaması 2. Yazılımın belirli sürümü veya sürümü de dahil olmak üzere test edilen EI donanımının ve yazılımının yapılandırması, örn., test edilen donanım ve yazılımın yapılandırmasının onayı CM organizasyonu tarafından 3. Varsa, EI için kullanıcı belgeleri (örn. kullanıcı kılavuzları, el kitapları) G. EI Sorunları ve Eksiklikleri 1. Doğrulamanın başlangıcından itibaren bilinen tüm EI donanım ve yazılım sorunları veya eksiklikleri olay, şiddet dereceleri ile 2. Bilinen sorunların veya eksikliklerin test üzerindeki beklenen etkisi H. Test Ortamı 1. Donanım, yazılım, otomatik test ekipmanı, test araçları, simülatörler, öykünücüler, sürücüler vb. dahil olmak üzere test ortamının açıklaması. 2. Test ortamı yapılandırmasının CM organizasyonu tarafından onaylanması 3. Test ortamı bileşenlerinin (donanım, yazılım, otomatik test ekipmanı, test araçları, simülatörler, öykünücüler, sürücüler vb. dahil) doğru olduğundan emin olmak için gerçekleştirilen doğrulama durumu doğrulama testi olayını desteklemek için gerekli işlevleri yerine getirir 4. Bilinen tüm test ortamı donanım ve yazılım sorunları veya eksiklikleri ve bunların test üzerindeki beklenen etkileri Süreçler, Roller, Sorumluluklar ve Yetkiler 1. Test personeli ve rolleri, sorumlulukları BEN. ve yetkileri: A. CM ve KG personeli ile test ekibi personeli dahil B. Hem Devlet hem de yüklenici dahil 2. İzlenecek test süreçleri, aşağıdakiler dahil: A. Bir nominal süreç b. Test anormallikleriyle karşılaşıldığında ve düzeltmelerin yapılması gerektiğinde yeniden test süreci c. Testin devam edip etmeyeceğini ve nasıl devam ettirilebileceğini belirlemek için bir anormallik değerlendirme süreci yürütme sırasında bir anormallik meydana geldikten sonra D. Test yürütme ve veri analizinin tamamlanmasının ardından, EI gereksinimlerinin doğrulama durumunun (tamamen doğrulandı, kısmen doğrulandı, doğrulanmadı) bir kayıt bakım süreci J. Test programları 1. Doğrulama testi etkinliği için saatlik programlar 2. Prova testi sürelerine dayalı programların gerekçesi Sayfa 114 / 168 Machine Translated by Google Ek F K. Test Sınırlamaları 1. Testi etkileyebilecek herhangi bir test sınırlaması veya diğer koşullar 60.4 TRR "Kabul Kriterleri" A. Gereksinimler 1. Bu test doğrulama etkinliğinde doğrulanması planlanan gereksinimler, onaylanan tüm değişiklikler B. Tasarım 1. CDR'den bu yana yapılan herhangi bir tasarım değişikliği, bu test doğrulama olayını olumsuz etkilemeyecektir. C. Test Planları 1. Test planındaki tüm değişiklikler onaylandı 2. Tüm değişiklikler dahil edilen test planı, eksiksiz tüm gereksinimlerin doğrulanması 3. Test planı, gerekli doğrulama yöntemleri ve seviyeleri ile tutarlıdır D. Test Prosedürleri 1. Test verileriyle birlikte her test durumu için test prosedürleri doğru, eksiksiz ve test senaryosuna tahsis edilen tüm gereksinimleri doğrulamak için yeterince sağlam 2. Test prosedürleri, gerekli doğrulama yöntemleri ve seviyeleri ile tutarlıdır 3. Test prosedürleri, tekrarlanabilecek kadar ayrıntılıdır 4. Test prosedürleri, onaylanmış test planına uygundur 5. Provalardan gelen tüm kırmızı çizgiler, test prosedürleri İzlenebilirlik 1. Test edilen gereksinimler ile test senaryoları arasında çift VE. yönlü izlenebilirlik sağlanır ve gereksinimlerin doğrulanacağı test prosedürleri 2. İzlenebilirlik doğru, eksiksiz ve tutarlıdır 3. Test prosedürlerinin adımlarının tanımlanması, her birinin doğrulanması durumunda sağlanır. gereksinim tamamlandı F. EI'nin Açıklaması 1. Test edilen EI açıkça tanımlanmıştır 2. EI, CM organizasyonu tarafından konfigürasyon kontrolü altındadır ve her bir EI'nin konfigürasyonu donanım ve yazılım bileşeni belgelenmiştir G. EI Sorunları ve Eksiklikleri 1. Donanım ve yazılım da dahil olmak üzere EI, doğrulama testine başlamak için yeterince olgun etkinlik 2. EI'nin test edilen bölümü için önem derecesi 1 veya 2 olan herhangi bir sorun veya eksiklik açık değil H. Test Ortamı 1. Donanım ve yazılım da dahil olmak üzere test ortamı, test edilen gereksinimleri doğrulayın 2. Donanım ve yazılım da dahil olmak üzere test ortamının, doğrulama testi olayını desteklemek için gerekli işlevleri doğru bir şekilde gerçekleştirmesini sağlamak için doğrulama testi olayından önce yeterli doğrulama gerçekleşti. Sayfa 115 / 168 Machine Translated by Google Ek F 3. Test ortamı, CM organizasyonu tarafından konfigürasyon kontrolü altındadır ve test ortamının her bir bileşeninin konfigürasyonu belgelenmiştir. BEN. Süreçler, Roller ve Sorumluluklar 1. Test uygulaması sırasında izlenecek süreçler tanımlanır ve belgelenir ve kontrollü ve disiplinli bir test uygulamasıyla sonuçlanacaktır 2. Personel rolleri ve sorumlulukları hem yüklenici hem de Devlet için iyi tanımlanmıştır 3. Mevcudiyet ve QA personelinin rolü aşağıdakileri sağlamak için yeterlidir: A. Test süreci izlenir b. Test yürütme, aşağıdaki gibi belgelenen herhangi bir sapma ile test prosedürlerini titizlikle takip eder: kırmızı Hat C. Testler sırasında karşılaşılan tüm problemler veya eksiklikler uygun şekilde belgelendirilir. formlar D. Test günlüğü, test başlangıcı, test bitişi, kesintiler ve anormallikler dahil olmak üzere testin yürütülmesini aslına uygun şekilde belgeler. J. Test Programları 1. Test programları uygulanabilir K. Test Sınırlamaları 1. Herhangi bir test sınırlaması, planlanan gereksinimleri doğrulama yeteneğini etkilemeyecektir. Sayfa 116 / 168 Machine Translated by Google Ek G Ek G - İşlevsel Yapılandırma Denetimi (FCA) 70. İşlevsel Yapılandırma Denetimi (FCA) Uzay Sistemlerine özel rehberlik için, 13 Haziran 2008 tarihli SMC STD SMCS-S-002 Konfigürasyon Yönetimine bakın. 70.1 Genel C. İşlevsel Yapılandırma Denetiminin (FCA) amacı, yapılandırma öğesinin gerçek performansının donanım Geliştirme veya Yazılım Gereksinimleri ve Arayüz Gereksinimleri Spesifikasyonlarına uygun olduğunu doğrulamaktır. Test verileri, donanımın veya bilgisayar yazılımının işlevsel ve tahsis edilmiş yapılandırma tanımlamasının gerektirdiği şekilde çalıştığını doğrulamak için gözden geçirilir. Devlet tarafından karşılanarak geliştirilen yapılandırma öğeleri için, bir FCA, yapılandırma öğesinin kabul edilmesi için bir ön koşul olacaktır. Yazılım için, Yazılım Test Raporlarının ve uygun olduğu şekilde Bilgisayar Sistemi Operatör Kılavuzu (CSOM), Yazılım Kullanıcı Kılavuzu (SUM) ve Bilgisayar Sistemi Teşhis Kılavuzunun (CSDM) geçerliliği ve eksiksizlik derecesi hakkında teknik bir anlayışa varılacaktır. ). B. Karmaşık bir yapılandırma öğesi için FCA, sözleşme kurumu tarafından belirtildiği takdirde, yapılandırma öğesinin geliştirilmesi boyunca kademeli olarak yürütülecek ve yapılandırma öğesinin yeterlilik testinin tamamlanmasıyla birlikte tüm tutarsızlıkların gözden geçirilmesiyle sona erecektir. son FCA. FCA, operasyonel envanter miktarlarının üretimi için serbest bırakılacak konfigürasyonun temsilcisi (prototip veya üretim öncesi) konfigürasyon öğesinin konfigürasyonu üzerinde yürütülecektir. Bir prototip veya ön üretim ürünü üretilmediğinde, FCA ilk üretim ürünü üzerinde yürütülecektir. Konfigürasyon öğesi yeterliliğinin yalnızca entegre sistem testi yoluyla belirlenebildiği durumlarda, bu tür konfigürasyon öğeleri için FCA'lar, bu tür entegre testler tamamlanana kadar tamamlanmış sayılmaz. C. Yerel sözleşme yönetimi ajansına yapılan yapılandırma öğesinin kabulü veya kabul edilmemesine ilişkin tavsiyeler, sonraki paragraflarda belirtilen prosedürlere ve gerekliliklere dayalıdır ve bunlara tabidir. D. Kritik Tasarım İncelemesinin (CDR) sonuçlarıyla devam ederek, amaçlanan kullanıma uygunluk açısından Paragraf 3.27'de tanımlanan mühendislik verilerini gözden geçirin. Gözden geçirme, Paragraf 100.6'da tartışılan kontrol listesi öğelerini uygun şekilde uyarlanmış olarak dikkate alacaktır. 70.2 Sözleşme Gereksinimleri A. FCA programları, yüklenici tarafından konfigürasyon öğesi geliştirme kaydına kaydedilecektir. Bir yapılandırma öğesi, işlevsel ve tahsis edilmiş temelin sözleşme kurumu kimlik doğrulaması olmadan denetlenemez. Ayrıca yüklenici, denetlenecek konfigürasyon öğesi için nihai taslak Ürün Spesifikasyonunu FCA'dan önce incelenmek üzere sözleşme yapan kuruma sunacaktır. 70.3 Yüklenicinin Sorumluluğu A. FCA tarihinden önce (denetlenecek konfigürasyon öğeleri için), yüklenici aşağıdaki bilgileri sözleşme makamına sağlayacaktır (bu bilgiler Bölüm 4 ve 5'in genel gerekliliklerine ek olarak sağlanacaktır): 1. Yüklenici temsili (test yöneticisi hazır bulunacaktır) 2. Denetlenecek öğelerin belirlenmesi: A. terminoloji B. Spesifikasyon kimlik numarası c. Yapılandırma öğe numarası Sayfa 117 / 168 Machine Translated by Google Ek G D. Sözleşme kurumu tarafından talep edilen veya onaylanan konfigürasyon kalemindeki tüm sapmaların/ feragatnamelerin güncel listesi e. Yapılandırılmış öğeleri otomatik test ekipmanıyla test etmek için Test Programının durumu (ne zaman uygulanabilir) 70.4 Prosedürler ve Gereksinimler Yüklenicinin test prosedürleri ve sonuçları, bir gereksinim testi doğrulama matrisinde (RTVM) EI'nin en düşük düzeyine kadar haritalanan spesifikasyon gereksinimlerine uygunluk açısından incelenecektir. A. Aşağıdaki test bilgileri FCA ekibi için mevcut olacaktır: 1. Konfigürasyon öğesi için test planları, spesifikasyonlar, açıklamalar, prosedürler ve raporlar 2. Ön kabul verilerinin kullanıldığı, başarıyla tamamlanmış fonksiyonel testlerin tam listesi kaydedildi 3. Ayrıntılı test verileri kaydedilmemişse başarılı fonksiyonel testlerin tam listesi 4. Spesifikasyonun gerektirdiği ancak henüz yapılmamış fonksiyonel testlerin tam listesi. (Sistem veya alt sistem testi olarak gerçekleştirilecek) 5. Üretim öncesi ve üretim test sonuçları B. Onaylanmış test prosedürleri ve doğrulanmış veriler (tanık olunan) ile gerçekleştirilen testler, spesifikasyon Bölüm 3'te belirtilen konfigürasyon öğesi performansını sağlamak ve Bölüm 4'te yer alan kalite güvence hükümlerini ve kalifikasyon gereksinimlerini karşılamak için yeterli olmalıdır. C. Test sırasında tam olarak doğrulanamayan performans parametreleri için yeterli analiz veya simülasyon gerçekleştirilmiş olacaktır. Analiz veya simülasyonların sonuçları, spesifikasyonda belirtildiği gibi konfigürasyon öğesi performansını sağlamak için yeterli olacaktır. D. FCA ekibi tarafından kullanılan test raporları, prosedürler ve veriler, FCA dakikaları E. Yüklenicinin, test verilerinin doğrulandığı konfigürasyon öğesinin fiziksel konfigürasyonunu belgelediğinden emin olmak için, konfigürasyon öğesinin yüklenicinin dahili belgelerinin (çizimlerinin) bir listesi gözden geçirilmelidir. F. Tedarik edilecek HWCI parçalarının çizimleri, imalat için gerekli olan test verilerinin çizimlere dahil edildiğinden veya çizimlerle birlikte verildiğinden emin olmak için seçici olarak örneklenmelidir. G. Kalite güvence testi hükümlerini geçemeyen Yapılandırma Öğeleri (CI'ler), geçememe nedeni olarak analiz edilmelidir. Bir CI yeniden kalifikasyona tabi tutulmadan önce hem CI'da hem de ilgili mühendislik verilerinde uygun düzeltmeler yapılmalıdır. H. Konfigürasyon öğesi için FCA'da mevcut olacak dokümantasyon ve donanım ve bilgisayar yazılımını ve gerçekleştirilecek görevleri tanımlayan bir kontrol listesi geliştirilecektir. Bkz. FCA Öncesi kontrol sayfası. BEN. J. Nitelikleri entegre sistem testinin tamamlanmasına bağlı olan konfigürasyon öğeleri için 70.4.3 FCA'nın kısmen tamamlanması paragrafına uygunluğu sağlamak için yeniden testler veya ek testler yapılmalıdır. K. SWCI'lar için aşağıdaki ek gereksinimler geçerli olacaktır: 1. Yüklenici, FCA ekibine denetlenmekte olan her bir SWCI için bir brifing verecek ve her bir SWCI için test sonuçlarını ve bulgularını tanımlayacaktır. Asgari olarak, tartışma, her bir öğe için önerilen bir çözüm, dahil edilen ve test edilen ECP'lerin bir açıklaması ve önerilenin yanı sıra tüm SWCI test çabasının genel bir sunumu dahil olmak üzere, karşılanmayan SWCI gerekliliklerini içerecektir. alanlar ve başarılar Sayfa 118 / 168 Machine Translated by Google Ek G 2. Resmi test planlarının, açıklamalarının ve prosedürlerinin denetimi yapılacak ve resmi test verileriyle karşılaştırılacaktır. Sonuçların tamlığı ve doğruluğu kontrol edilmelidir. Eksiklikler belgelenecek ve FCA tutanaklarının bir parçası haline getirilecektir. Tüm tutarsızlıklar için tamamlanma tarihleri açıkça belirlenmeli ve belgelenmelidir. 3. Raporların doğrulandığını doğrulamak için Yazılım Test Raporlarının bir denetimi yapılacaktır. SWCI testlerini doğru ve tam olarak tanımlayın 4. Onaylanan tüm ECP'ler, teknik olarak onaylandıklarından emin olmak için gözden geçirilmelidir. dahil edildi ve doğrulandı 5. Dokümantasyon seti boyunca doğruluk ve tutarlılığı sağlamak için daha önce teslim edilen dokümanlardaki tüm güncellemeler gözden geçirilecektir. dahil edildi ve tamamlandı 7. Arayüz gereksinimleri ve bu gereksinimlerin testi, SWCI'lar için gözden geçirilecektir. 8. Veritabanı özelliklerini, depolama tahsis verilerini ve zamanlamasını ve sıralamayı gözden geçirin belirtilen gerekliliklere uygunluk için özellikler 70.5 Denetim Sonrası Aksiyonlar A. Belirli bir FCA'nın tamamlanmasından sonra yüklenici, FCA tutanaklarının kopyalarını yayınlayacak ve dağıtacaktır. Sözleşme makamı, bir FCA'nın başarılı performansının PCA'nın yürütülmesi için gereklilikleri karşıladığının göstergesi ile FCA'nın tamamlandığını resmi olarak kabul eder. B. FCA'nın başarısı konfigürasyon öğesi Geliştirme Kaydı üzerine kaydedilecektir. yüklenici tarafından. Sayfa 119 / 168 Machine Translated by Google Ek H Ek H - Fiziksel Yapılandırma Denetimi (PCA) 80. Fiziksel Yapılandırma Denetimi (PCA) Uzay Sistemlerine özel rehberlik için, 13 Haziran 2008 tarihli SMC STD SMCS-S-002 Konfigürasyon Yönetimine bakın. 80.1 Genel A. Fiziksel Konfigürasyon Denetimi (PCA), ürün temelini oluşturmak için bir konfigürasyon öğesinin son halinin tasarım belgelerine karşı resmi olarak incelenmesi olacaktır. Denetimin başarıyla tamamlanmasından sonra, müteakip tüm değişiklikler mühendislik değişiklik eylemi tarafından işlenir. PCA ayrıca, belgelerde belirtilen kabul testi gereksinimlerinin, bir konfigürasyon öğesinin üretim birimlerinin kalite güvence faaliyetleri tarafından kabulü için yeterli olduğunu belirler. PCA, HWCI'lerin üretiminde kullanılan mühendislik çizimlerinin, spesifikasyonların, teknik verilerin ve testlerin ayrıntılı bir denetimini ve SWCI'lar için tasarım belgelerinin, listelerin ve kılavuzların ayrıntılı bir denetimini içerir. Gözden geçirme, as-built veya as-coded konfigürasyonunun bu dokümantasyona yansıtıldığından emin olmak için yayınlanan mühendislik dokümantasyonunun ve kalite kontrol kayıtlarının denetimini içerecektir. Yazılım için, Yazılım Ürün Spesifikasyonu ve Yazılım Sürüm Açıklaması PCA incelemesinin bir parçası olacaktır. B. PCA, konfigürasyon kalemlerinin ilk maddesi üzerinden yapılacak olup, halihazırda envanterde bulunan konfigürasyon kalemlerinin tekrarı olanlar, ihaleyi yapan kurum ve yüklenici tarafından ortaklaşa belirlenecek ve seçilecektir. PCA daha önce farklı bir yüklenici tarafından teslim edilen ilk ürün üzerinde gerçekleştirilmiş olsa da, yeni bir yüklenici tarafından teslim edilecek ilk konfigürasyon öğesi üzerinde bir PCA yürütülecektir. C. Konfigürasyon maddesi Ürün spesifikasyonunun sözleşme yapan kurum tarafından resmi olarak onaylanması ve bir PCA'nın tatmin edici bir şekilde tamamlanması, ürün temel çizgisinin oluşturulmasıyla sonuçlanır. D. Sorumlu sözleşme idare ofisine (CAO) yapılan yapılandırma öğesinin kabulü veya kabul edilmemesine ilişkin tavsiyeler, sonraki paragraflarda belirtilen prosedürlere ve gerekliliklere dayalıdır ve bunlara tabidir. E. Tüm işlem ve destek belgelerinin (örneğin, Bilgisayar Sistemi Operatör Kılavuzu (CSOM), Yazılım Kullanıcı Kılavuzu (SUM), Bilgisayar Sistemi Teşhis Kılavuzu (CSDM), Yazılım Programcı Kılavuzu (SPM), Üretici Yazılımı Destek Kılavuzu) için son bir inceleme yapılacaktır. (FSM)) formatı, eksiksizliği ve geçerli veri öğesi açıklamalarına uygunluğu kontrol etmek için. F. İşlevsel Konfigürasyon Denetiminin (FCA) sonuçlarıyla devam ederek, amaçlanan kullanıma uygunluk açısından Paragraf 3.15'te tanımlanan mühendislik verilerini gözden geçirin. Gözden geçirme, Paragraf 100.6'da tartışılan kontrol listesi öğelerini uygun şekilde uyarlanmış olarak dikkate almalıdır. 80.2 Sözleşme Gereksinimleri PCA programları, yüklenici tarafından konfigürasyon öğesi Geliştirme Kaydına kaydedilecektir. Denetlenmekte olan her bir SWCI için bir dizi güncel liste sağlanacaktır. Yüklenici, denetlenecek konfigürasyon öğesi için ürün spesifikasyonunun nihai taslağını PCA'dan önce incelenmek üzere sözleşme yapan kuruma sunacaktır. 80.3 Yüklenicinin Sorumluluğu A. Yüklenici, sözleşme yapan kuruma aşağıdaki bilgileri sağlayacaktır (bu bilgi, Bölüm 4 ve 5'in genel talimatlarına ve sözleşme gerekliliklerine uygun olarak sağlanacaktır): 1. Yüklenicinin temsili (test yöneticisi, katılım) Sayfa 120 / 168 Machine Translated by Google Ek H 2. Aşağıdakiler tarafından kabul edilecek kalemlerin tanımlanması: A. terminoloji B. Spesifikasyon kimlik numarası c. Yapılandırma öğesi tanımlayıcıları D. Seri numaraları e. Çizim ve parça numaraları F. Kimlik numaraları G. Kod tanımlama numaraları h. Yazılım envanteri numaralandırma sistemi 3. Talep edilen veya sözleşme makamının onayladığı konfigürasyon kalemine göre tüm sapmaları/feragatleri gösteren bir liste B. Denetlenmekte olan yapılandırma öğesiyle ilgili veriler denetim sırasında PCA ekibine sağlanmadıkça PCA gerçekleştirilemez. Yüklenici, bu bilgileri hazır referans için derleyecek ve hazır hale getirecektir. Gerekli bilgiler şunları içerecektir: 1. Konfigürasyon öğesi ürün spesifikasyonu 2. Konfigürasyon öğesine göre hem onaylanan hem de önemli değişiklikleri gösteren bir liste 3. Tam eksiklik listesi 4. Kabul testi prosedürleri ve ilgili test verileri 5. Revizyon mektupları dahil olmak üzere mühendislik çizim dizini 6. Çalıştırma, bakım ve resimli parça dökümü kılavuzları 7. Önerilen DD Form 250, “Malzeme Muayenesi ve Teslim Alma Raporu” 8. Onaylanmış terminoloji ve isim levhaları 9. Yazılım Programcısı Kılavuzları (SPM'ler), Yazılım Kullanıcı Kılavuzları (SUM'lar), Bilgisayar Sistemi Operatör Kılavuzu (CSOM), Bilgisayar Sistemi Tanılama Kılavuzu (CSDM) ve Ürün Yazılımı Destek Kılavuzu (FSM) 10. Yazılım sürümü açıklama belgesi 11. Her yapılandırma öğesi için FCA dakikaları 12. Kalite güvence programlarının bulguları ve durumu C. Yüklenici, denetim sırasında tüm verileri toplayacak ve PCA ekibinin kullanımına sunacaktır. öğe yapılandırmasını açıklar. Öğe yapılandırma verileri şunları içerecektir: 1. Donanım geliştirme spesifikasyonu, Yazılım Gereksinimleri Spesifikasyonu ve Arayüz Gereksinimleri Spesifikasyonlarının geçerli onaylanmış yayını, onaylanmış spesifikasyon değişiklik bildirimlerini ve onaylanmış sapmaları ve muafiyetleri içerecektir 2. Test sırasında fiilen yapılan tüm değişikliklerin tanımlanması 3 • Gerekli tüm değişikliklerin tanımlanması tamamlanmadı 4. Onaylanan tüm çizimler ve belgeler, konfigürasyon öğesi ürün spesifikasyonunda tanımlandığı şekilde en üstteki çizim numarasına göre. Tüm çizimler, sözleşmede belirtilen kategori ve biçimde olacaktır. 5. HWCI'ler için imalat talimat sayfaları, sözleşmeyi yapan kurum tarafından belirlenir. D. Yüklenici, seçilen üretim biriminin fiziksel konfigürasyonları ile FCA için kullanılan Geliştirme Birim(ler)i arasındaki herhangi bir farkı belirleyecek ve bunu ilgili kuruluşa belgeleyecek veya gösterecektir. Sayfa 121 / 168 Machine Translated by Google Ek H Bu farklılıkların seçilen birimlerin fonksiyonel özelliklerini bozmaması. 80.4 PCA Prosedürleri ve Gereksinimleri A. Çizim ve İmalat Talimat Sayfası İnceleme Talimatları: 1. Sözleşme yapan kurum eşbaşkanı tarafından belirlenen, her bir donanım parçası için temsili sayıda çizim ve ilgili imalat talimat sayfaları, doğruluklarını belirlemek ve mühendislik çizimleri ile donanıma yansıtılan yetkili değişiklikleri içerdiklerinden emin olmak için gözden geçirilecektir. . Sözleşmeyi yapan kurum eşbaşkanı tarafından aksi belirtilmedikçe, çizimlerin ve ilgili imalat talimat sayfalarının incelenmesi, geçerli bir numune alma esasına göre gerçekleştirilebilir. Bu gözden geçirmenin amacı, imalat talimat sayfalarının çizimlerde yer alan tüm tasarım detaylarını doğru bir şekilde yansıtmasını sağlamaktır. Donanım, imalat talimat föylerine uygun olarak yapıldığından, talimat föyleriyle tasarım detayları arasındaki farklılıklar ve çizimlerdeki değişiklikler donanıma da yansıtılacaktır. 2. İncelenen her çizim için aşağıdaki minimum bilgiler kaydedilecektir: A. Çizim numarası/başlığı (revizyon mektubu dahil) b. Çizim onay tarihi c. Bu çizimle ilişkili imalat talimat sayfalarının listesi (değişiklik harfi/başlıkları ve onay tarihi olan numaralar) d. Tutarsızlıklar/yorumlar e. Çizime yansıyan bir parça numarası örneği seçin. Program Parçaları Seçim Listesi ile uyumluluğu kontrol edin ve doğru parçaların gerçekten takılı olduğundan emin olmak için HWCI'yi inceleyin. 3. Asgari olarak, her bir çizim ve ilgili imalat talimat sayfaları için aşağıdaki muayeneler yapılmalıdır: a. İmalat talimatı sayfasında tanımlanan çizim numarası, en son yayınlananla eşleşmelidir. çizim B. İmalat talimat sayfalarındaki malzeme listesi, üzerinde tanımlanan malzemelerle eşleşmelidir. çizim C. Çizimde belirtilen tüm özel talimatlar üretimde olmalıdır. talimat sayfaları D. Çizimde belirtilen tüm boyutlar, toleranslar, yüzeyler vb. üretim talimatı sayfaları e. Çizimde belirtilen tüm özel işlemler imalatta tanımlanmalıdır. talimat sayfaları F. Çizimde belirtilen terminoloji açıklamaları, parça numaraları ve seri numarası işaretleri, imalat talimat sayfalarında tanımlanmalıdır. G. Onaylanan tüm değişikliklerin konfigürasyon öğesine dahil edildiğinden emin olmak için çizimleri ve ilgili üretim talimatı sayfalarını inceleyin. H. İncelenen tüm çizimlerin tanımlandığından emin olmak için sürüm kaydını kontrol edin i. Beşten fazla önemli değişiklik içeren çizimlerin sayısını kaydedin çizime bağlı J. Bir ana tertibatın çizimlerini ve/veya donanım yapılandırmasının kara kutusunu kontrol edin Üst çizimden parça parça çizimine kadar süreklilik için öğe Sayfa 122 / 168 Machine Translated by Google Ek H B. Üretilmekte olan konfigürasyonun yayınlanan mühendislik verilerini doğru bir şekilde yansıttığını belirlemek için yüklenicinin mühendislik yayın sistemi ve değişiklik kontrol prosedürleriyle doğrudan karşılaştırma yaparak HWCI için temel yapılandırmanın tüm kayıtlarının gözden geçirilmesi. Buna, halihazırda yapılandırılmış yedeklerin teslim edilmesini sağlamak için PCA'dan önce sağlanan yedeklerin ara sürümleri dahildir. C. Mühendislik değişikliklerinin işlenmesini ve resmi olarak serbest bırakılmasını düzgün bir şekilde kontrol etmek için yeterli olduklarını tespit etmek için yüklenicinin mühendislik serbest bırakma ve değişiklik kontrol sisteminin denetimi. Aşağıda belirtilen minimum ihtiyaçlar ve yetenekler, yüklenicinin mühendislik yayın kayıtları sistemi için gereklidir. Yüklenicinin formatları, sistemleri ve prosedürleri kullanılacaktır. Temel gereksinimlere ek bilgiler, yüklenicinin iç sisteminin bir parçası olarak kabul edilecektir. (*) (*) Sözleşme İdare Ofisi (CAO) Kalite Güvence Temsilcisi (QAR) kayıtları, yüklenicinin mevcut ve en yakın geçmiş performansının belirlenmesi amacıyla incelenebilir. D. Varsa, her çizim numarası için yüklenici, taşeron veya satıcı tarafından sağlanan bir izin kaydında asgari olarak aşağıdaki bilgiler yer alacaktır: 1. Seri numaraları, üst çizim numarası, şartname numarası 2. Çizim numarası, başlık , kod numarası, sayfa sayısı, yayın tarihi, değişiklik mektubu, değişiklik mektubu yayın tarihi, mühendislik değişiklik emri (ECO) numarası VE. Yüklenicinin serbest bırakma işlevi ve belgeleri aşağıdakileri belirleme yeteneğine sahip olacaktır: 1. Alt parça numaraları açısından herhangi bir seviyedeki herhangi bir parçanın bileşimi standart parçalar) 2. Standart parçalara montaj hariç, parça numarasını kullanan bir sonraki daha yüksek montaj 3. Diğer konfigürasyon öğelerine veya parça numaralarına göre konfigürasyon öğesinin veya parça numarasının bileşimi 4. Alt parçaların üzerinde bulunduğu konfigürasyon öğesi ve ilişkili seri numarası kullanılmış. (Bu, konfigürasyon öğeleri üretmeyen, asal seviyenin altındaki yükleniciler için geçerli değildir.) 5. Kısmen veya tamamen serbest bırakılan değişikliklerin hesap verebilirliği yapılandırma öğesi 6. Herhangi bir değişikliğin yapılandırma öğesi ve seri numarası geçerliliği 7. Standart olmayan herhangi bir parçada kullanılan standart özellik numarası veya standart parça numaraları sayı 8. Herhangi bir alt yüklenici, satıcı veya tedarikçi parça numarasıyla ilişkili yüklenici şartname belgesi ve şartname kontrol numaraları F. Mühendislik serbest bırakma sistemi ve ilgili belgeler aşağıdakileri yapabilecek kapasitede olacaktır: 1. Değişiklikleri belirleme ve sözleşmeyi yapan kurum tarafından resmi olarak kabul edilen değiştirilen konfigürasyonların kayıtlarını tutma 2. Üretim entegrasyonu için yayınlanan tüm mühendislik değişikliklerinin belirlenmesi. Bu değişiklikler, yapılandırma öğesinin resmi olarak kabul edilmesinden önce tamamen yayınlanacak ve dahil edilecektir. 3. Resmi düzenleme sırasında her yapılandırma öğesi için yayınlanan yapılandırmanın belirlenmesi kabul G. Eşgüdümlü eylemi sağlamak ve verilerin tek taraflı olarak açıklanmasını engellemek için mühendislik verileri merkezi bir otorite aracılığıyla yayınlanacak veya işlenecektir. H. Mühendislik değişiklik kontrol numaraları benzersiz olacaktır BEN. Nitelikli yapılandırma öğesinin yapılandırması ile denetlenen yapılandırma öğesinin yapılandırması arasındaki fark, PCA tutanaklarında kayda geçirilmelidir. Sayfa 123 / 168 Machine Translated by Google Ek H J. HWCI kabul testleri için veriler ve prosedürler, ürün spesifikasyonuna uygun olmalıdır. PCA ekibi, yeniden yapılacak kabul testlerini belirleyecektir ve gerekli denetimlerin, teftişlerin veya testlerin tamamına veya bir kısmına sözleşme yapan kurumun temsilcilerinin tanık olmasını sağlama ayrıcalığını saklı tutar. K. Kabul testi gerekliliklerini geçemeyen HWCI'ler onarılacaktır. gerekirse ve yüklenici tarafından ürün spesifikasyonuna uygun olarak PCA ekip lideri tarafından belirtilen şekilde yeniden test edilmelidir. Bu tür verilere bir hükümet temsilcisi tanık olacaktır. L. M. PCA ekibi, kullanıcıya sevkiyat sırasında yeterli kapsama sağlamak için hazırlanan yedekleme verilerini (yapılandırma öğesiyle birlikte gelen tüm ilk belgeler) doğru türler ve miktarlar açısından gözden geçirir. N. Ürün spesifikasyonuna uygun olduğunu gösteren yapılandırma öğelerinin kabulü aşağıdaki şekilde onaylanır: 1. PCA ekibi, yapılandırma öğesinin yerleşik olduğunu imzayla tasdik edecektir. çizimlere ve spesifikasyonlara uygun olarak O. Asgari olarak, PCA ekibi tarafından her bir SWCI üzerinde aşağıdaki eylemler gerçekleştirilecektir. denetlendi: 1. Yazılım ürün özelliklerini oluşturacak tüm belgeleri biçim ve biçim açısından inceleyin. eksiksizlik 2. Kaydedilen tutarsızlıklar ve alınan önlemler için FCA tutanaklarını inceleyin 3. Uygun girişler, semboller, etiketler, etiketler, referanslar ve veriler için tasarım açıklamalarını inceleyin Açıklamalar 4. Tutarlılık için üst düzey yazılım birimleri tasarım açıklamalarını alt düzey yazılım birimi açıklamalarıyla karşılaştırın 5. Doğruluk için tüm alt düzey tasarım açıklamalarını tüm yazılım listeleriyle karşılaştırın ve bütünlük 6. Biçimin tamlığı ve geçerli veri öğesi açıklamalarıyla uyumluluk için Yazılım Kullanıcı Kılavuz(lar)ı, Yazılım Programcı Kılavuzu, Bilgisayar Sistemi Kullanıcı Kılavuzu, Ürün Yazılımı Destek Kılavuzu ve Bilgisayar Sistemi Tanılama Kılavuzu'nu kontrol edin. (Bu kılavuzların resmi doğrulaması ve kabulü, prosedür içeriğinin doğru olduğundan emin olmak için sistem testine kadar saklanmalıdır.) 7. Uygunluğu sağlamak için gerçek SWCI dağıtım ortamını (kart desteleri, teypler, diskler, vb.) inceleyin Yazılım Gereksinimleri Spesifikasyonunun 5. Bölümü ile 8. Onaylanmış kodlama standartlarına uygunluk açısından açıklamalı listeleri inceleyin 80.5 Denetim Sonrası Aksiyonlar A. PCA için sunulan yapılandırma öğesinin ve yapılandırma öğesi ürün spesifikasyonunun Sözleşme makamı tarafından kabul edilmesi veya reddedilmesi, PCA'nın tamamlanmasından sonra, sorunun çözümü için uygun düzeltici eylemler de dahil olmak üzere, sorumlu sözleşme yönetimi kuruluşu veya diğer belirlenmiş kuruluş tarafından yazılı olarak yükleniciye sunulacaktır. eksiklikler PCA'nın tamamlanmasından sonra, yüklenici B. PCA tutanaklarının kopyalarını yayınlayacak ve dağıtacaktır. Sözleşme makamı, paragraf 4.2.4'te belirtildiği gibi PCA'nın tamamlandığını resmen kabul eder. Sayfa 124 / 168 Machine Translated by Google Ek H C. PCA'nın başarısı, yüklenici tarafından konfigürasyon öğesi Geliştirme Kaydına kaydedilecektir. Yalnızca FBL'nin başarılı bir şekilde doğrulanması/onaylanması ve düzeltici faaliyetin kapatılması, üretime devam etme yetkisi ile sonuçlanabilir Sayfa 125 / 168 Machine Translated by Google Ek I Ek I - Sistem Doğrulama İncelemesi (SVR) 90. Sistem Doğrulama İncelemesi (SVR) Sistem Doğrulama İncelemesi (SVR), daha önce Resmi Yeterlilik İncelemesi (FQR) olarak tanımlanmıştı. 90.1 Genel SVR'nin amacı, test yoluyla belirlenen sistemin yapılandırma öğelerinin gerçek performansının donanım Geliştirme Spesifikasyonu, Yazılım Gereksinimleri ve Arayüz Gereksinimleri Spesifikasyonlarına uygun olduğunu doğrulamak ve test raporlarını/verilerini belirlemek olacaktır. konfigürasyon öğelerinin kalifikasyon testlerinin sonuçlarını belgeler. Resmi belgelendirme noktası, sözleşme yapan kurum tarafından belirlenecek ve programın doğasına, belirli donanım ve yazılımın risk yönlerine ve yüklenicinin yapılandırma öğelerinin gerekliliklerini başarılı bir şekilde doğrulamadaki ilerlemesine bağlı olacaktır. Mümkün olduğunda, SVR, PCA'dan önce konfigürasyon öğesi/alt sistem testinin sonunda FCA ile birleştirilmelidir. Konfigürasyon öğelerinin kendi sistem ortamlarında çalışmasını sağlamak için FCA'da yeterli test sonuçları mevcut değilse, SVR, yapılandırma öğelerinin onaylanmasını sağlamak için gerekli testler başarıyla tamamlandığında Sistem testi sırasında (PCA sonrası) yürütülecektir (PCA sonrası). . Kombine olmayan FCA/SVR için, SVR'nin izlenebilirliği, korelasyonu ve eksiksizliği FCA ile sağlanmalı ve aynı çabanın tekrarından kaçınılmalıdır. 90.2 Gereksinimler A. SVR ve FCA'nın tek bir birleşik Denetim/İncelemede gerçekleştirilebildiği durumlarda, konfigürasyon öğelerinin yüklenici ve devlet "sertifikası", FCA'nın tamamlanmasından sonra yapılacaktır ve bu tür bir sertifika, SVR. B. Sözleşme yapan kurumdaki konfigürasyon öğelerinin kalifikasyonundan sorumlu kurum, FCA sırasında sistemin SVR için hazır olmadığına karar verdiğinde, SVR, sistemin kalifikasyonu hakkında yeterli bilginin mevcut olduğu belirlenene kadar ertelenecektir. SVR, gerekli görülmesi halinde Sistem testinin sonuna kadar ertelenebilir. C. Ayrı bir SVR gerektiğinde, yüklenici, bir SVR'yi doğrulamak için konfigürasyon öğelerinin test sonuçlarının yeterliliğini sözleşme makamına bildirecek ve Test ve Dağıtımdan Sorumlu Müdür Yardımcısı ile gündemi koordine edecektir. SVR ekibi, FCA ekibi için gerekli olanla aynı şekilde monte edilecektir. SVR'de FCA çalışmasının tekrarı olmayacaktır; ancak, aşağıdaki ek çabalar gerçekleştirilmelidir: 1. FCA tutanaklarının bir incelemesi yapılmalı ve SVR, bir FCA'nın uzantısı. Konfigürasyon öğelerinin Sistem/Alt Sistem, Yazılım Gereksinimleri ve Arayüz Gereksinimleri Spesifikasyonlarına göre kalifikasyonunu sağlamak için yeni/ek yeterlilik verileri denetlenmeli ve gözden geçirilmelidir. 2. Sistem testi sırasında konfigürasyon öğesi kalifikasyonuna karşı gerçekleştirilen herhangi bir test, kabul edilebilir. 3. Yüklenici, sözleşme yapan kurum tarafından belgelendirme bildiriminden sonra, kalifikasyonun sistem belgelendirme tarihini ve ilgili test(ler)in sonuçlarını ortaya koyan test raporlarının/belgelerinin kimliğini Geliştirme Kaydı konfigürasyon öğesine girecektir. . D. Gündem, ekip organizasyonu, gözden geçirme prosedürleri, gözden geçirilecek veriler vb. gibi diğer tüm faktörler, SVR'yi gerçekleştirmek için gerekli olduğu ölçüde bu standardın FCA ve Genel Gereklilikler ve Prosedürler bölümlerinde belirtildiği gibi gerçekleştirilecektir. 90.3 İnceleme Sonrası İşlemi A. SVR'yi yürüttükten sonra, yüklenici SVR tutanaklarının kopyalarını yayınlayacak ve dağıtacaktır. Sözleşme veren kurum, Paragraf 5.3'te belirtildiği gibi İncelemenin gerçekleştirildiğini resmi olarak kabul edecektir. Sayfa 126 / 168 Machine Translated by Google Ek I Sayfa 127 / 168 Machine Translated by Google Ek J Ek J - Üretime Hazırlık Gözden Geçirmesi (MRR) Ve Üretime Hazırlık İncelemesi (PRR) 100. Üretime Hazırlık Değerlendirmesi (MRR) ve Üretime Hazırlık Değerlendirmesi (PRR) 100.1 Genel A. Savunmaya özgü ve/veya savunma açısından kritik üretim ve üretim, silah sistemlerinin geliştirilmesinde hayati bir rol oynamaktadır. Değişen koşullar, savunma imalatını önemli ölçüde etkiledi. Bunlar: 1. Ulusal güvenliğe yönelik değişen tehditler Azalan savunma bütçeleri Savunma sanayinin 2. konsolidasyonu 4. Sanayinin 3. artan küreselleşmesi 5. Teknolojinin artan değişim hızı 6. Çevreye uyumlu üretim için gereksinimler B. Savunmaya özgü ve/veya savunma açısından kritik üretim yetenekleri, ya geniş çapta bir dizi silah sistemine uygulanabilir ya da belirli silah sistemlerine özgüdür, yani: 1. Kompozit işleme ve onarım 2. Elektronik süreçler 3. Bilgi teknolojisi sistemleri 4. Silah sistemi desteği 5. Tasarım, modelleme ve simülasyon 6. Üretim süreçleri C. Savunma imalat özellikleri birbiriyle etkileşim halindedir ve aşağıdakilerden oluşur: elementler: 1. Faaliyet tabanlı muhasebe ve bağımsız bir değişken olarak maliyet muhasebesi dahil olmak üzere üretim muhasebesi Yaşam 2. döngüsü tasarımı, entegre ürün ve süreç geliştirme, üç boyutlu dijital ürün modelleri, simülasyon ve modelleme ve hızlı prototip oluşturma dahil olmak üzere ürün tasarımı Üretim süreçleri üretken 3. sayısal kontrol, uyarlanabilir makine kontrolü, tahmine dayalı süreç kontrolü, yüksek hızlı makineyle işleme, esnek takımlama, yumuşak takımlama, aletsiz montaj, gömülü sensörler, flip çipler, nanoteknoloji ve biyoteknoloji dahil Çevreyle uyumlu üretim teknolojileri, temizleme sistemleri, 4. kaplamalar dahil ve malzeme seçimi, depolama ve elden çıkarma Kuruluşlar arasında ekip oluşturma, sanal girişimler, uzun vadeli tedarikçi ilişkileri, yüksek 5. performanslı kuruluşlar, çapraz işlevli ekipler, yalın işletmeler, uyarlanabilir işletmeler, çevik işletmeler ve bilgi tabanlı ve öğrenen işletmeler Elektronik ticaret, insanların sanal ortak yerleşimi, veri alışverişi standartları, internet teknolojileri, intranet teknolojileri, tarayıcı teknolojileri, akıllı ajanlar, kesintisiz veri ortamları, 6. telekomünikasyon ve uzaktan öğrenme dahil olmak üzere bilgi ve iletişim teknolojileri Sayfa 128 / 168 Machine Translated by Google Ek J 7. Gelişmiş üretim süreçleri ve uygulamalarının bakım, onarım ve yükseltme operasyonlarına uygulanması Yeni 8. ve mevcut sistemler için teknoloji ekleme Mekanik ve 9. elektronik sistemler için kendi kendine teşhis 10. Yeniden üretim için yeni teknolojiler 11. Silah sistemlerinin sürdürülmesi için tasarım ve üretim yöntemleri: A. Gelişmiş üretim süreçleri ve uygulamalarının bakım, onarım ve yükseltme işlemlerine uygulanması b. Yeni ve mevcut sistemler için teknoloji ekleme C. Mekanik ve elektronik sistemler için kendi kendine teşhis d. Yeniden üretim için yeni teknolojiler e. Sürdürmeyi iyileştiren tasarım yöntemleri f. Yaşam döngüsü maliyetlerini optimize etmek için tasarım değiş tokuşları için algoritmalar g. Kavramsal aşamada tasarım ödünleşimlerini kolaylaştıran parametrik modeller h. Çeşitli çözünürlük seviyelerinde simülasyona izin verecek ürün veritabanları 12. Ticari kullanıma hazır (COTS) ürünlerin yaygın uygulaması: A. Açık mimari ve teknoloji şeffaflığı için tasarlanmış yeni silah sistemleri b. Mevcut ve gelecekteki silah sistemlerine dahil edilebilecek yeni COTS teknolojilerinin farkındalığını sürdürmek, belgelemek ve planlamak ve ayrıca bu bilgileri bireysel program ofislerine yaymak için merkezi bir program ve mekanizmalar C. COTS ürünlerini sahadaki silah sistemlerine sokmak için geliştirilmiş yöntemler d. COTS parçalarının askeri amaçlar için yeterliliğini belirlemek için düşük maliyetli doğrulama yöntemleri uygulamalar 13. En geniş uygulama yelpazesine sahip savunmaya özgü ve savunma açısından kritik süreçler: A. Oran şeffaf üretimi mümkün kılan süreçler (yani, birim başına maliyetin üretim oranından bağımsız olduğu üretim) b. Kompozit yapıların düşük maliyetli üretimi için prosesler c. Düşük maliyetli kaplamaların ve yapıların düşük maliyetli üretimi ve uygulaması için süreçler gözlemlenebilirlik d. Savunmaya özgü elektronik teknolojileri e. Büyük, karmaşık parçaların üretiminde boyutsal kontrol sağlayan tasarım, bilgi ve üretim teknolojileri 100.2 Üretime Hazırlık İncelemesi (MRR) A. Ana yüklenici, alt yüklenici veya kritik bileşen tedarikçisinde bir birimin veya sözleşmeyle belirlenen diğer konfigürasyon öğelerinin imalatına başlamadan önce, ana yüklenici, benzersiz savunma ve/veya savunma özelliklerini bünyesinde barındıran kaliteli bir ürün oluşturmaya hazır olduğundan emin olmak için bir MRR yürütecektir. - incelenmekte olan programa uygun olarak, paragraf 100.1'de tanımlanan, arzu edilen bir savunma yüklenicisinin karakteristik özelliği olan kritik üretim yetenekleri. B. Uygun tasarım, imalat, test, parça, malzeme, proses, kalite ve diğer sorumlu kuruluşlardan temsilciler asgari olarak katılacaktır. Uygun hükümet temsilcileri davet edilecek ve katılmalarına izin verilecektir. Sayfa 129 / 168 Machine Translated by Google Ek J C. Kapsanan konular, PCO ve yüklenicinin program yöneticisi tarafından karşılıklı olarak mutabakata varılacak olan, paragraf 100.1'de belirtilen uygulanabilir öğeleri içerecektir ve bunlarla sınırlı olmamak üzere aşağıdakileri içerecektir: 1. Çizim mevcudiyeti ve kabul edilebilirlik 2. Konfigürasyon durumu 3. Parçaların ve malzemelerin üretilebilirliği 4. Üretim süreçlerinin ve sertifikaların yeterliliği Üretim planlaması 5. Mevcut üretim trendi verileri 6. Personel deneyimi ve eğitim ve 7. sertifikalar Takımlama 8. 9. Tesisler 10. Muayene noktaları 11. Test ekipmanı kullanılabilirliği ve kalibrasyon durumu 12. Düzeltici eylem durumu 13. Önceki benzer donanım yapılarından ve programından öğrenilen imalat dersleri D. İmalat ve Test Planlaması: Yüklenici, imalat döngüsünün tüm bölümleri için, akış şemalarını veya tümünü tanımlamaya yönelik diğer etkili alternatif yöntemleri içerecek olan imalat, inceleme ve test talimatları geliştirecektir. muayene ve test noktaları. Yüklenicinin kalite güvence kuruluşu planlamaya katılacak ve yayınlanmadan önce talimatları gözden geçirip onaylayacaktır. Talimatlar, ürünün teknik gereklilikleri karşıladığını doğrulamak için gerekli testlerin ve muayenelerin etkili bir şekilde yapılmasını sağlamak için çizimler, malzeme özellikleri, süreç özellikleri ve işçilik standartları gibi mühendislik gerekliliklerini içerecek veya bunlara atıfta bulunacaktır. Test talimatları, ölçülecek özellikleri, ölçüm yöntemlerini ve testin gerçekleştirileceği noktayı belirtmelidir. Üretim süreçlerinde, ekipmanda ve/ veya test ekipmanında/aletlerinde yapılan herhangi bir değişiklik belgelenecektir. Bu tür değişikliklerin sonuçları mümkün olan en kısa sürede değerlendirilecektir. Yüklenici, gerekli imalat, muayene ve test talimatlarını geliştirirken aşağıdakileri ele alacaktır: 1. Sürekliliği sağlamak için tüm imalat, muayene ve test noktalarının sıralaması ve tüm operasyonların etkinliği Daha 2. yüksek girinti seviyelerinde onarım veya yeniden çalışmayı en aza indirmek için optimum parça garanti seviyesinde muayene ve test performansı. Tüm işçilik, müteakip işlemlerle kapsanmadan önce en az bir ve tercihen iki kez denetlenecektir. Modül seviyesinde çevre testi ve yanma 3. yeterliliği Yabancı cisim kontrolünü içerecek temizlik ve kirlilik kontrolü 4. 5. Elektrostatik boşalmaya karşı hassas öğelerin korunmasına ilişkin hükümler de dahil olmak üzere, kurum içi taşıma ve paketlemenin yeterliliği Uygulanabilir 6. çizimlerin, spesifikasyonların ve standartların mevcudiyeti ve kullanımı Her muayene veya 7. test için kabul veya ret kriterlerinin net tanımı 8. Kapsamlı izleme ve kritik öğelerin ve özelliklerinin belgelenmesi Muayene ve montaj personeli için görsel yardımcılar 9. 10. Üretim sürecinde belirtilen ve kullanılan maddelerin, kimyasalların, mağaza yardımcı maddelerinin, giysilerin ve harcanabilir malzemelerin (temizlik malzemeleri, yapıştırıcılar, birleştirme malzemeleri, çözücüler, paçavralar vb.) uygun seçimi, uygulanması, kullanımı ve kontrolü Sayfa 130 / 168 Machine Translated by Google Ek J 11. Kullanılacak test ekipmanı, aletler, şablonlar, demirbaşlar ve diğer fabrikasyon ekipmanları 12. İmalat ve kalite için uygun zorunlu denetim noktalarının eklenmesi kuruluşlar 13. Üretime Hazırlık İncelemeleri (MRR'ler), Teste Hazırlık İncelemeleri (TRR'ler), ve birimler ve diğer yapılandırma öğeleri için Donanım Kabul İncelemeleri (HAR'lar) 14. Başlatma ve durdurma süreleri, sıcaklıklar, tork değerleri vb. gibi işlem verilerini kaydetme hükümleri. E. İşçilik: Yüklenici, işçiliğin yeterli olmasını sağlayacak yöntemler geliştirecektir. sözleşme son maddesinde belirtilen gereksinimleri karşılamak için. F. Standartlar: Yüklenici, işçilik standartlarını belirleyecektir. Bu standartlar, tasarım spesifikasyonlarının, çizimlerin, çalışma talimatlarının veya diğer hazır spesifikasyonların ve standartların bir parçası olabilir. Bu standartlar, endüstri tarafından kabul edilen işçilik standartlarından türetilecek ve ayrıca yüklenicinin imalat tecrübesine dayanacaktır. Tüm standartlar, sözleşmenin kısıtlamaları dahilinde müşteriye mümkün olan en yüksek kalitede ve en güvenilir donanımı sağlamayı amaçlayacaktır. Tüm standartlar, belirli ayrıntılı kabul veya ret kriterlerini tanımlayacaktır. G. Görsel Yardımcılar: İmalatı veya incelemeleri desteklemek için görsel yardımcılar kullanıldığında, yüklenici sürekli kullanılabilirliği ve uygun konfigürasyonu sağlamak için kabul edilebilir işçilik gösteren numuneleri, grafikleri veya görsel yardımcıları belirleyecek, sürdürecek ve kontrol edecektir. 100.3 Üretime Hazırlık İncelemesi (PRR) C. PRR, üretim risklerinin ve yüklenicinin bu riskleri yönetme metodolojisinin değerlendirilmesinde hükümete yardımcı olacak bir mekanizma sağlamak için yürütülecektir. B. Dört ana PRR değerlendirme unsuru şunlardır: 1. Üretim Yönetimi, örneğin, üretim organizasyonunun ne kadar iyi yapılandırıldığına ve yönetildiğine odaklanan "Organizasyonel Güvence" konusuna odaklanın. 2. yöntemlerin, süreçlerin ve test ekipmanının tanımlandığından ve üretim operasyonlarını desteklemek için mevcut olduğundan emin olmak için Üretim Operasyonları, örneğin, imalatın/üretimin nasıl planlanacağına ve yürütüleceğine odaklanan "Proses Güvencesi" konusuna odaklanın Ürün Güvencesi, örneğin, kalitenin nasıl 3. oluştuğunu ele alın ürüne ve ürün kalitesinin nasıl takip edileceğine ve doğrulanacağına göre tasarlandı 4. C. Üretime Hazır Olma Riski Hesaplamaları Metodolojisi: Geliştirmeden üretime geçiş sırasında riski yönetmek, büyük sistem satın alma programlarının yaşam döngüsünde kritik bir görevdir. PRR'ye yönelik özel hazırlık kılavuzu için, POC/Yüklenici ekibi, aşağıdaki kriterlere göre ana unsur etki değerlendirmesi ve puanlaması için risk hesaplama metodolojisini tanımlayan Üretime Hazırlık İnceleme Aracı Kullanıcı Kılavuzunu (AFSCR 84-2) kullanmayı seçebilir. : Sayfa 131 / 168 Machine Translated by Google Ek J Etki Değerlendirmesi Etki Puanı 0 Hiçbiri Önemsiz 1 Küçük 2 Ana 3 4 felaket 1. Risk puanı, olasılık değerlendirmesinin ve etkinin ürünüdür. Örneğin, belirli bir değerlendirme öğesi için olasılık değerlendirmesi %70 ise ve ilgili etki değerlendirmesi büyükse, hesaplanan risk puanı 0,70 * 3 = 2,1 olacaktır. Sonuç, PRR ekibi tarafından girilen eşik değerlerle karşılaştırılır. 2. Bireysel değerlendirme unsurları için genel bir risk değerlendirmesi hesaplanır. Bu tartışmalı bir yaklaşımdır; bazıları, bir alt öğe içindeki herhangi bir değerlendirme öğesinin yüksek riskli olması durumunda, tüm alt öğenin de yüksek riskli olarak derecelendirilmesi gerektiğini savundu. Bu argümanın karşıtı, kavramın kendisinin uç noktalara götürülebileceğidir. Örneğin, yüksek risk olarak derecelendirilen herhangi bir değerlendirme unsuru, alt unsurun yüksek risk olarak derecelendirilmesini gerektiriyorsa, o zaman ana unsur yüksek risk olarak derecelendirilmelidir, çünkü bir alt unsur yüksek risklidir ve nihayetinde PRR'nin tamamı derecelendirilmelidir. önemli bir unsur yüksek risk olduğu için yüksek risk. Tüm veriler gözden geçirilmek üzere mevcut olduğundan, özet ve özet amaçlar için risk değerlendirmesini özetlemek makul bir yaklaşım gibi görünmektedir, ancak her PRR POC ve/veya Yüklenici ekibi bu yaklaşımı kabul etmek isteyip istemediklerini düşünmelidir. D. Üretim İşleme ve İmalat 1. Sertifikasyon: Yüklenici, karmaşık, kritik operasyonlarda kullanılan makinelerin, ekipmanın ve prosedürlerin kalifikasyonunu sertifikalandırmak için bir yöntem oluşturacaktır. Yapılan yeterlik testlerinin ve bu testlerin sonuçlarının kayıtları muhafaza edilmelidir. Üretim öncesi doğrulama, belirli bir tasarım için üretilen ilk ürün üzerinde yapılan ölçümleri içerecektir. Makineler, teçhizat ve prosedürler, kalite eğilimlerinin sonuçlarının gerektirdiği şekilde veya önemli proses değişiklikleri yapıldığında (yani, malzeme kalınlığı, tasarım, güç kaynağı, kapasite, voltaj veya yoğunluk gibi öğeler) yeniden sertifikalandırılacaktır. 2. Temizlik, Kontaminasyon ve Korozyon Kontrolü: Yüklenici, donanım spesifikasyonlarından elde edilen temizlik, kontaminasyon ve korozyon kontrolü gereksinimlerini gözden geçirecek ve tanımlayacak ve donanımı üretim, test, depolama ve nakliye sırasında yeterince korumak için prosedürlerin geliştirilmesini sağlayacaktır. Kontrollerin uygulanması, kalite güvencesi tarafından düzenli olarak izlenecektir. Fiziksel Çevrenin Kontrolü: Yüklenici, periyodik denetim yoluyla 3. fiziksel ortamın (sıcaklık, nem, ışık, çalışma alanlarının düzenlenmesi veya makine ve teçhizatın düzenlenmesi gibi) donanımın kazara hasar görmesini önlemek ve tüm çalışma ve depolama alanlarında güvenli olmayan koşulları önlemek için kontrol edilir. Kritik Öğe Kalite Kontrol Gereksinimleri: Yüklenici, uygun kritik öğe kontrolünü oluşturacak ve sürdürecektir. İmalat, uygun 4. planlama atölye dosyalarındaki, süreç planlarındaki, kayıt defterlerindeki ve şirket içi imalat için geçerli olan imalatı ve hareketi kontrol eden ilgili belgelerdeki özel talimatları içerecektir. Tercihli muamele için seçilen bileşenler veya malzemeler, özel gereksinimler konusunda personeli uyarmak için göze çarpacak şekilde işaretlenecek veya etiketlenecektir. Bu kalemler, tüm stok odalarında ve tutma ve depolama alanlarında ayrılmış olacak veya belirgin bir şekilde işaretlenmiş demirbaşlara ve yerlere sahip olacaktır. Bu tür kalemler, süresi dolmuş zaman, döngü veya takvim ömrünün durumu için düzenli ve sistematik olarak denetlenecektir. Süresi, döngüsü veya takvim ömrü dolmuş kalemler şu şekilde tanımlanmalıdır: Sayfa 132 / 168 Machine Translated by Google Ek J uygun olmayan ve uygun şekilde düzenlenmiş. Seçilen kritik bileşenlerin incelemeleri, kullanılan çalışma talimatlarının ve standartların yeterliliğini doğrulamak için periyodik olarak yapılmalıdır. Kritik 5. Öğe Doğrulaması: Her kritik öğe için, montajın başlangıcından başlayarak ve ilerleyen montaj ve test seviyelerinde, yüklenicinin kalite organizasyonu doğrulayacaktır. tedarik edilen veya üretilen tüm bu tür eşya ve malzemeler için sözleşme, çizim ve şartname gerekliliklerinin karşılandığını. Eğilimler, beklenen normlardan sapmalar ve marjinal koşullar dahil olmak üzere anormallikler belirlenecektir. Bu kalemlerin kalitesinin ve imalatlarının ayrıntılı değerlendirmesi şunları içerecektir: A. Gizli kusurlara neden olabilecek olası tasarım ve yerleşim sorunlarının belirlenmesi veya marjinal performans B. Mevcut üretim test yöntemlerinin ve kontrollerinin tekrarlanabilir ürünler ürettiğinin doğrulanması c. Varsa, mühendislik bilgilerinin ek (veya revizyonu) ile hafifletilebilecek üretim sorunlarının gözden geçirilmesi D. Kritik parametrelerin ölçüldüğünün ve geçerli testle doğrulandığının doğrulanması prosedürler e. Kararlar, düzenlemeler, düzeltici faaliyetler veya tavsiyeler, uygun kriterler ve önceki geçmiş verileri F. Gözden geçirme sırasında not edilen veya gözlemlenen anormallikler analiz edilir, değerlendirilir ve düzenlenir g. Kayıtlar aşamalı olarak gözden geçirilir ve genel “Kabul Kriterleri”nin bir parçası haline getirilir h. As-built ve design arasındaki farkların belirlenmesi ve çözümlenmesi belgeler Ben. Altta yatan nedenleri (belirtiler veya tezahürler) belirlemek için arıza ve tutarsızlık raporlarının gözden geçirilmesi ve aşırı gerilim ve neden olunan ikincil arızaların bir özeti 6. Elektrostatik Deşarj Kontrol (ESD) Programı: Elektrostatik deşarj kontrol programı uygulamasının gözetimi için prosedürler oluşturulacaktır. Bu, elektrostatik boşalmaya duyarlı öğelerin tanımlanmasını ve bu tür bir hasarı önleyecek koruyucu özellikleri içerecektir. Bu asgari olarak şunları içermelidir: a. Tasarım kriterleri b. Korunan çalışma alanları ve koruyucu giysiler c. Proses kontrolleri ve işçilik standartları d. Elleçleme, paketleme, nakliye ve depolama e. eğitim f. Belgelerin ve donanımın işaretlenmesi g. Sertifikalı ESD iş istasyonları için denetim planı 7. Tahribatsız Değerlendirme: Kantitatif ölçümler, bütünlük analizi ve tahribatsız muayene yapmak için kullanılan tahribatsız değerlendirme yöntemleri ve doğrulama teknikleri (ve ilgili ekipman ve tesisler) kontrol edilecek ve yüklenicinin kalifikasyonuna, kalibrasyonuna, sertifikasyonuna ve standartlarına entegre edilecektir. prosedürler. Donanım uçuş konfigürasyonları için tahribatsız değerlendirmeler, ilgili bilimsel alanda yetkin ve sertifikalı personel tarafından yapılacaktır. 8. Tamamlanmış Kalem Muayenesi ve Testi: Bir sözleşme nihai kaleminin nakliyesi veya depolanmasından önce, yüklenici, tüm iş dizilerinin tatmin edici bir şekilde tamamlandığından ve tüm Sayfa 133 / 168 Machine Translated by Google Ek J uygunsuzluk sorunları giderilmiştir. Yüklenici, nihai gözden geçirmenin kayıtlarını ve bulgularını muhafaza edecektir. 9. İstatistiksel Süreç Kontrolü: Yüklenicinin kalite güvence kuruluşu, süreç değişkenliğini kontrol etmek için kullanılan tekniklerin geliştirilmesine katılacaktır. Bu, kalifiye personel tarafından tasarım ifşası teknik dokümantasyonu ve üretim süreçlerinin bağımsız değerlendirmelerinden oluşmalıdır. Asgari olarak şunları göz önünde bulundurun: a. Kritik kalite özellikleri tanımlanır, ölçülür ve doğrulanır b. Veriler ölçüm noktalarından toplanır c. Kontrol limitleri ve tolerans varyasyonları, ürün spesifikasyon limitleri içinde tutulur d. Önleyici ve düzeltici faaliyetler için prosedür ve yöntemler oluşturulmuş, Tasarım ve üretime geri bildirim sağlanır Sayfa 134 / 168 Machine Translated by Google Ek J Sayfa 135 / 168 Machine Translated by Google Ek K Ek K - MIL-STD-1521'i Uyarlamak için Uygulama Kılavuzu 110. MIL-STD-1521 Terziliği için Uygulama Kılavuzu 110.1 Kapsam C. Bu ek, kılavuzluk sağlar ve bu standardın edinim sürecinde sözleşmeye bağlı olarak başvurulması durumunda, bu standardın gerekliliklerinin maliyet etkin bir şekilde uygulanması için kullanılacaktır. Bu ek, sözleşme gerekliliklerinin hazırlanmasından sorumlu olan faaliyet için rehberlik görevi görür ve sözleşmenin bir parçasını oluşturmaz. Not: MIL-STD-1521'e ilişkin Ek K'deki tüm referanslar, bu MIL STD-1521B, TOR-2007(8583)-6414_Cilt 1 güncellemesi anlamına gelir. 110.2 Amaç A. Burada yer alan yönergeler, tüm Savunma Bakanlığı bileşenlerinin seçici bir şekilde uygulanmasını ve askeri özellikleri ve standartları sözleşmeye dayalı dayatmalarından önce uyarlamasını gerektiren Savunma Bakanlığı Direktifi 4120.21, Şartname ve Standartlar Uygulamasını uygular ve: 110.3 1. Uygulanamaz ve gereksiz gereksinimleri ortadan kaldırın 2. dahil edilmeyen gerekli teknik inceleme ve denetim faktörlerinin eklenmesini/değiştirilmesini sağlayın. MIL-STD-1521 3. Fazlalığı ve diğer sözleşme şartnameleri ve standartlarıyla tutarsızlığı ortadan kaldırın Amaç A. Bu kılavuzun amacı, MIL-STD 1521'in uyarlanmasına ilişkin uygulamaları ve sınırlamaları belirlemektir. MILSTD-1521, bağımsız bir belge değildir. Sözleşme gerekliliklerinde (örn. SOW, vb.) belirtilen çalışma çabasına bağlıdır. Şartnamelerin uyarlanması, askeri tedarikin tüm aşamalarında yer alacaktır, ancak özellikle talep paketi hazırlama ve sözleşme müzakerelerinin ilk aşamaları için geçerlidir. Tedarik kapsamındaki son kalem(ler)in türüne bağlı olarak, MIL-STD-1521'de belirtilen incelemeler ve denetimler tüm programlar için gerekli olabilir veya olmayabilir. 110.4 Uyarlamayla İlgili Hususlar 110.4.1 Çalışma Bildirimi ile İlişki A. Program Yöneticisi, teknik incelemelerin, zamanında ve etkin ilgiyi sağlamak için, yüklenicinin İş Bildirimi ve sözleşme hükümleri kapsamında gerekli olan çalışma çabasını uygulamasına ilişkin görünürlük sağladığını akılda tutmalıdır. sözleşme gereksinimlerinin teknik yorumuna. B. MIL-STD-1521'i uyarlamanın anahtarı, MIL-STD-1521 gerekliliklerini geçerli SOW ve sözleşmeden doğan görev gerekliliklerinin ayrıntılarıyla eşleştirmektir. MIL-STD-1521'in incelenmekte olan sözleşme için geçerli olmayan teknik inceleme faktörleri içerebileceği hemen anlaşılacaktır. (Örneğin, bir sözleşme bilgisayar yazılımını içermiyorsa, MIL-STD-1521'deki bilgisayar yazılımı malzemelerinin gözden geçirilmesine yapılan tüm atıflar geçerli olmayacaktır). C. MIL-STD-1521 kullanıldığında, SOW'da geçerli gereksinimleri içeren bir görev belirtilecektir. MIL-STD-1521'de belirtilmeyen ancak belirli bir programın doğası gereği gerekli görülen inceleme faktörleri İş Bildirimi'ne eklenecektir. Dikkatli bir değerlendirme sürecine tabi olan teknik inceleme ve denetim gereklilikleri, sözleşmenin ifası sırasında sürekli müzakere edilecek çok amaçlı bir belge yerine programa özel hale gelecektir. Sayfa 136 / 168 Machine Translated by Google Ek K 110.4.2 Fazlalığın ve Belirsizliğin Ortadan Kaldırılması A. MILSTD-1521, teknik incelemeler ve denetimler için geniş program belgesi olmakla birlikte, mevcut diğer standartlar da teknik incelemeler veya denetimler gerektirir. Örneğin, güvenilirlik, sürdürülebilirlik, sistem mühendisliği vb. için MIL-STD'ler gözden geçirme ve/veya denetim gerektirebilir. Tasarımın bu yönlerinin gözden geçirilmesi de MILSTD-1521 kapsamında gerekli olacaktır; bu nedenle, bu tür standartlar MIL-STD-1521 ile birlikte sözleşmeye bağlı olarak şart koşulmuşsa, SOW, bu diğer standartların teknik inceleme gerekliliklerinin MIL-STD-1521'deki teknik incelemeler veya denetimlerle nasıl birleştirilip birleştirilemeyeceğini gösteren bir hüküm içerecektir. B. İncelemelerin birleştirilmesi, incelemeler ve denetimler için gereksinimler içeren diğer MIL-STD'leri, "Planları" vb. geçersiz kılmaz. Sözleşme, sözleşmeye uygunluğun arzulanan görünürlüğünü ve güvencesini sağlayacak asgari entegre, kapsamlı teknik tasarım inceleme çabasını gerektirecektir. 110.4.3 Terzilik İşlemlerine Yüklenicinin Katılımı A. Belirli bir inceleme veya denetim gerektiğinde, gözden geçirilecek konuların program gereklilikleriyle uyumlu hale getirilmesi önemlidir. Bu nedenle teklif sahibine değişiklikleri önerme ve uygun gördüğü konuları veya öğeleri belirleme fırsatı verilecektir. B. Program ofisi, teklif hazırlama talimatlarında, teklif sahibinin MIL-STD-1521 konularını veya öğelerini ve bunlarla ilgili detayların SOW tarafından gerekli görülen çeşitli inceleme veya denetimlerde ele alınmasını tavsiye etmesini isteyecektir. Bu, teklifi verenin konuları veya öğeleri ve ayrıntıları eklemeler ve çıkarmalar yoluyla belirli inceleme veya denetim için uyarlamasına olanak tanır. C. Ek olarak, etkili terziliğin birkaç gözden geçirme noktası gerektirdiği kabul edilmelidir. Bununla birlikte, inceleme veya denetim gerekliliği, sözleşmenin imzalanmasından önce sonuçlandırılmalıdır. 110.4.4 Karmaşıklık A. Sistem, alt sistem, konfigürasyon öğesi karmaşıklığı ve program türü, bu tür gözden geçirmelerin hem ihtiyacının hem de sayısının belirlenmesinde merkezi öneme sahiptir. Karmaşık olmayan küçük bir sistem geliştirirken, bazı incelemeler gerekli olmayabilir veya gerekirse kapsam sınırlı olabilir. Ya daha önce tartışılan uyarlama prosedürleri, MIL-STD-1521'in hariç tutulmasıyla ya da sınırlı kapsamlı bir teknik inceleme çabasını yansıtan uyarlanmış bir MIL STD-1521 ile sonuçlanmalıdır. Tersine, çok karmaşık bir geliştirmede, gözden geçirme süreci, incelemelerin seviyeleri ve sayıları artacaktır. B. Yukarıdakilere ek olarak, uygulama derecesi, yapılandırma öğesinin geliştirme durumuna (örneğin, yeni tasarım veya ticari olarak temin edilebilir) veya varsa herhangi bir değişikliğin derecesine bağlıdır. Örneğin: yeni geliştirilen bir öğe, gözden geçirme konularının veya öğelerinin ve denetimlerin çoğunu gerektirebilirken, piyasada bulunan uygun belgelere sahip bir yapılandırma öğesi, yani doğrulanmış test sonuçları, spesifikasyonlar, çizimler, vb. sınırlı incelemeler veya denetimler gerektirebilir. programa ve arayüzlerine uygulanmasına. C. Değiştirilen tasarımlar söz konusu olduğunda, değişikliklerin derecesi ve etkisi dikkate alınmalıdır. İncelemeler ve denetimler, değişiklikler ve bunların arayüzleri ile sınırlı olabilir. 110.5 Teknik Gözden Geçirme ve Denetimlerin Planlanması A. Teknik Gözden Geçirme ve Denetimler için program son derece önemlidir. Çok erken yürütülürlerse, incelenecek öğe yeterince tanımlanmayacaktır. Tersine, gözden geçirme çok geç olursa, program taahhütleri hatalı bir şekilde verilmiş olabilir ve düzeltme hem zor hem de maliyetli olacaktır. B. Planlama amacıyla, teknik gözden geçirmeleri planlamak için iyi bir yöntem, bunları dokümantasyon gereksinimleriyle ilişkilendirmektir. Örneğin, PDR'nin özü, yüklenicinin bu belgelerin gerekliliklerini karşılama yaklaşımını değerlendirmek olduğundan, donanım Geliştirme Spesifikasyonu veya yazılım mimarisi ve ayrıntılı tasarım ve Yazılım Test Planı hazır olduktan sonra bir PDR planlayın. C. Tetkiklerin planlanması, yalnızca belgelerin mevcudiyetine değil, aynı zamanda donanım/yazılım mevcudiyetine ve kabul yeterlilik testlerinin tamamlanmasına da bağlıdır. Tablo 3 Sayfa 137 / 168 Machine Translated by Google Ek K her gözden geçirme veya denetimle ilişkili birincil belgelerin bir listesini ve tahmini zaman aşamasını içerir. Tablo 3. Gözden Geçirme ve Denetimlerin Planlanması Zaman Aşaması Gözden geçirmek Birincil Belgeler • Sistem Gereksinim Spesifikasyonu • Ön Genellikle Konsept Keşif Aşamasında gerçekleştirilir. SRR Operasyon Konsept Dokümanı • Sistem Mühendisliği Yönetim Planı • Sistem/Segment Spesifikasyonu Ancak, Konsept Araştırma Aşaması tamamlanmadığında diğer aşamalarda kullanılabilir. • Yazılım Geliştirme Planı • Analiz ve Ticari Çalışma Raporları • Sistem/Segment belirtimi • Ön Operasyon Konsept Belgesi (OpsCon) • Ön Yazılım Gereksinimleri SFR genellikle gösteri ve Doğrulama Aşaması Spesifikasyonu • Ön Yazılım Arayüzü Gereksinimleri Spesifikasyonu • Analizler, ticaret çalışmaları • Çizimler Seviye I DoDD1000B • MIL-DTL-31000C'ye göre TDP tipi ve elemanı • Yazılım Gereksinimleri Spesifikasyonları • Yazılım Mimari Tanımı • Harici Yazılım Arayüzü Gereksinimleri Spesifikasyonları • Dahili Yazılım Arayüzü Gereksinimleri Spesifikasyonları • Yazılımdan Donanıma Arayüz Gereksinimleri Spesifikasyonları • Mühendislik Analizleri • Ticaret Çalışmaları SAR Genellikle Tam Ölçekte erken Gelişim • Teknik Performans Metrikleri • Yazılım Geliştirme Planı • Yazılım Ana Yapı Planı • Yazılım Test Planı • Operasyonel Konsept Belgesi (OpsCon) • İlk Yazılım Kaynakları Veri Raporu (SRDR) • Yaşam Döngüsü Maliyeti (LCC) Analizi • Bağımsız Değişken Olarak Maliyet (CAIV) Çalışmaları Gözden geçirmek Zaman Aşaması Birincil Belgeler Sayfa 138 / 168 Machine Translated by Google Ek K • Geliştirme Spesifikasyonu • B Tipi Performans Spesifikasyonu • Çizimler Seviye I DoDD1000B • MIL-DTL-31000C'ye göre PDR Genellikle Gösteride gerçekleştirilir ve Doğrulama ve/veya Tam Ölçek Geliştirme Aşaması TDP tipi ve elemanı • Yazılım Üst Düzey Tasarım Belgesi • Yazılım Test Planı • Ön Bilgisayar Kaynakları Entegre Destek Belgesi • Ön Bilgisayar Sistemi Kullanım Kılavuzu • Ön Yazılım Kullanıcı El Kitabı • Ön Bilgisayar Sistemi Tanılama Kılavuzu • Taslak Ürün Spesifikasyonu • Tip C Spesifikasyonu ve başvurulan belgeler • Çizimler Seviye I veya II DoDD1000B • MIL-DTL-31000C'ye göre TDP tipi ve elemanı • Yazılım Ayrıntılı Tasarım Belgesi • Donanım CDR Genellikle Tam Ölçekte gerçekleştirilir Geliştirme aşaması Arayüzü Tasarım Belgesi • Yazılım Test Açıklaması • Bilgisayar Kaynakları Entegre Destek Belgesi • Yazılım Programcı Kılavuzu • Üretici Yazılımı Destek Kılavuzu • Test Açıklamaları/Prosedürleri • Yazılım Geliştirme Belgeleri • Veri Tabanı Tasarım Belgeleri • Yazılım Test Prosedürleri TR Genellikle Tam Ölçekte gerçekleştirilir • Resmi Olmayan Yazılım Geliştirme Testi Sonuçları Geliştirme aşaması • Resmi Olmayan Donanım Geliştirme Testi Sonuçları • Test Planları • Test açıklamaları • FCA Genellikle Tam Ölçeğin sonunda gerçekleştirilir Gelişim Test prosedürleri • Yazılım test raporları • Bilgisayar Sistemi Operatör Kılavuzu • Yazılım Kullanıcı Kılavuzu • Bilgisayar Sistemi Teşhis Kılavuzu Sayfa 139 / 168 Machine Translated by Google Ek K Zaman Aşaması Gözden geçirmek Birincil Belgeler • Son Bölüm II Spesifikasyonu Genellikle, geliştirici yüklenicinin üretim yüklenicisi olarak önceden seçildiği ilk üretimin başlarında PCA gerçekleştirilir. • C Tipi Ürün Spesifikasyonları • Tam Ölçekli Geliştirme sonunda, geliştirme Başvurulan Yazılım Ürün Spesifikasyonu Belgeleri ve Çizimler • DoDD1000B'ye göre yüklenicisi Üretim yüklenicisi TDP Tipi ve Elemanı • Yazılım Ürün Spesifikasyonu Seviye II veya III Çizimler • MIL-DTL-31000C'ye göre olarak önceden seçilmediğinde gerçekleştirilebilir. PCA, müteakip her yüklenici veya üretim kesintisi ile tekrarlanır. • Sürüm Açıklama Belgesi * DoDD-1000B, halefi olan MIL DTL-31000 belgesine aktarılmadıkları için Ek K'de terzilikte dikkate alınması önerilen üç çizim seviyesini tanımlar. 110.6 Mühendislik Veri İncelemeleri için Uyarlama Kılavuzu A. Mühendislik Verileri incelemeleri, MIL-STD 1521'deki resmi tasarım incelemelerinin/denetimlerinin bir parçası olarak gerçekleştirilir. Bu incelemelere ve denetimlere hazırlanmak ve bunları yürütmek için Mühendislik Verilerini İnceleme Kontrol Listesini kullanın. Mühendislik Verileri Tutarsızlık Sayfasındaki tutarsızlıkları not edin (Şekil 6). Gözden geçirmeler ve denetimler art arda daha ayrıntılı olduğundan, program ilerledikçe kontrol listesindeki daha fazla öğe geçerli olacaktır. Tüm gözden geçirmeler ve denetimler tamamlandığında, özel kontrol listesindeki tüm maddeler tamamlanmış olacaktır. Mühendislik Verileri İçin Kontrol Listesini İnceleyin BEN. Bir mühendislik verileri incelemesi yapılmadan önce aşağıdaki sorular ve değerlendirmeler kullanılmalıdır. Bunlar önerilen yönergelerdir ve bu şekilde kullanılmalıdır Ön brifing hazırlığı: 1. Şu soruları II. yanıtlayın: a. İncelemenin amacı nedir? B. Sözleşme neyi gerektiriyor? C. Çizimler nasıl kullanılacak? 2. Brifingler düzenleyin: a. Yüklenici, ekibe sözleşme gereklilikleri ve durumu hakkında bilgi verecektir b. Mühendislik Veri Yönetimi Görevlisi (EDMO) veya Başkan, ekibe inceleme prosedürleri hakkında bilgi vermelidir. C. Düzeltici eylem prosedürlerini tartışın Sayfa 140 / 168 Machine Translated by Google Ek K III. Veri İncelemesi: 1. Paketi oluşturun: a. Üst montaj çizimlerinin örneğini seçin b. Üst montaj veya ana alt montaj çizimlerinin Parça Listesine bakın c. Diğer alt montaj çizimleri üst parça listesinde listeleniyor mu? D. Üst parça listesinde listelenen tüm çizimler mevcut mu? e. Alt montaj parça listesinde listelenen tüm çizimler mevcut mu? F. Üretim planlama belgeleri mevcut mu? 2. Aşağıdakiler için mühendislik verilerini inceleyin: A. Çizim okunaklı mı ve çoğaltmaya uygun mu? B. Süreçler/özellikler listeleniyor mu? C. Tüm çizimlerdeki notlara bakın. Tüm notlar anlaşılır mı? Notlar açık mı ve Özlü? D. Tuhaf semboller, kısaltmalar vb. açıklanıyor mu? e. Tüm boyutlar ve toleranslar gösteriliyor mu? F. Malzeme tanımlanmış mı? G. Herhangi bir rapora atıfta bulunuluyor mu? Eğer öyleyse, pakette sağlanıyorlar mı? H. Resmi olmayan spesifikasyonların kopyaları paketin bir parçası olarak sağlanıyor mu? Ben. Sınırlı hak açıklamalarının kullanımı, Savunma Edinme Yönetmeliği (DAR) ve Federal Edinme Yönetmeliği (FAR) uyarınca doğru mu? J. Kontrol çizimleri (özellikle Kaynak ve Spesifikasyon Kontrolü) uygun şekilde kullanılıyor mu? ve DoD-STD-100'e göre işaretlendi mi? k. Sertlik açısından kritik öğeler ve sertlik açısından kritik işlem işaretleri doğru mu? l. Elektrostatik deşarja duyarlı (ESDS) sembolojisi ve uyarıları şu şekilde dahil ediliyor mu? uygun? M. Sözleşmede gerektiği gibi değişiklikler yapıldı mı? N. İndeks ve veri listeleri mevcut ve doğru mu? Ö. Her bir mühendislik verisi parçası için bir dağıtım bildirimi var mı? P. Spesifik işaretleme gereklilikleri (MIL-STD-130) tanımlanmış mı? Q. Kabul testi gereklilikleri, rekabetçi yeniden satın alma ile ayrı ayrı korunabilecek kalemler için tüm alt montaj/detay çizimlerine dahil ediliyor mu? R. Çizim seviyesi için uygun mühendislik tasarım bilgisi dahil edilmiş mi? sözleşmede belirtilmiş mi? S. Çizimler yerine askeri bir standart veya şartname kullanılabilir mi? T. Uygulanabilir güvenlik sınıflandırmaları doğru şekilde işaretlenmiş mi? sen Sözleşme gereklilikleri yeterli mi? v. Çizim paketi, amaçlanan son kullanımı desteklemek için yeterli görünüyor mu? (örneğin, lojistik destek, rekabetçi yeniden satın alma, vb.)? 3. Tüm eksiklikleri/tutarsızlıkları Mühendislik Verileri Tutarsızlık Tablosuna (bkz. Şekil 6) sorunu tam olarak tanımlamaya ve uyum için gereken eylemi yeterli ayrıntıda kaydedin Sayfa 141 / 168 Machine Translated by Google Ek K B. Gözden geçirmeler ve denetimler için zaman çerçevesi yukarıda önerilmiş olsa da, söz konusu programa bağlı olarak değişiklik gösterebilir. Her gözden geçirme veya denetim için program, teklif sahibinden teklifinin bir parçası olarak veya sistem mühendisliği yönetim planının (teklifin bir parçası olabilir) bir parçası olarak istenebilir. İncelemenin sonunda, EDMO (veya İnceleme Ekip Şefi) tüm tutarsızlık belgelerini toplar, imzalar ve uygun düzenlemeyi belirler. Tutarsızlıkların çözümlenmesinden sonra, sayfalar Mühendislik Veri Dosyalarında dosyalanacaktır. Sayfa 142 / 168 Machine Translated by Google Ek K Çarşaf ile ilgili (Program adı) MÜHENDİSLİK VERİLERİ TUTARSIZLIK SAYFASI (İnceleme Kontrol Listesi ile kullanılacak) Ana ve Alt Yüklenici/Satıcı Adı: İnceleme Türü: İnceleyenin Adı Çizim/Belge Numarası Rev. tutarsızlıklar Eylem Gerekli/Uygunluk Bitiş tarihi: Program Ofisi EDMO (veya Takım Şefi) İmza: ___________________________________ Hava Lojistik EDMO İmzası: ____________________________________ Eylem Ajansı: Müteahhit Program Ofisi Diğer Sözleşme İdare Ofisi Bu blok Action Agency tarafından kullanılacak. Düzelten tutarsızlıklar: __________________________________ __ __________ İmza Şekil 6. Mühendislik Verileri Tutarsızlık Tablosu Çözümlemeden sonra, Mühendislik Verileri Tutarsızlık Sayfasını Program Ofisi EDMO'ya iade edin. Sayfa 143 / 168 Tarih Tarih Machine Translated by Google Sözlük Bölüm I – Tanımlar Alternatiflerin Analizi (AoA) AoA, bir görev kabiliyetini karşılamak için alternatif sistem konseptlerinin operasyonel etkinliğinin, operasyonel uygunluğunun ve tahmini maliyetlerin ve risklerin değerlendirilme sürecidir. Analiz, her bir alternatifin temel varsayımlar veya değişkenlerdeki olası değişikliklere duyarlılığı dahil olmak üzere, yetenekleri tatmin ettiği düşünülen alternatiflerin avantajlarını ve dezavantajlarını değerlendirir. Mimari Mimarlık, bileşenlerin bir yapısı, bunların ilişkileri ve tasarımlarını ve zaman içindeki gelişimini yöneten ilke ve yönergelerdir; veya Mimari, bir dizi gereksinim veya bir sistem konsepti veya her ikisi için öğeleri ve bunların ilişkilerini gösteren bir yapı veya organizasyondur; veya Mimari, bir sistemin açıklık veya birlikte çalışabilirlik gibi üst düzey bir özelliği veya niteliği veya yukarıda bahsedilenleri içeren bir standarttır. Mimari Görünümler Mimari görünümler, mimari ürünlerin biçim ve içeriğinin standartlaştırılmasıdır. Savunma Bakanlığı (DoD) Mimari Çerçevesi (DoDAF) tarafından tanımlanan mimari görünümler şunlardır: A. Tümü (KAPALI) B. Operasyonel (OV) C. Sistemler (SV) D. Teknik (TV) Operasyonel konsept (OPCON) OV'yi yönlendirir. OV sırayla, SV'yi eksiklikleri ve sistem gereksinimlerini belirlemeye yönlendirir ve SV gereksinimleri, TV'yi uygulanabilir standartların ortak bir setini ele almaya yönlendirir; AV, OV, SV'nin üçüyle ilgili bir mimarinin kapsayıcı yönlerini sağlar. , ve televizyon. Mimari açıklama, çeşitli görüşler arasında açık bağlantılar sağlar: yani, "birlikte çalışabilirlik", çeşitli görüşler arasında bu ilişkileri geliştirmenin önemini gösteren tipik bir mimari odak noktasıdır. Alternatif Sistem İncelemesi (ASR) ASR, sonuçta ortaya çıkan gereksinim setinin müşterilerin ihtiyaç ve beklentileriyle uyuşmasını ve incelenmekte olan sistemin Teknoloji Geliştirme aşamasına geçebilmesini sağlamak için yürütülür. ASR, Konsept İyileştirme aşamasında değerlendirilen alternatif sistemleri değerlendirir ve Teknoloji Geliştirme planının tercih edilen sistem çözümüyle tutarlı olmasını ve Sistem Geliştirme ve Gösterim giriş riskini kabul edilebilir bir düzeye indirmek için yeterli kaynaklara sahip olmasını sağlar. ASR, tercih edilen sistem alternatifinin uygun maliyetli, karşılanabilir, operasyonel olarak etkin ve uygun olması ve bir ihtiyaca kabul edilebilir bir risk düzeyinde zamanında çözüm sağlayacak şekilde geliştirilebilmesi. Sorunun çözümlenmesi ve süreç ve sonuçlar üzerinde yönetici seviyesinde uygun mutabakat için zaman sağlamak üzere A Dönüm Noktasından çok önce yapılır. Denetimler ve İncelemeler Denetimler ve gözden geçirmeler, genellikle PDR'den sonra herhangi bir zamanda, bağımsız olarak veya diğer incelemelerin bir parçası olarak, bir konfigürasyon öğesinin/öğelerinin geliştirilmesinin PDR'nin Biçim, Uygunluk, İşlevsel (FFF) ve performans hedeflerini karşıladığını doğrulamak için yürütülen planlanmış olaylardır. programı. Bu denetimler ve gözden geçirmeler aşağıdakileri kapsayabilir ancak bunlarla sınırlı değildir: İşlevsel Yapılandırma Denetimi (FCA) A. Fiziksel Yapılandırma Denetimi (PCA) B. Sistem Doğrulama İncelemesi (SVR) Sayfa 144 / 168 Machine Translated by Google Sözlük C. Gemi Hazırlık İncelemeleri, yani Sevkiyat Onayı (CTS) D. Görev, Uçuş ve/veya Fırlatmaya Hazırlık İncelemeleri (M/F/LRR) Temel (B/L veya BL) Temel, daha sonra daha fazla geliştirme için temel teşkil eden, resmi olarak gözden geçirilmiş ve üzerinde anlaşmaya varılmış bir spesifikasyon veya üründür. Temel değerler, yalnızca sözleşme yapan kurumun incelemesini ve onayını gerektiren resmi değişiklik kontrol prosedürleri aracılığıyla değiştirilebilir. Başlangıçta belgelenen ve doğrulanan sistem düzeyinde gereksinimler ve kısıtlamalar, bunların tahsisi veya bir sonraki düzeye atanması ve bunlarla ilgili tüm değişiklikler, SOW sözleşmesine uygun olarak onaylanır. Tipik olarak, temel gereksinimler başlangıçta Sistem İşlevsel İncelemesinde (SFR) veya benzer bir olayda onaylanır. Spesifik olarak, örneğin, teknik taban çizgileri: A. işlevsel: (1) Fonksiyonel Temel (FBL), fiziksel ve performans sistem seviyesi gereksinimleri ve ilgili tasarım kısıtlamaları ile birlikte doğrulanır ve onaylanır (2) Tahsis edilen: (3) Tahsis Edilen Referans Çizgisi (ABL), onaylanmış bir tahsis edilen sistemin fiziksel hiyerarşisidir. yapılandırma (4) Hiyerarşideki her bir sistem ürünü için başlangıçta belgelenen, doğrulanan ve onaylanan tasarımdan işlevselliğe ve performans gereklilikleri ve tasarım kısıtlamaları ve bunlarda sözleşmeye uygun olarak onaylanan tüm değişiklikler (5) Her bir bileşen veya bilgisayar yazılımı öğesi ve bileşenlerin ve/veya bilgisayar yazılımı öğelerinin her bir ayrı entegre grubu için tüm tasarım gerekliliklerini ve kısıtlamalarını tanımlayan ayrılabilir belgeler veya B. Ürün (Son Öğe/Yapılandırma) örneğin: (1) Üretilecek her bir fiziksel eleman için yapım gereklilikleri (2) Ayrı ayrı tasarlanmış veya test edilmiş her bir yazılım öğesi için yazılım kodu (3) Tedarik edilecek her fiziksel öğe, parça veya malzeme için satın alma gereklilikleri (4) Tasarım yayın temel çizgisine yönelik başlangıçta belgelenmiş ve onaylanmış güncelleme, bir veya Aşağıdakilerin doğrulanmasından sonra daha fazla son öğe (EI): a) EI tasarımı, mevcut tahsis edilen ve tasarım yayın temel çizgilerindeki tüm performans ve işlevsel gereklilikleri ve kısıtlamaları karşılar b) As-built, as-coded veya as-entegrated ürün, temel çizgiyi doğru bir şekilde yansıtır c) Donanım ve yazılım, sürekli üretime hazır olma durumu, kabul doğrulaması, konuşlandırma, eğitim, operasyonlar, destek ve elden çıkarma ve müteakip tüm değişiklikler Bütçe maliyeti Bütçe ve Maliyet terminolojisi kılavuzu DoD 5000.4M'de bulunabilir. Kritik Tasarım İncelemesi (CDR) CDR, inceleme altındaki yapılandırma öğesinin veya sistemin ayrıntılı tasarımının fabrikasyona, sistem entegrasyonuna, gösterime ve teste devam edebilmesini sağlamak amacıyla ayrıntılı tasarım esasen tamamlandığında her bir yapılandırma öğesi için yürütülen çok disiplinli bir teknik incelemedir. ve konfigürasyon öğesi (CI) geliştirme spesifikasyonlarının belirtilen performans ve mühendislik uzmanlığı gereksinimlerini maliyet (program bütçesi), program (program çizelgesi), risk ve diğer sistem kısıtlamaları dahilinde karşılayabilir: Sayfa 145 / 168 Machine Translated by Google Sözlük A. CDR, konfigürasyon öğesi ile diğer ekipman, tesis, bilgisayar yazılımı ve personel öğeleri arasındaki ayrıntılı tasarım uyumluluğunu kurar b. CDR, yapılandırma öğesi risk alanlarını değerlendirir (teknik, maliyet ve program bazında) c. CDR, üretilebilirlik analizlerinin sonuçlarını değerlendirir d. CDR, tasarım çözümünün ayrıntılı tasarımının, performans ve test özelliklerinin kabul edilebilirliğinin belirlenmesine ve operasyon ve destek belgelerinin yeterliliğine odaklanır. e. CDR, sistemdeki her konfigürasyon öğesi (ürün temel çizgisi) için ürün spesifikasyonlarında yakalandığı şekliyle nihai sistem tasarımını değerlendirir ve ürün temel çizgisindeki her ürünün ayrıntılı tasarım belgelerinde, örneğin aşağıdakiler için ürün spesifikasyonlarında ele alındığından emin olur: (1 ) Donanım, konfigürasyon öğelerinin fabrikasyonunu sağlamak için ve üretimi içerebilir çizimler (2) Seçilen yaşam döngüsü model(ler)ine dayalı olarak SDP'de belirtilen ölçüde yazılım (örn. yazılım mimarisi ve bir Yazılım Yapılandırma Öğesinin (SWCI) ayrıntılı tasarımı) F. Karmaşık sistemler için, yüklenici her bir alt sistem veya konfigürasyon öğesi için bir CDR yürütebilir. Bu bireysel incelemeler, genel bir sistem CDR'sine yol açacaktır. Bireysel incelemeler yapıldığında, genel sistem CDR'sinin vurgusu, genel sistem ayrıntılı tasarım gerekliliklerinin yanı sıra konfigürasyon öğesi işlevsel ve fiziksel arayüz tasarımına odaklanmalıdır. G. Sistem CDR'si, donanım, insan ve yazılımın son ayrıntılı tasarımlarının tamamlanıp tamamlanmadığını ve yüklenicinin sistem üretimi, gösterimi ve testini başlatmaya hazır olup olmadığını belirler. Yapılandırma Öğesi (CI) Yapılandırma kalemi, belgelenmiş bir dizi gereksinimi karşılayan ve lojistik destek için gerekli olan veya ayrı satın alma için belirlenen herhangi bir öğeyi içeren bir öğedir. Konfigürasyon öğeleri, sözleşme yapan kurum tarafından nihai öğe (EI) olarak belirlenen veya yüklenici tarafından geliştirme/işlevsel son kullanım için önerilen ve bireysel yapılandırma yönetimi için belirlenmiş donanım veya yazılımdan veya her ikisinin bir araya gelmesinden oluşabilir. A. Konfigürasyon öğesi, bir son kullanım işlevini karşılayan ve ayrı konfigürasyon yönetimi için belirlenmiş herhangi bir donanım, yazılım veya her ikisinin birleşimidir. Konfigürasyon öğelerine tipik olarak, CI'nin ayrı ayrı birimlerini benzersiz bir şekilde tanımlamak için seri numaralarının atanması için değişmeyen bir temel işlevi gören alfanümerik bir tanımlayıcı tarafından atıfta bulunulur (Ayrıca bkz: Ürün İzleme Temel Tanımlayıcısı) B. "CI" ve "Ürün" terimleri, ANSI/EIA 649'da takma adlar olarak tanımlanır ve MIL-HDBK-61A içinde birbirinin yerine kullanılabilir C. Bir yapılandırma öğesi, bir son kullanım işlevini karşılayan donanım, aygıt yazılımı, bilgisayar yazılımı veya bunların herhangi bir ayrık parçasının toplamıdır ve Devlet tarafından ayrı yapılandırma yönetimi için belirlenir. CI'lar karmaşıklık, boyut ve tip bakımından bir uçak, elektronik veya gemi sisteminden bir test ölçere veya mermi mermisine kadar geniş ölçüde değişebilir. Lojistik Destek (LS) için gerekli olan ve ayrı tedarik için belirlenen herhangi bir kalem bir CI'dır [Savunma Edinim ve Terimler Sözlüğü, 2005] Sayfa 146 / 168 Machine Translated by Google Sözlük Operasyon Kavramı (CONOPS) CONOPS, amacı muharip komutanların karşılaşabilecekleri bir sorunu tanımlamak, ihtiyaçları belirlemek, hedeflere, yeteneklere veya istenen etkilere ulaşmak ve bunların istihdamını tanımlayan sıralı eylemleri tanımlamak olan üst düzey bir kavramdır. A. CONOPS, tipik olarak, bir yetenek veya sistem konseptini kullanmak ve desteklemek için satın alma ajansı planlayıcısı veya Sistem Program Ofisinin (SPO) desteğiyle operatör/kullanıcı tarafından geliştirilir. CONOPS, sistem fonksiyonel gereksinimlerini ve tasarım kısıtlamalarını belirlemek için Sistem Teknik Gereksinim Analizinde kullanılır. Raftan Ticari (COTS) COTS, gereksinimleri karşılamak için yaşam döngüsü boyunca benzersiz yüklenici aracı değişiklikleri veya bakım gerektirmeyen, ticari piyasada bulunan bir sistem ürünüdür. Etkililik (E) Etkililik, değişikliklerin veya sapmaların meydana geldiği zamandaki noktayı, bir olayı, bir yeteneği (örn. sistem, segment, SoS, IOC) veya bir ürün aralığını (örn. seri, lot numarası, model, tarih) tanımlayan bir atamadır. dahil edilecek. Mühendislik Verileri Mühendislik verileri, bir mühendislik tasarımını veya ürün konfigürasyonunu tanımlayan ve belgeleyen (orijinal öğelerin çoğaltılmasına izin verecek kadar yeterli) ve üretimi desteklemek için kullanılan bilgisayar yazılımı belgeleri de dahil olmak üzere (kayıt biçimi veya yönteminden bağımsız olarak) kaydedilen bilimsel veya teknik bilgilerdir. , mühendislik ve lojistik faaliyetler, örneğin: Katmak: A. Sistemler, alt sistemler, bilgisayar ve bilgisayar kaynak programları, bileşen mühendisliği, operasyonel testler, insan faktörleri, güvenilirlik, kullanılabilirlik ve bakım yapılabilirlik ve diğer mühendislik analizleri vb. ile ilgili tüm nihai planlar, prosedürler, raporlar ve belgeler. B. ASME Y14.100M'ye göre tüm mühendislik çizimlerini, ilişkili listeleri, işlem açıklamalarını ve diğer belgeleri, üretici özelliklerini, üretim planlama belgelerini ve fiziksel geometriyi, malzeme bileşimini tanımlayan standartları içeren MIL-DTL-31000'e göre teknik veri paketi (yeniden tedarik paketi) ve performans prosedürleri Donanım/yazılım öğelerinin veya hizmetlerinin tasarımı, üretimi, satın alınması, testi veya denetimi ile ilgili bir tasarım etkinliği tarafından hazırlanan diğer C. bilgiler Hariç tutmak: A. Bilgisayar yazılımı veya mali, idari, maliyet veya fiyatlandırma veya yönetim verileri veya sözleşme yönetimine bağlı diğer bilgiler Uçuşa Hazırlık İncelemesi (FRR) Uçuşa Hazırlık İncelemesi (FRR), incelenmekte olan sistemin, uçuşa elverişlilik standartlarının karşılanması, hedeflerin açıkça belirtilmesi, uçuş testi veri gereksinimlerinin açıkça tanımlanması ve kabul edilebilir bir risk yönetimi ile uçuş testine geçebilmesini sağlamak için gerçekleştirilen çok disiplinli bir ürün ve süreç değerlendirmesidir. planı tanımlanmış ve onaylanmıştır. FRR şu amaçlarla toplanır: A. Mühendislik ve uçuş arasında uygun koordinasyonun oluştuğundan emin olun B. Uygulanabilir tüm disiplinlerin, belirlenen çaba kapsamını anladığından ve bunlarla aynı fikirde olduğundan emin olun Sayfa 147 / 168 Machine Translated by Google Sözlük C. Uçuşa elverişlilik ile test ve değerlendirme gerekliliklerini karşılamak için gerekli verilerin elde edilmesi için bu çabanın nasıl yürütüleceğinin yeterliliğini değerlendirin. D. Uçuş testi çabası içinde değerlendirilecek her konfigürasyon için yeterliliği ve uygun ayrıntı düzeyini değerlendirin İşlev Bir işlev, gerekli bir sonuca ulaşmak veya operasyonel bir ihtiyacı karşılamak için gerçekleştirilecek bir görevdir. İşlevsel (Analiz, Tahsis ve Mimari) Fonksiyonel Analiz ve Tahsis A. Sistemin ömrü boyunca birincil sistem fonksiyonlarını yerine getirmek için ihtiyaç duyulan üst düzey fonksiyonların belirlenmesi, bunların ilişkileri ve her bir alt fonksiyon veya alt fonksiyon kümesinin olabileceği noktaya kadar alt fonksiyonlara ayrıştırılması. tahsis edilen temeldeki bir ve yalnızca bir fiziksel öğeyle ilgili, her bir işlevin ve alt işlevin ne kadar iyi yerine getirilmesi gerektiğini belirlemek için gereksinimler temelindeki üst seviye gereksinimlerin ve kısıtlamaların tahsisi ve fonksiyonel bir bütünün yakalanması mimari Fonksiyonel Mimari A. İşlevsel analiz ve tahsisin sonucu b. Fonksiyonların hiyerarşik düzenlemesi, bunların alt fonksiyonlara ayrışması, ilgili zaman çizelgeleri ve performans gereksinimlerinin ve kısıtlamaların gereksinimler temelindeki işlevlere ve alt işlevlere tahsisi Fonksiyonel elemanlar arasındaki arayüzler C. Artımlı Geliştirme A. Artımlı geliştirme, istenen tüm yeteneklerin tanımlandığı bir yaşam döngüsü modelidir; tüm son durum gereksinimleri önceden bilinir ve anlaşılır ancak parçalar halinde veya artımlarla uygulanır. Tüm gereksinimler başlangıçta bilindiğinden, tüm artışlar önceden planlanabilir; uygulama sıralama sırası ve çakışmaları, artım geliştirmenin başlangıcında belirlenecektir. Bilgi Değişimi Gereksinimleri (IER'ler) A. IER'ler, Yetenek Geliştirme Belgelerinde (CDD'ler), Yetenek Üretim Belgelerinde (CPD'ler) ve Bitirme Gereksinim Belgelerinde (CRD'ler) belgelenen birlikte çalışabilirlik KPP eşiğini ve nesnel değerleri tanımlayan gereksinimlerdir. B. IER'ler, incelenmekte olan sistemin gerektirdiği bilgi ihtiyaçlarını belgelemektedir. ve desteklenen diğer sistemlerin ihtiyaçları C. IER'ler, önerilen sistemin komuta, kontrol, iletişim, bilgisayarlar ve istihbarat (C4I) için tüm iletişim ve bilgi işlem gereksinimlerini belgeler. İlk Teknik İnceleme (ITR) ITR, programın ilk Program Hedefi Memorandum (POM) sunumunu destekleyen çok disiplinli bir teknik incelemedir. A. ITR, önerilen programın öngörülen gereksinimlerini ve kavramsal yaklaşımını değerlendirir ve proje için gerekli araştırma, geliştirme, test, mühendislik, lojistik ve programatik temellerin teknik zorluklar ve risklerin tüm yelpazesini yansıttığını doğrular. Sayfa 148 / 168 Machine Translated by Google Sözlük B. Bu gözden geçirme, bir programın teknik temelinin, geçerli bir maliyet tahminini (kabul edilebilir maliyet riski ile) desteklemek için yeterince titiz olmasını ve bu tahminin maliyet, teknik ve program yönetimi konu uzmanları tarafından bağımsız bir şekilde değerlendirilmesini sağlar. C. ITR, sorun çözümü ve süreç ve sonuçlar üzerinde yönetici düzeyinde uygun mutabakat için zaman sağlamak üzere gerçek maliyet tahmini sunumundan çok önce tutulur. ITR, ASR'den önceki herhangi bir zamanda yapılabilir. birlikte çalışabilirlik Sistemlerin, birimlerin veya güçlerin diğer sistemlere, birimlere veya güçlere veri, bilgi, malzeme ve hizmetler sağlama ve bunları kabul etme ve bu şekilde değiş tokuş edilen veri, bilgi, malzeme ve hizmetleri kullanma yeteneği. birlikte etkin bir şekilde çalışır. Bilgi teknolojisi ve Ulusal Güvenlik Sistemlerinin birlikte çalışabilirliği, hem teknik bilgi alışverişini hem de görevin yerine getirilmesi için gerekli olan bu değiş tokuş edilen bilginin uçtan uca operasyonel etkinliğini içerir. Anahtar Performans Parametresi (KPP) KPP, etkili bir askeri yetenek için en gerekli kabul edilen minimum özellik veya özelliktir. A. KPP'ler, karşılanması gereken EI yetenekleridir. B. KPP'ler, kullanıcının dikkate almaya istekli olduğu kritik performans gereksinimleridir. bir koşul karşılanmazsa programın iptali Yaşam döngüsü Yaşam döngüsü, bir görev ihtiyacının belirlenmesi veya bir sistem eksikliğinin belirlenmesi ile başlayan ve sistemin tasfiye edilmesine kadar olan sonraki tüm aşamalar boyunca bir sistem veya yükseltme evriminin kapsamıdır. İmalat "İmalat" terimi, bir ürün yapmak için gereken tüm unsurları kullanmak için gerekli olan geniş bir dizi işlevsel görevi kapsar. Programı desteklemek için Ulusal Teknoloji ve Endüstriyel Üs (NTIB) yetenekleri, uygun maliyetli üretim için tasarımı etkileme, ihtiyaç duyulan insanlar ve beceriler, malzeme seçimi, uygun üretim yöntemleri, yetenekli makineler gibi çok çeşitli konular dahildir. , çizelgeleme, ölçümler ve kalite güvence yönetim sistemleri. İmalat, matrisle atanan imalat müdürleri, diğer program ofisi görevlileri, sözleşmeli yönetim hizmetleri personeli, laboratuvarlar, yükleniciler ve emtia personeli ile depo personeli dahil olmak üzere çeşitli organizasyonlardan fonksiyonel uzmanlıkların desteğini gerektirir. Üretime Hazırlık Düzeyleri (MRL'ler) Üretime Hazırlık Düzeyleri (MRL'ler), üretime hazır olma durumunu ve üretilebilirlik olgunluğunu üretim perspektifinden değerlendirmek için kullanılan ölçütlerdir. MRL'ler, gereksinimleri karşılaması düşünülen üretim teknolojileri, ürünler ve süreçlerle ilişkili göreli olgunluk (ve ilişkili riskler) hakkında ortak bir anlayış sağlar, satın alma programlarında üretimle ilişkili riskleri tanımlar ve azaltır, üretim riskini azaltır ve tam oran öncesinde üretilebilirliği gösterir. üretme. Sayfa 149 / 168 Machine Translated by Google Sözlük Tablo 4. DoD MRL Tanımları MRL Seviye 1-3 Tanımlar İmalat kavramları belirlendi. Seviye 4 Laboratuvar ortamında sistem, bileşen veya öğe doğrulaması. Seviye 5 İlk ilgili ortamda sistem, bileşen veya öğe doğrulaması. Mühendislik uygulaması/breadboard, brassboard geliştirme. Seviye 6 Breadboard ötesinde prototip gösteriminde sistem, bileşen veya öğe, tahta geliştirme. Seviye 7 Gelişmiş geliştirme aşamasında olan sistem, bileşen veya öğe. Düzey 8 Gelişmiş geliştirme aşamasında olan sistem, bileşen veya öğe. LRIP için hazır. Seviye 9 Sistem, bileşen veya öğe önceden üretilmiş veya üretimde veya sistem, bileşen veya öğe LRIP'de. Tam Oranda Üretime (FRP) Hazır. Seviye 10 Daha önce üretilmiş veya üretimde olan sistem, bileşen veya öğe veya sistem, bileşen veya öğe FRP'de. Tablo 5. DoD MRL Açıklamaları MRL Seviye 1-3 Seviye 4 Tanım Laboratuvar çalışmalarına dayalı olarak mevcut üretim konseptlerinin veya üretilebilirlik ihtiyaçlarının belirlenmesi. Bu, üretime hazır olmanın en düşük seviyesidir. Teknolojiler en az TRL 4 olacak şekilde olgunlaşmış olmalıdır. Bu noktada, çok az gereksinim onaylanmıştır ve çok sayıda mühendislik/tasarım değişikliği vardır. Bileşen fiziksel ve fonksiyonel arayüzleri tanımlanmamıştır. Malzemeler, makineler ve aletler bir laboratuvar ortamında gösterilmiştir. Muayene ve test ekipmanları laboratuvar ortamında gösterilmiştir. Üretim maliyeti etkenleri belirlenir. Üretilebilirlik değerlendirmeleri başlatıldı. Seviye 5 Teknolojiler en az TRL 5 olacak şekilde olgunlaşmış olmalıdır. Bu noktada, tüm gereksinimler doğrulanmamıştır ve önemli mühendislik/tasarım değişiklikleri vardır. Bileşen fiziksel ve fonksiyonel arayüzleri tanımlanmamıştır. Malzemeler, makineler ve aletler, ilgili bir üretim ortamında gösterilmiştir, ancak çoğu üretim süreci ve prosedürü geliştirme aşamasındadır (veya ManTech girişimleri devam etmektedir). Muayene ve test ekipmanları laboratuvar ortamında gösterilmiştir. Üretim maliyeti etkenleri/ hedefleri analiz edilir. Sistem düzeyinde DTC hedefleri ayarlandı. Üretilebilirlik değerlendirmeleri devam ediyor. Sayfa 150 / 168 Machine Translated by Google Sözlük Seviye 6 Prototip gösterim aşamasında, gereksinimler doğrulanır ve tanımlanır. Bununla birlikte, hala birçok mühendislik/tasarım değişikliği vardır ve fiziksel ve işlevsel arayüzler henüz tam olarak tanımlanmamıştır. Teknolojiler en az 6 TL'ye olgunlaşmış olmalıdır. Hammaddeler öncelikle ilgili imalat ortamında tanıtılır. Benzer süreçler ve prosedürler, ilgili bir üretim ortamında gösterilmiştir. Bu noktada, muhtemelen makineler ve aletler için gerekli olan büyük yatırımlar vardır. Muayene ve test ekipmanı geliştirme aşamasında olmalıdır. Üretilebilirlik risk değerlendirmeleri devam etmekte ve ticari çalışmalar yürütülmektedir. Bir üretim Maliyeti Azaltma Planı geliştirilir. Üretim hedeflerine ulaşıldı. Seviye 7 Teknolojiler en az 7 TL'ye kadar olgunlaşmış olmalıdır. Bu noktada mühendislik/tasarım değişiklikleri azalmalıdır. Fiziksel ve işlevsel arayüzler açıkça tanımlanmalıdır. Tüm hammaddeler üretimdedir ve planlanan Düşük Oranlı İlk Üretim (LRIP) programını karşılamak için hazırdır. Pilot hat üretim süreçleri ve prosedürleri ayarlandı ve test ediliyor. Henüz kanıtlanmamış veya kontrol altında olmayan süreçler ve prosedürler. Bu aşamada, ilk üretilebilirlik iyileştirmeleri devam ediyor olmalıdır. DTC tahminleri, hedeflerin yüzde 125'inden az. Ayrıntılı üretim tahminleri oluşturulur. Seviye 8 Teknolojiler en az 8 TL'ye kadar olgunlaşmış olmalıdır. Bu noktada mühendislik/tasarım değişiklikleri önemli ölçüde azalmalıdır. Fiziksel ve işlevsel arayüzler açıkça tanımlanmalıdır. Tüm hammaddeler üretimde ve planlanan LRIP programını karşılamak için hazır. Üretim süreçleri ve prosedürleri pilot hatta kanıtlanmıştır ve kontrol altındadır ve LRIP için hazırdır. Bu aşamada, ilk üretilebilirlik risk değerlendirmeleri tamamlanmalıdır. Üretim maliyeti tahminleri, DTC hedeflerini karşılar. 9. Seviye LRIP sırasında, tüm sistem mühendisliği/tasarım gereksinimleri karşılanmalı ve yalnızca minimum sistem mühendisliği/ tasarım değişiklikleri olmalıdır. Teknolojiler en az 9 TL'ye olgunlaşmış olmalıdır. Malzemeler üretimdedir ve planlanan üretim programlarını karşılamaya hazırdır. Üretim prosesleri ve prosedürleri, üretimde üç sigma veya başka bir uygun kalite seviyesinde kurulur ve kontrol edilir. Makineler, takımlar ve inceleme ve test ekipmanları, üretimde üç sigma veya başka bir uygun kalite düzeyi sağlar. Üretim risk izlemesi devam etmektedir. LRIP fiili maliyetleri tahminleri karşılamaktadır. Seviye 10 En yüksek üretim hazırlığı seviyesi. Minimum mühendislik/tasarım değişikliği. Sistem, bileşen veya öğe üretimdedir veya üretilmiştir ve tüm mühendislik, performans, kalite ve güvenilirlik gereksinimlerini karşılamaktadır. Tüm malzemeler, imalat süreçleri ve prosedürleri, muayene ve test ekipmanları, üretimde altı sigma veya diğer uygun kalite seviyelerine göre üretimde kontrol edilir. Kanıtlanmış, uygun fiyatlı bir ürün, gerekli programı karşılayabilir. Üretim fiili maliyetleri tahminleri karşılar. Sayfa 151 / 168 Machine Translated by Google Sözlük Net Merkezli Ağ merkezli bir ortamın nitelikleriyle ilgili veya bunları temsil eden. Ağ merkezli bir ortam, verilerin kullanıcılar, uygulamalar ve platformlar arasında zamanında ve sorunsuz bir şekilde paylaşıldığı sağlam, küresel olarak birbirine bağlı bir ağ ortamıdır (altyapı, sistemler, süreçler ve insanlar dahil). Ağ merkezli bir ortam, önemli ölçüde gelişmiş askeri durumsal farkındalık ve önemli ölçüde kısaltılmış karar verme döngüleri sağlar. Ağa Hazır Anahtar Performans Parametresi (NR-KPP) NR-KPP, hem teknik bilgi alışverişi hem de bu alışverişin uçtan uca operasyonel etkinliği için gereken bilgi ihtiyaçlarını, bilgi güncelliğini, bilgi güvencesini ve ağa hazır olma özelliklerini değerlendirir. NR-KPP, belirli bir yetenek için bilgi ihtiyaçlarını karşılamak üzere bilgilerin zamanında, doğru ve eksiksiz değişimi ve kullanımı için gerekli olan ölçülebilir ve test edilebilir özelliklerden ve/veya performans ölçütlerinden oluşur. İhtiyaç Tahsis Belgesi (RAD) RAD, bir sistem mimarisinin öğeleri (örn. SoS, segmentler, öğeler, alt sistemler ve alt düzey HW ve SW yapılandırma öğeleri ve birimleri) ile gereksinimler (arayüz, işlevsel, kalite, test, vb.) ve ayrıca ürünün teknik gereksinimler belgesinde veya kullanıcı gereksinimlerinde belirtilmeyen programa/sisteme özgü/özgün koşullar. RAD, aşağıdaki öğelerin gözlemlendiğine dair kanıt sağlar: A. Tüm gereksinimler ve marjinal koşullar, sistem mimarisinin her öğesi tarafından ele alınır B. Her gereksinim, teknik mimarinin en az bir unsuruna atanır c. Her gereksinim, d en düşük öğeye kadar akıtılır. Her gereksinim, uygun başarı kriterleri ile tanımlanmış bir metodoloji aracılığıyla doğrulanabilir ve bir Gereksinim Doğrulama İzlenebilirlik Matrisi (RVTM) ile belgelenir. Tahsis edilen her gereksinimin, iki yönlü olarak izlenebilir ve Gereksinim İzlenebilirlik Matrisi (RTM) tarafından belgelenen bir üst/alt ilişkisi vardır. Gereksinimler Gereksinimler, doğrulanabilen ve paydaş kabulü için gerekli görülen bir sistemi, ürünü veya süreç özelliğini veya kısıtlamasını tanımlayan açık ifadelerdir. Gereksinimler, bir sözleşmeyi, standardı, spesifikasyonu veya diğer resmi olarak dayatılan belgeleri veya bir belgelenmiş temsili yerine getirmek için bir sistem veya sistem bileşeni tarafından karşılanması veya sahip olunması gereken bir sorunu çözmek veya bir hedefe ulaşmak için bir kullanıcının ihtiyaç duyduğu koşullar veya yeteneklerdir. geliştirme sürecinin çeşitli aşamalarında durum veya yetenek. Gereksinimler başlangıçta Sistem Gereksinimlerinin Gözden Geçirilmesinde (SRR) veya benzer bir etkinlikte onaylanır ve bunlarla sınırlı olmamak üzere aşağıdaki türleri A. kapsayabilir: Kabul Edilebilirlik (Gereksinimler) Kabul edilebilirlik gereksinimleri, tüm kullanıcı yeteneklerini ve gereksinimlerini karşılayan bir sistemi tanımlar. Tüm kullanıcı gereksinimleri, sistem ve alt düzey gereksinimleri takip eder B. Analiz (Gereksinimler) Gereksinim analizi, gerekli operasyonel yetenekler, gereksinimler, hedefler (veya hedefler), etkinlik ölçütleri; görevler; öngörülen kullanım ortamları; Savunma Bakanlığı politikaları ve uygulamaları; kamu hukuku; ve bir yandan sağlanacak yetenekler ile evrimsel büyüme potansiyeli arasındaki denge ve Sayfa 152 / 168 Machine Translated by Google Sözlük Öte yandan maliyet, program ve risk. Gereksinim analizlerinin sonuçları, gereksinim temel çizgisinde belgelenir. C. Temel (Gereksinimler) Temel gereksinimler, belgelenmiş, doğrulanmış ve onaylanmış sistem düzeyinde (üst düzey) doğrulanabilir ve tahsis edilebilir işlevsel ve performans teknik gereksinimleri ve tasarım kısıtlamaları, bunların bir sonraki düzeye (ve gerekirse sistem mühendisliği temelini yakalamak için daha düşük düzeylere) tahsis edilmesi veya atanmasıdır. program için) ve sözleşmeye uygun olarak onaylanan tüm değişiklikler D. Kısıtlamalar (Gereksinim) Kısıtlamalar, içinde diğer gereksinimlerin tahsis edilmesi veya türetilmesi ve sistem ürünlerinin tasarlanması gereken sınırları oluşturan gereksinimlerdir. Kısıtlamalar, başka bir sistemle bir arayüz tarafından harici olarak empoze edilebilir veya program veya sözleşmenin dahili kararlarından kaynaklanabilir. Kısıtlamalar genellikle federal yasa, DOD politikası ve yönergesi ve veya gerekli standartlar ve spesifikasyonlar tarafından yönlendirilir. Bu. Türetilmiş gereksinimler, önerilen çözümün doğasından çıkarılan yetenek ihtiyacında açıkça belirtilmeyen gereksinimlerdir; geçerli doğrulama, yeniden işleme, depolama, nakliye, çalıştırma ve destek ortamları; politika; kanun; en iyi mühendislik uygulaması; veya yukarıdakilerin bir kombinasyonu F. Tasarım Hedefi (Gereksinimler) Tasarım gereklilikleri, donanım, yazılım, süreçler, veriler veya yeni veya değiştirilmiş yüklenici kuruluş tesisleri dahil olmak üzere bir sistem ürününün tasarımının uyması gereken tahsis edilmiş ve türetilmiş doğrulanabilir teknik gereksinimler ve tasarım kısıtlamalarıdır g. Geliştirme (Gereksinimler) Gereksinim Geliştirme, ilgili paydaşlardan tüm girdileri alma ve bunu teknik biçim, uygunluk (uygunluk), işlev ve performans (FFF&P) gereksinimlerine dönüştürme sürecidir İşlevsel (Gereksinim) H. İşlevsel gereksinim, bir sistem veya son ürün/EI tarafından sağlanması gereken bir ihtiyaç veya yetenektir. Ben. Arayüz (Gereksinimler) (1) Fiziksel (2) İşlevsel (3) Dahili (4) Dış (5) Programlar J. Performans gereklilikleri) Performans gereklilikleri, genellikle nicelik, kalite, kapsam, zamanlılık veya hazır olma gibi terimlerle ölçülen, bir işlevin ne ölçüde yürütülmesi gerektiğine ilişkin ifadelerdir. İşlevsel Gereksinime Bakın Sayfa 153 / 168 Machine Translated by Google Sözlük k. Referans (Gereksinimler) Referans gereksinim, daha yüksek düzeyde bir gereksinim ve/veya bir gereksinim, gereksinim tahsisi veya başka bir temel veya işlevsel mimari öğesi için bir analiz, test veya başka bir gerekçedir. Risk Risk, gelecekte ortaya çıkabilecek, program hedefleri ve hedefleri gibi tanımlanmış maliyet, program ve teknik performans gibi tanımlanmış parametreler veya kısıtlamalar dahilinde bir hedefe ulaşılamaması ile sonuçlanabilecek potansiyel bir sorun veya belirsizliktir. Riskin iki bileşeni vardır: a. Belirli bir sonuca ulaşamama olasılığı/olasılığı b. Bu sonuca ulaşamamanın sonuçları/ etkileri Risk Yönetim Süreci Risk yönetimi, bir sistemin yaşam döngüsü boyunca gerçekleştirilen sürekli bir süreçtir. Bilinmeyenleri sürekli olarak belirlemek ve ölçmek için organize bir metodolojidir; hafifletme seçeneklerinin geliştirilmesi; uygun risk azaltmanın seçilmesi, planlanması ve uygulanması; ve başarılı bir risk azaltma sağlamak için uygulamanın izlenmesi. Etkili risk yönetimi, risk yönetimi planlamasına bağlıdır; risklerin erken tespiti ve analizi; düzeltici eylemlerin erken uygulanması; sürekli izleme ve yeniden değerlendirme; ve iletişim, dokümantasyon ve koordinasyon. Risk yönetimi süreci, sürekli olarak gerçekleştirilen aşağıdaki temel faaliyetleri içerir: A. Risk tanımlaması B. Risk analizi C. Risk Azaltma Planlaması D. Risk Azaltma Planı Uygulaması Bu. Risk Takibi Önemli Başarı Önemli bir başarı, bir etkinliği tamamlamaya ve dolayısıyla sözleşmenin amaçlarını ve gerekliliklerini karşılamaya yönelik ilerleme düzeyini gösteren belirli bir adım veya sonuçtur. Önemli Başarı Kriterleri Önemli başarı kriterleri, Entegre Ana Planda (IMP) listelenen önemli bir başarı tamamlanmadan ve başarıya bağlı çalışma devam etmeden önce tatmin edici bir şekilde gösterilmesi gereken spesifik, ölçülebilir koşullardır. Yazılım İncelemeleri Yazılım incelemeleri, eksik veya tutarsız ürünler veya sistemin gereksinimlerini veya kullanıcılarının ihtiyaçlarını karşılamamasına neden olacak yazılım ürünleri gibi olası sorunları bulmak için düzenlenen bir dizi yazılım derleme incelemesidir. Yazılım incelemeleri örneğin şunları içerir: A. Yazılım Gereksinimleri ve Mimari İncelemesi (SAR) B. Yazılım Derleme Planı İncelemesi (SBPR) C. Yazılım Oluşturma Gereksinimleri İncelemesi (SBRR) D. Yazılım Yapı Tasarımı İncelemesi (SBDR) Bu. Yazılım Oluşturma Testine Hazırlık İncelemesi (SBTRR) Sayfa 154 / 168 Machine Translated by Google Sözlük F. Yazılım Oluşturma Testi Çıkış İncelemesi (SBTER) Bu incelemeler her yapı için tekrarlanır. Artımlı yazılım incelemeleri için (gereksinimlerin tümünün önceden bilindiği durumlarda), SBRR kısa olacak, yaklaşan yapı için yazılım gereksinimlerinin mevcut anlayışına odaklanacak ve yaklaşan veya gelecekteki yapılar için hiçbir gereksinimi değiştirmeye gerek olmadığını doğrulayacaktır. Uzay Sistemi Uzay sistemi, yer (hareketli veya sabit), uzay (karma yüklere sahip uydular) ve havadaki yeteneklerin veya sistemlerin bir karışımının, yeteneklerden daha büyük bir operasyonel ve işlev kabiliyetine sahip bir sistemler sistemine organizasyonu ve entegrasyonudur. onu oluşturan parçalardan. sarmal geliştirme Spiral geliştirme, istenen bir yeteneğin tanımlandığı, ancak son durum gereksinimlerinin program başlangıcında bilinmediği bir süreç ve yaşam döngüsü geliştirme modelidir. Bu gereksinimler, sürekli kullanıcı geri bildiriminin olduğu ve her artışın kullanıcıya mümkün olan en iyi yeteneği sağladığı gösterim ve risk yönetimi yoluyla rafine edilir. Gelecekteki artışlar için gereksinimler, kullanıcılardan gelen geri bildirimlere ve teknoloji olgunlaşmasına bağlıdır. Boehm1 sarmal modeli "Riske dayalı süreç modeli üreteci" olarak tanımlar. Yazılım yoğun sistemlerin çok paydaşlı eşzamanlı mühendisliğine rehberlik etmek için kullanılır. İki ana ayırt edici özelliği vardır. Biri, risk derecesini azaltırken bir sistemin tanımlama ve uygulama derecesini aşamalı olarak büyütmek için döngüsel bir yaklaşımdır. Diğeri, uygulanabilir ve karşılıklı olarak tatmin edici sistem çözümlerine yönelik paydaş taahhüdünü sağlamak için bir dizi bağlantı noktası kilometre taşıdır.” sentez Sentez, işlevsel mimarilerin ve bunlarla ilişkili gereksinimlerin fiziksel mimarilere ve bir veya daha fazla fiziksel donanım, yazılım ve personel çözümlerine dönüştürüldüğü süreçtir. sistem Sistem, Sistemler Sistemi (SoS), Sistem Ailesi (FoS), Segmentler, Alt Sistemler ve/veya Bileşenden oluşabilir. Tüm sistemler iki öğeden oluşur: a. Bir edinen tarafından amaçlanan bir amaç için kullanılacak nihai ürünler ve bir nihai ürünün veya nihai ürünlerin bir araya toplanmasının yaratılmasını, gerçekleştirilmesini ve kullanılmasını sağlayan etkinleştirici ürünler seti. B. Sistemin ilişkili süreç fonksiyonlarını gerçekleştirmek için kullanılan etkinleştirme ürünleri— son ürünleri geliştirmek, üretmek, test etmek, dağıtmak ve desteklemek; son ürünleri kullanan operatörleri ve bakım personelini eğitin; ve artık kullanım için uygun olmayan son ürünleri emekliye ayırın veya elden çıkarın Hem nihai ürünler hem de etkinleştiren ürünler uygun şekilde geliştirilir veya yeniden kullanılır. Sistem, sistem ürünlerini geliştiren, üreten, test eden, çalıştıran, destekleyen ve kullanımdan kaldıran personelin yanı sıra, hem bu sistem işlevleriyle ilgili diğerlerini eğitenleri hem de bu personelle ilgili insan faktörü konularını ve endişelerini dolaylı olarak içerir. Bu tür personel ve insan faktörleri konuları, bu standardın teknik inceleme süreçlerinin uygulamalarında yer almaktadır. 1 Boehm, Barry. 2001. Spiral Modeli Evrimsel Kazanım İçin Bir Araç Olarak Anlamak. Sayfa 155 / 168 Machine Translated by Google Sözlük Sistem Mühendisliği (SE) Sistem mühendisliği, bir program ekibinin belirtilen bir yetenek ihtiyacından operasyonel olarak etkili ve uygun bir sisteme geçiş için uyguladığı kapsayıcı süreçtir. Sistem mühendisliği, satın alma yaşam döngüsü boyunca (her aşamaya uyarlanmış) sistem mühendisliği süreçlerinin uygulanmasını kapsar ve yetenek ihtiyaçlarını ve tasarım hususlarını ve kısıtlamalarının yanı sıra teknolojinin getirdiği sınırlamaları ele alan dengeli çözümler için bütünleştirici mekanizma olması amaçlanır. bütçe ve zamanlama. Sistem Mühendisliği Süreçleri Sistem mühendisliği süreçleri yinelemeli ve özyinelemelidir ve kontrollü taban çizgileri kullanılarak bir geliştirme düzeyinden sonraki daha ayrıntılı düzeye düzenli bir ilerleme sağlamak için sistem yapısının alt ve alt düzeylerinde uygulanır. A. SE süreçleri, kavram tanımının başında ve ardından toplam yaşam döngüsü boyunca sürekli olarak uygulanır b. SE süreçleri, sistem, alt sistemler ve sistem bileşenleri ile bu sistemin üretimi, işletilmesi, eğitimi, desteklenmesi ve imhası için kullanılan destekleyici veya etkinleştirici sistemler için kullanılır. SE süreçleri, gereksinimlerin tasarımdan sisteme geçişini sağlar ve gereksinimler evreninin toplu bir bütün olarak tanımlanabileceği, analiz edilebileceği, ayrıştırılabileceği, ticareti yapılabileceği, yönetilebileceği, tahsis edilebileceği, tasarlanabileceği, entegre edilebileceği ve test edilebileceği entegre bir çerçeve olarak hizmet eder. , alanlı ve sürekli. Sistemler Sistemi (SoS) Mühendisliği Sistem mühendisliği, planlama, analiz, organizasyon ve mevcut ve yeni yeteneklerin/sistemlerin bir karışımının, mevcut ve yeni yeteneklerin/sistemlerin bir sistem kabiliyeti sistemine entegrasyonunu kapsayan disiplinli bir süreçtir. oluşturan parçalar. SoS mühendisliği, sistem yeteneklerini belirlemek için kullanılan yukarıdan aşağıya, kapsamlı, işbirlikçi, çok disiplinli, yinelemeli ve eşzamanlı bir teknik yönetim sürecidir; bu tür yetenekleri bir dizi birbirine bağlı sisteme tahsis etmek; ve bir sistemler sisteminin yaşam döngüsü boyunca gerekli tüm geliştirme, üretim, sürdürme ve diğer faaliyetleri koordine etmek ve entegre etmek. Sistem Doğrulama İncelemesi (SVR) SVR, incelenmekte olan sistemin maliyet (program bütçesi), program (program çizelgesi), risk ve diğer sistem kısıtlamaları. SVR şunları onaylar: A. Sistemin nihai ürünü, üretim konfigürasyonunun kanıtladığı gibi, İşlevsel, Tahsis Edilen ve Ürün Temel Çizgilerinde belgelendiği gibi işlevsel gereksinimleri (Yetenek Geliştirme Belgesinden ve taslak Yetenek Üretim Belgesinden elde edilen) karşılar. B. Karar veri tabanı, aşağıdakileri tam ve doğru bir şekilde yakalayacak şekilde tüm değişiklikleri ve güncellemeleri içerecek şekilde tutulmuştur: (1) Mevcut onaylanmış temeller (2) Doğrulama (DT&E) ve doğrulama (IOT&E) sırasında keşfedilen eksiklikler çözüldü ve değişiklikler onaylandı ve uygulandı (3) Onaylanan diğer tüm değişiklikler, etkilenen ana hatlara dahil edilmiştir ve uyumlu olduğu doğrulanan etkilenen sistem ürünleri Sayfa 156 / 168 Machine Translated by Google Sözlük (4) Yaşam döngüsü maliyet projeksiyonları, programın karşılanabilirliği ile tutarlı olmaya devam ediyor kısıtlamalar (5) Üretimi, üretim doğrulamasını, eğitimi, konuşlandırmayı, operasyonları, desteği ve imhayı başlatmak için gerekli planlar, prosedürler, kaynaklar ve tesisler mevcuttur (veya programa göre) (6) Geri kalan riskler tanımlanmıştır ve bu riskler kapsamında ele alınabilir. planlanan program (7) Doğrulama verileri, analiz yoluyla doğrulamada kullanılan varsayımların ve yöntemlerin bir değerlendirmesi de dahil olmak üzere, sistemin ve onu oluşturan ürünlerin temel hatlara uygunluğunu ve gereksinimleri, tahsis edilen ana hatları ve tasarım yayın temel hatlarını karşıladığını belgelemektedir. Üretime Hazırlık Gözden Geçirmesi ile eşzamanlı olarak. SVR, Kritik Tasarım İncelemesinden bir denetim izi sağlar. SVR, Yetenek Üretim Belgesine girdiler sağlar. terzilik Terzilik, belirli bir satın alma sözleşmesine ne ölçüde uygulanabileceklerini açıklığa kavuşturmak için metinlerin, şekillerin, grafiklerin veya şartname tablolarının, standartların ve diğer gereksinimlerin veya görevlendirme belgelerinin değiştirilmesidir. A. Müteahhitin takdirine bağlı olarak terzilik yapılır. Her başvuruda, bu belge, ihale acentesi tarafından yönlendirildiği şekilde belirli bir programın, program aşamasının veya sözleşme yapısının özel gereksinimlerine göre uyarlanacaktır. Gereksiz maliyet, veri ekleyen görevler, sürece veya ürüne değer katmayan her türlü faktör ortadan kaldırılmalıdır. B. Uyarlama, silme (uygulanamayan görevlerin kaldırılması), değiştirme (belirli bir çabaya uygulamayı daha açık bir şekilde yansıtmak için görevleri değiştirme) veya ekleme (program gereksinimlerini karşılamak için görevler ekleme) şeklini alır. Gereksinimlerin ve görev bildirimlerinin uyarlanması, talep belgelerinin hazırlanmasında ve ayrıca bir Teklif Talebi taslağına yanıt olarak yükleniciler tarafından kullanılabilir. TBD/TBR/TBS/TBP A. TBD - Geliştirici tarafından belirlenecek (veya resmi olarak yükleniciye tavsiye edilecek) ajan) belirtilen ve belgelenen bir tarihe göre analiz veya teste dayalı B. TBR - Ön unsur, belirtilen ve belgelenen bir tarihe kadar analiz veya teste dayalı olarak geliştirici tarafından çözülecektir (veya yükleniciye tavsiye edilecektir). C. TBS - Sözleşme yapan kurum tarafından geliştiriciye üzerinde anlaşmaya varılan ve belgelenmiş tarih D. TBP - Sözleşme yapan kurum tarafından geliştiriciye üzerinde anlaşmaya varılan ve belgelenmiş tarih Teknik Performans Ölçümü (TPM) TPM, teknik parametreler için mevcut fiili başarıyı mevcut zamanda ve gelecekteki tarihlerde tahmin edilenle karşılaştıran bir ölçümdür ve ilerlemeyi teyit eder ve bir KPP yeteneğinin sağlanmasını veya bir gereksinimi karşılamayı tehlikeye atabilecek eksiklikleri tanımlar. Tipik TPM aday seçimleri: A. Tüm sistemi önemli ölçüde nitelendiren performans parametreleri B. Doğrudan analizlerden, gösterimlerden veya testlerden elde edilen parametreler Sayfa 157 / 168 Machine Translated by Google Sözlük C. Analizlerin veya testlerin sonuçlarından elde edilen doğrudan bir değer ölçüsü Temeli D. olan tahmin edilen değerler (analizler, geçmiş veriler) e. Her parametre, program yaşam döngüsü boyunca tahmin edilen değerler ve toleranslarla karşılaştırmak için periyodik olarak ölçülebilir ve profillenebilir. TPM'lerin takibi tipik olarak, ideal olarak SFR tarafından ancak PDR'den sonra olmamakla birlikte, seçilen TPM'lerin tamamı programın yaşam döngüsünde daha sonraya kadar mevcut olmayabilir, ancak bir temel tasarım oluşturulur oluşturulmaz başlar. Teknoloji Hazırlık Düzeyleri (TRL'ler) TRL, gelişen teknolojilerin (malzemeler, bileşenler, cihazlar vb.) bu teknolojiyi bir son öğeye (sistem, alt sistem veya CI) dahil etmeden önceki olgunluğunun bir ölçüsüdür. Tablo 6. DoD TRL Tanımları TL Tanımlar Seviye 1 Gözlenen ve raporlanan temel ilkeler Seviye 2 Formüle edilen teknoloji konsepti ve/veya uygulaması 3. seviye Analitik ve deneysel kritik işlev ve/veya karakteristik kavram kanıtı Seviye 4 Laboratuvar ortamında bileşen ve/veya devre tahtası doğrulaması Seviye 5 İlgili ortamda bileşen ve/veya devre tahtası doğrulaması Seviye 6 İlgili bir ortamda sistem/alt sistem modeli veya prototip gösterimi (Yer veya Uzay) Seviye 7 Operasyonel (uzay) bir ortamda sistem prototip gösterimi Seviye 8 Gerçek sistem tamamlandı ve (uçuş) test ve gösteri yoluyla onaylandı 9. Seviye Başarılı görev operasyonları ile kanıtlanmış gerçek sistem (uçuş) (Yer ve Uzay) Sayfa 158 / 168 Machine Translated by Google Sözlük Şekil 7. Sistem Geliştirme Olgunluğu ile TRL İlişkisi Sayfa 159 / 168 Machine Translated by Google Sözlük Tablo 7. DoD Donanım ve Yazılım TRL Açıklamaları TL Donanım ve Yazılım Açıklamaları Seviye 1 En düşük teknoloji hazırlığı seviyesi. Araştırma, uygulamalı araştırma ve geliştirmeye dönüştürülmeye başlar. Örnekler, bir teknolojinin temel özelliklerine ilişkin kağıt üzerinde yapılan çalışmaları içerebilir. Seviye 2 Buluş başlar. Temel ilkeler gözlendikten sonra, pratik uygulamalar icat edilebilir. Başvurular spekülatiftir ve varsayımları destekleyecek hiçbir kanıt veya ayrıntılı analiz olmayabilir. Örnekler analitik çalışmalarla sınırlıdır. Seviye 3 Aktif araştırma ve geliştirme başlatılır. Bu, teknolojinin ayrı unsurlarının analitik tahminlerini fiziksel olarak doğrulamak için analitik çalışmaları ve laboratuvar çalışmalarını içerir. Örnekler, henüz entegre edilmemiş veya temsili olmayan bileşenleri içerir. Seviye 4 Temel teknolojik bileşenler, birlikte çalışacaklarını belirlemek için entegre edilmiştir. Bu, nihai sisteme kıyasla nispeten "düşük doğruluktur". Örnekler arasında "ad hoc" donanımın laboratuvara entegrasyonu yer alır. Seviye 5 Breadboard teknolojisinin doğruluğu önemli ölçüde artar. Temel teknolojik bileşenler, simüle edilmiş bir ortamda test edilebilmesi için oldukça gerçekçi destekleyici öğelerle entegre edilmiştir. Örnekler, bileşenlerin "yüksek doğrulukta" laboratuvar entegrasyonunu içerir. Seviye 6 TRL 5'in çok ötesinde temsili model veya prototip sistem ilgili ortamda test edilir. Bir teknolojinin kanıtlanmış hazır olma durumunda önemli bir adımı temsil eder. Örnekler, bir prototipin yüksek doğrulukta bir laboratuvar ortamında veya simüle edilmiş operasyonel ortamda test edilmesini içerir. Seviye 7 Prototip, planlanan operasyonel sistemin yakınında veya yakınında. Uçak, araç veya uzay gibi operasyonel bir ortamda gerçek bir sistem prototipinin gösterilmesini gerektiren TRL 6'dan büyük bir adımı temsil eder. Örnekler, prototipin bir test yatağı uçağında test edilmesini içerir. Level 8 Teknolojisinin nihai haliyle ve beklenen koşullarda çalıştığı kanıtlanmıştır. Çoğu durumda, bu TRL, gerçek sistem geliştirmenin sonunu temsil eder. Örnekler, özellikleri karşılayıp karşılamadığını belirlemek için sistemin amaçlanan silah sisteminde geliştirme testi ve değerlendirmesini içerir. 9. Seviye Operasyonel test ve değerlendirmede karşılaşılanlar gibi, teknolojinin nihai haliyle ve görev koşulları altında fiili uygulaması. Örnekler, sistemin operasyonel görev koşulları altında kullanılmasını içerir. izlenebilirlik İzlenebilirlik, gereksinim temel çizgisinin, işlevsel mimarinin, tahsis edilen temel hattın, tasarım yayın temel çizgisinin ve ürün konfigürasyon temel çizgisinin bir öğesini veya bunların karar veri tabanındaki temsilini ve bunların diğer herhangi bir öğeyle olan ilişkisini ilişkilendirme yeteneğidir. İzlenebilirlik doğası gereği iki yönlüdür: Aşağıya Doğru İzlenebilirlik: bir usta-ast veya ebeveynalt ilişkisinin olduğu durumlarda Yukarıya Doğru İzlenebilirlik: bir ast-ana veya alt-üst ilişkisinin olduğu durumlarda. Doğrulama Doğrulama, belirli bir amaçlanan kullanım veya uygulama için gerekliliklerin DoDI 5000.02'nin karşılandığının nesnel kanıt sağlanması yoluyla doğrulanmasıdır, örneğin: a. Nihai öğenin gerekli niteliklere sahip olduğunun, geliştirilmesinde gerekli varsayımların geçerli olduğunun (yani, müşteri tarafından kabul edilebilir) olduğunun ve ortaya çıkan sistem tasarımının etkinliğinin, sistem teknik gerekliliklerini ve kısıtlamalarını karşılanabilir bir şekilde karşılayabileceğinin gösterilmesi. Sayfa 160 / 168 Machine Translated by Google Sözlük B. EI veya ürün bileşeninin hedef ortamına yerleştirildiğinde kullanım amacını yerine getirdiğini gösterme süreci Doğrulama Doğrulama, belirtilen gerekliliklerin yerine getirildiğinin objektif kanıt sağlanması yoluyla doğrulanmasıdır [ISO 9000: 2000]. Bir ürünün doğrulanması, ürünün doğrulanmış tasarım ve performans temeline göre üretildiğini ve ürünün belirtilen gereksinimlerini karşıladığını gösterir. EI'nin tasarım veya üretim spesifikasyonunu karşıladığını doğrulayan süreçtir. Şelale Geliştirme Waterfall geliştirme, tüm gereksinimlerin başlangıçta bilindiği, gereksinimler, mimari, tasarım, uygulama, entegrasyon ve test faaliyetlerinin bu sırayla, muhtemelen geri bildirim ve örtüşme ile gerçekleştirdiği bir süreç ve yaşam döngüsü modelidir. Sayfa 161 / 168 Machine Translated by Google Bölüm II – Kısaltmalar diğer adıyla Ayrıca şöyle bilinir ABL Tahsis Edilen Temel BİR KEDİ Edinme Kategorisi AFOTEC AF Operasyonları Test ve Değerlendirme Merkezi AI Eylem ögesi AoA Alternatiflerin Analizi APB Edinme Programı Temeli ASR Alternatif Sistem İncelemesi AT Edinme Ekibi konşimento temel GSYİH Yakma Planı BL temel O OLDU Hayatın Başlangıcı C4I Komuta, Kontrol, İletişim, Bilgisayarlar ve İstihbarat Cıv Bağımsız Değişken Olarak Maliyet YÜKSEK Sözleşme İdare Ofisi KART Maliyet Analizi Gereksinimleri Açıklama CDD Yetenek Geliştirme Belgesi CDM Yüklenici Veri Kılavuzu CDR Kritik Tasarım İncelemesi CDRL Yüklenici Veri Gereksinim Listesi CD'ler Yüklenici Veri Sayfası ORADA Yapılandırma öğesi SANTİMETRE Konfigürasyon yönetimi CMMI Yetenek Olgunluk Modeli Entegrasyonu COMSEC İletişim Güvenliği CONOPS Operasyon Konsepti bebek karyolası CRD CSCI uzantısı Raftan Ticari Bitirme Gereksinimleri Belgesi Bilgisayar Yazılımı Kritik Öğesi CSDM Bilgisayar Sistemi Teşhis Kılavuzu DÜĞÜM Bilgisayar Sistemi Kullanım Kılavuzu CTE Kritik Teknoloji Elemanı CWBS Sözleşmeli İş Kırılım Yapısı ANCAK Savunma Tedarik Yönetmeliği ONLAR Doğrudan Bağlı Depolama Sayfa 162 / 167 Machine Translated by Google DDB Karar Veri Tabanı ORADA Savunma İstihbarat Teşkilatı DIACAP Savunma İstihbarat Değerlendirme Yeteneği YAPTI Veri Öğesi Açıklama DISR Savunma Bakanlığı Bilgi Standartları Deposu DMS Azalan Üretim Kaynağı DMSMS Azalan Üretim Kaynakları ve Malzeme Kıtlıkları DoDAF Savunma Bakanlığı Mimari Çerçevesi DT&E Geliştirme Testi ve Değerlendirmesi DUSD Savunma Müsteşar Yardımcısı eko Mühendislik Değişiklik Emri ED Mühendislik Geliştirme EDMO Mühendislik Veri Yönetimi Sorumlusu EESS HAYIR Çevresel Etkiler Stres Taraması Son madde EMC Elektromanyetik uyumluluk BEN Elektromanyetik girişim EOL Hayatın sonu EPDS Elektrik Güç Dağıtım Sistemi ES&OH Çevre Güvenliği ve İş Sağlığı ESD Elektrostatik Deşarj Kontrolü ESLOC Eşdeğer Kaynak Kod Satırları EVM Kazanılmış Değer Yönetimi F/A İmalat/Montaj UZAK Federal Satın Alma Yönetmeliği FBL İşlevsel Temel FCA İşlevsel Yapılandırma Denetimi FF&F Biçim, Uyum ve İşlev FFBD Fonksiyonel Akış Blok Şeması FFF&P Biçim, Uyum (uygunluk), İşlev ve Performans FFFP Biçim, Uyum, İşlev, Performans FMECA Arıza Modları, Etkileri ve Kritiklik Analizi FoS Sistem Ailesi FQR Resmi Yeterlilik İncelemesi CTP Tam Oranda Üretim FSM Üretici Yazılımı Destek Kılavuzu GFE Devlet Teçhizatı GİG Küresel Bilgi Tablosu Sayfa 163 / 167 Machine Translated by Google GOTS Raftaki Hükümet GSE Yer Destek Ekipmanı GUI Grafiksel kullanıcı arayüzü KONU Donanım Tahsis Listesi SAÇ Donanım Kabul İncelemesi HCI İnsan Bilgisayar Arayüzü HMMP Tehlikeli Maddeler Yönetim Planı HSI İnsan Sistemleri Entegrasyonu HW Donanım HWCI Donanım Yapılandırma Öğesi BT Kurulumlar ve Test EĞER Arayüz IA Bilgi Güvencesi IAW Uyarınca IB Endüstriyel Üs IBR Entegre Temel İnceleme ICD İlk Yetenekler Belgesi IMP Entegre Ana Plan İYS Entegre Ana Program Nesnelerin İnterneti ve E İlk Çalıştırma Testi ve Değerlendirmesi IPT Entegre Ürün Ekibi IRS Arayüz Gereksinimleri Spesifikasyonu ISO Uluslararası Standardizasyon Örgütü İSS Entegre Destek Planı ISR Hizmet İçi İnceleme BT Bilgi Teknolojisi ITR İlk Teknik İnceleme IV&V Bağımsız Doğrulama ve Validasyon KDP Kilit Karar Noktası KIP Anahtar Arayüz Profili KPP Temel Performans Parametresi LCC Yaşam Döngüsü Maliyeti LMI Lojistik Yönetimi Bilgileri LRIP Düşük Oranlı İlk Üretim HANIM Modelleme ve Simülasyon M/F/LRR Görev, Uçuş ve/veya Fırlatma Hazırlığı İncelemeleri M/PRR Üretim ve Ürün Hazırlığı İncelemesi MDA Dönüm Noktası Karar Otoritesi Sayfa 164 / 167 Machine Translated by Google BİN Askeri MLS Çok Düzeyli Güvenli MRL Üretim Hazırlık Düzeyleri MRL Malzeme İstek Listesi MRR Üretime Hazırlık İncelemesi MTBF Başarısızlık Arasındaki Ortalama Süre MTTR Tamir zamanı İÇİNDE Ağa Bağlı Depolama NCOW Ağ Merkezli Operasyonlar ve Harp NCOW-R Ağ Merkezli Operasyonlar ve Harp Referansı DIR-DİR Gelişimsel Olmayan Öğe NEPA Ulusal Çevre Politikası Yasası NR-KPP Ağa Hazır Anahtar Performans Parametresi NSS Ulusal Güvenlik Stratejisi UÇ Milli Teknoloji ve Sanayi Üssü AH Operasyonel Mimari OKB Operasyonel Yetenek Gösterimi OpsCon Operasyon Konsepti OSHA İş Sağlığı ve Güvenliği Yasası/Yönetim OT&E Operasyonel Test ve Değerlendirme OTRR Operasyonel Teste Hazırlık İncelemesi ÖTS Satışa hazır OV Operasyonel Görünüm PCA Fiziksel Yapılandırma Denetimi PCO Satınalma Sözleşme Sorumlusu PCR Fiziksel Yapılandırma İncelemesi PDR Ön Tasarım İncelemesi PEL İzin Verilen Maruz Kalma Seviyesi AĞIRLIK Program Odaklı Çevre, Güvenlik ve İş Sağlığı Değerlendirmesi PHS&T Paketleme, Taşıma, Depolama ve Taşınabilirlik PM&P Parçalar, Malzemeler ve Süreçler BİRAZ Bağlantı noktası PP Program Koruması SAGP Program Koruma Planı PRR Üretime Hazırlık İncelemesi PSP Ürün Destek Planı PWBS Program İş Kırılım Yapısı R&M Güvenilirlik ve Sürdürebilirlik Sayfa 165 / 167 Machine Translated by Google RAD İhtiyaç Tahsis Belgesi YAĞMA Yedekli Ucuz Disk Dizisi RAM&T Güvenilirliği, Kullanılabilirliği, Bakımı Yapılabilirliği ve Test Edilebilirliği RBL Gereksinimler Temeli RD&M Güvenilirliği, Güvenilirliği ve Sürdürebilirliği RFI Radyo Frekans Arayüzü RM Risk yönetimi RM&M Risk Yönetimi ve Azaltma RRDD Risk Azaltma ve Tasarım Geliştirme RTM Gereksinim İzlenebilirlik Matrisi RVTM Gereksinimleri Doğrulama İzlenebilirlik Matrisi B&T Bilim ve Teknoloji SAN Güvenlik Yardım Ağı SAR Yazılım Gereksinimi ve Mimari İncelemesi Süreç İyileştirme için SCAMPI Standart CMMI Değerlendirme Yöntemi SDD Sistem Geliştirme ve Demo SDP Yazılım Geliştirme Planı SEMP Sistem Mühendisliği Yönetim Planı EYLÜL Sistem Mühendisliği Planı SFR Sistem İşlevsel İncelemesi SGLS Uzaydan Yere Bağlantı Seti SGLS Uzaydan Yere Bağlantı Sistemi gömlek Kaynak Kod Satırları SMC Uzay ve Füze Sistemleri Merkezi Biz Konu uzmanı S.o.s Sistemler Sistemi EKMEK İş Bildirimi SPM Bilgisayar Programcısının El Kitabı DPT Sistem Program Ofisi SRDR-F Nihai Geliştirici Raporu ve Veri Sözlüğü SRDR-ı İlk Geliştirici Raporu ve Veri Sözlüğü SRR Sistem Gereksinimlerini İnceleme SRS Yazılım Gereksinimleri Spesifikasyonu SSA Depolama Sistemi Mimarisi SSE Sistem Güvenliği Mühendisliği STD Standart TOPLAM Yazılım Kullanım Kılavuzu SV Sistem Görünümü Sayfa 166 / 167 Machine Translated by Google SVR Sistem Doğrulama İncelemesi SW Yazılım ANAHTAR Yazılım Yapılandırma Öğesi T&E Test ve Değerlendirme kesin tarih Kararlı Olmak TBR Çözülecek TBS Tedarik Edilecek TD Teknoloji Geliştirme ve/veya Teknoloji Gösterimi TDP Teknoloji Geliştirme Aşaması TDP Teknik Veri Paketi SICAKLIK Test ve Değerlendirme Master Planı görev tanımı Teknik İşletme Raporu TPM Teknik Performans Ölçümü ARASINDA Teknoloji Hazırlık Değerlendirmesi TRC Teknik İnceleme Kriterleri TRD Teknik Gereksinimler Belgesi TL Teknoloji Hazırlık Düzeyi TR Test Hazırlığı İncelemesi televizyon Teknik Görünüm ABD Hava Kuvvetleri Birleşik Devletler Hava Kuvvetleri V&V Doğrulama ve onaylama VCRM Doğrulama Çapraz Referans Matrisi WBS İş Kırılım Yapısı Sayfa 167 / 167 Machine Translated by Google Machine Translated by Google SMC Standardı İyileştirme Önerisi TALİMATLAR 1. 1'den 7'ye kadar blokları tamamlayın. Tüm bloklar tamamlanmalıdır. 2. Blok 8'de belirtilen Hazırlama Aktivitesine gönderin. NOT: Belgelerin kopyalarını talep etmek veya feragat talep etmek veya mevcut sözleşmelerdeki gereksinimlerin açıklığa kavuşturulmasını talep etmek için kullanmayın. Bu formda gönderilen yorumlar, atıfta bulunulan belgenin/belgelerin herhangi bir kısmından feragat etme veya sözleşme gerekliliklerini değiştirme yetkisini teşkil etmez veya ima etmez. Bu forma gönderilen yorumlar, Hazırlama Faaliyetinin öneriyi uygulama taahhüdünü teşkil etmez; Hazırlayan Otorite, yorumun gözden geçirilmesini koordine edecek ve Blok 6'da belirtilen yorumu gönderene düzenleme sağlayacaktır. SMC STANDARDI 2. Belge Tarihi 1. Belge Numarası DEĞİŞTİRMEK ÖNERİ: 3. Belge Başlığı 4. Değişikliğin Doğası (Paragraf numarasını belirleyin; önerilen revizyon dilini ve destekleyici verileri ekleyin. Gerektiğinde fazladan sayfalar ekleyin.) 5. Tavsiye Nedeni 6. Gönderici Bilgileri A. İsim B. organizasyon C. Adres D. Telefon e. e-posta adresi 7. Gönderim Tarihi 8. Hazırlık Etkinliği Uzay ve Füze Sistemleri Merkezi HAVA KUVVETLERİ UZAY KOMUTANLIĞI 483 N. Aviation Blvd. El Segundo, CA 91245 Dikkat: SMC/EAE Mart 2008

ADA633324 (1)

Products

Support

ADA633324 (1)

Add this document to collection(s)

Add this document to saved

Suggest us how to improve StudyLib