Not : Bu yazı ile ilgili olarak CMMI başlıklı yazıyı okuyabilirsiniz.
MIL-STD-498
Savunma sanayimizin öncü kuruluşlarından olduğunu iddia eden bir çok firmada kullanılan yazılım geliştirme standardı MIL-STD-498. Vakti zamanında (1994 yılında) başlatılan bu standart 1998 yılında iptal edilmiş olmasına rağmen, maalesef iç piyasamızda halen kullanım görmekte. Bu sürecin yerini IEEE 12207 aldı. IEEE 12207, daha fazla yaşam döngüsü odaklı.
Sürecin ne kadar High Ceremony ( ki bence hantal kelimesinin daha kibarca söylenmiş hali ) olduğunu gösteren bir şekli buradan aldım.
Süreç boyunca üretilen bazı dokümanları gösteren bir şekli ise buradan aldım.
Her ne kadar yukarıdaki şekilde iterative (tekrarlamalı/yinelemeli) yaklaşımdan bahsedilse bile hiç bir zaman kullanıldığına şahit olmadım.
2012 yılında bile yazılımların şelale modelinde geliştirilmesine sebep olan bu süreci kullanmaya devam eden (bir doküman bir kere onaylanınca kimse geriye dönüp onunla bir daha oynamak istemiyor, dolayısıyla ister istemez şelale yöntemine doğru kayılıyor) firmaları anlayamıyorum !
Türk Silahlı Kuvvetlerini Güçlendirme Vakfı firmaları (Aselsan, Roketsan, Havelsan, İşbir, Aspilsan) sırtlarını vakfa dayadıkları için ticari kaygıları diğer firmalara göre daha az. Ancak vakıfın iştiraki olmayan ticari müesseselerin bu hantal model ile esnekliklerini kaybetmelerine rağmen, ısrarla bu alışkanlıktan vazgeçmemeleri bence çok yazık !.
Data Item Description (DID)
DID üretilmesi beklenen belge anlamında düşünülebilir. MIL-STD-498 tam 22 tane DID tanımlıyor. Her DID'in içeriği ve şekli belirli. Her ne kadar belgenin şeklini değiştirmek mümkün olsa da, tüm DID'lerin gerçekten işe yaradığını söyleyebilmek ve hakkını vererek yazıldığını söyleyebilmek çok zor. Bu DID'lerden hangilerinin müşteriye teslim edileceği, CDRL belgesinden tanımlanır.
Bazı Kelimeler ve Türkçeleri
SDP : Software Development Plan
SDP içinde genellikle aşağıdakine benzer başlıklar olur.
1. Scope
2. Referenced Documents
3. Project Organization
4. Work Packages, Schedule and Budget
5. Notes
Daha detaylı yazılmak istenirse aşağıdaki başlıklar olur
1. Scope
2. Referenced Documents
3. Overview of Required Work
4. Plans for Performing General Software Development
5. Plans for Performing Detailed Software Development
5.1 Project Planning and Oversight
5.2 Establishing a Software Development Environment
5.3 System Requirements Analysis
5.4 System Design
5.5 Software Requirements Analysis
5.6 Software Design
5.7 Software Implementation and Unit Testing
5.8 Unit Integration Testing
5.9 CSCI Qualification Testing
5.10 System Integration Testing
5.11 System Qualification Testing
5.12 Software Use
5.13 Software Transition
5.14 Software Configuration Management
5.15 Software Product Evaluation
5.16 Software Quality Assurance
5.17 Problem Resolution
5.18 Joint Technical and Management Reviews
5.19 User Training
5.20 Othe Software Development Activities
6. Schedules and Activities
7. Project Organization and Resources
8. Compliance Matrix
9 Notes
CSCI : Computer Software Configuration Item. Official definition of CSCI (Computer Software Configuration Item) başlılı soruya göz atılabilir. Aselsan'da Yazılım Konfigürasyon Birimi (YKB) kelimesi kullanılıyor. Kabaca geliştirilen uygulama anlamına geliyor. Bir proje altında birden fazla uygulama olabilir Her CSCI CSC'lerden oluşur. Her CSCI için SRS ve SDD gerekir.
ICD : Interface Control Document
Genellikle elektriksel arayüzler için kullanılır. Ancak bazen yazılım arayüzleri için hazırlanan belgelere de Software ICD deniliyor. ICD formatı, işlenmek için Engineering formatına dönüştürülür.
IDD : Interface Design Document
Yazılım arayüzünü belirten belge.
Sözleşme : Kontrat, Tender Document gibi isimlerle anılır. Sözleşme bir çok eklerden oluşabilir. Bir çok gereksinimim, çıkış noktası sözleşme ve ekleridir.
ECP: Engineering Change Proposal. Mühendislik Değişikliği Önerisi. Sözleşme kapanmadan yapılan değişikliği belirtir. ECP'ler ECP-1, ECP-2 olarak adlandırılır. Toplantı tutanağıyla kayıt altına alınır.
MKN : Mühendislik Koordinasyon Notu
SRS :
Software Requirements Specification başlıklı yazıya taşıdım.
SSDD: System/Subsytem Design Document
SSDD içinde genellikle aşağıdakine benzer başlıklar olur.
1. Scope
2. Referenced Documents
3. System-Wide Design Decisions
3.1 General Design Decisions - Buraya her türlü şey yazılabilir. Kullanılacak dosya formatından, sembolojiye, programlama diline ve metodolojiye kadar ilgili ilgisiz her şey belirtilebilir.
3.2 Software Architecture - The system shall be based on X (e.g J2EE) architecture. Eğer herhangi bir referans mimari kullanılmıyorsa, mimarinin modüler ve katmanlı olduğu yazılabilir. Sebep olarak ta çok katmanlı mimarinin (multi-layered) kohezyonu (cohesion) artırdığı ve coupling'i azalttığı, böylece test edilebilir ve idame ettirilebilir bir yazılım olduğu belirtilebilir.
3.2 Fault Management - The system shall provide hardware level redundancy.
4. System Architectural Design
4.1 System Components
4.1.1 Hardware Architectural Design
4.1.2 Software Architectural Design - Bu kısma "Open Architecture" kullanıldığı, yazılımın katmanlardan oluştuğu yazılabilir. Yazılım katmanları bir şekil ile gösterilebilir. Örneğin şekilde en alta ara katman/iletişim katmanı konulur. Üstüne "ortak işlevler", daha üste "ortak servisler", en üste ise modüller konulur.
4.2 Concept of Execution - Concept of Execution sistemin ana bileşenleri arasındaki etkileşimi göstermek amacıyla UML Sequence diagramları ile gösterilebilir. Bu kısma alternatif akışları koymak gereksizdir.
4.3 Interface Design
5. Requirements Traceability (SSS -> SSDD arasındaki izlenebilirlik)
6. Notes
SDD : Konuyu SDD başlıklı yazıya taşıdım.
CDR : Critical Design Review. Kritik Tasarım Gözden Geçirme cümlesi kullanılabilir. Yukarıdaki şekilde gösterilmese de SDD dokümanı hazırlandıktan sonra tasarımın geliştirme için yeterli olgunluğa ulaştığının teyit edildiği aşama. Örnek olarak Altay tankı CDR'ına veya SM-3 CDR'ına bakılabilir.
Aşağıdaki cümle olgunluğa dikkat edilmesi gerektiğini vurguluyor.
CDR aşamasında gelmeden önce bir prototip yapmak ve müşteri ile paylaşmak gerekir. Aşağıdaki cümleler, prototiplemenin CDR aşamasına gelmeden bitmiş olması gerektiğini belirtiyor. Yani tüm alt sistemler bitmese bile, kritik olanlar en azından test edilmiş ve tümleştirilmiş olmalı.
CDR'dan kısa bir süre sonra örneğin CDR +1 gibi bir ayda ön entegrasyona başlanması iyi olabilir.
Bazı projeler hedeflerinden saptıklarında, CDR eklenmesi/çıkarılması düşünülen işlevlerin konuşulduğu, alternatif takvim ve maliyet seçeneklerinin konuşulduğu bir toplantıya dönüşüyor.
UTD : Unit Test Description. SDD'de tanımlı olan yazılım bileşenleri ve birim testleri arasındaki ilişkiyi içerir. Örneğin MyCSCI altındaki MyComponent altındaki Function1 için yazılan birim testler şunlardır diye bir tablo şeklinde tutulabilir.
STP : Software Test Plan. Aselsan'da Yazılım Test Planı (YTEP) kelimesi kullanılıyor. Genellikle proje müdürleri tarafından laf olsun torba dolsun mantığıyla yazılan testlerin koşturulması için kullanılacak araç, gereken ortam, kaynaklar vs. gibi konuları açıklayan doküman.
STD :
Software Test Document başlıklı yazıya taşıdım.
STR : Software Test Report. Aselsan'da Yazılım Test Raporu (YTER) kelimesi kullanılıyor. Koşturulan testler ve sonuçlarını gösteren rapor.
Kısaltmalardan sonra akışa bir göz atacak olursak aşağıdakine benzer bir silsile izleniyor. Aşamalar projelere göre farklı isimler alabiliyor. Farklı yöntemler de izlenebilir. Sadece örnek olsun diye yazıyorum.
Belgelerde Kullanılan Gizlilik Seviyeleri
Çok Gizli -> Top Secret
Gizli -> Secret
Özel -> Confidential
Hizmete Özel -> Restricted
Tasnif Dışı -> Unclassified
----------------------------------------------------------------------------------------------------
T0 (Proje Başlangıcı) --> Genellikle bir avans alınır.
SRR (System Requirements Review. Türkçesi Sistem Gereksinimleri Gözden Geçirme Toplantısı)
Sistem gereksinimlerinin ortaya konulduğu aşama
SRR'da teslim edilen bazı belgeler şunlar.
PDR (Preliminary Design Review. Türkçesi Ön Tasarım Gözden Geçirme Toplantısı)
Ön Tasarım yapıldıktan sonra gelinen aşama. PDR'da teslim edilen bazı belgeler şunlar.
Müşteri ile gerçek PDR toplantısı yapmadan önce, ekip içinde çatlak ses çıkmaması için bir prova yapılmasında fayda var.
Bu aşamada yazılım gereksinimleri doğrulanır. PDR genellikle ödeme kilometre taşıdır. Bazen seçilen donanımın onayı da bu aşamada verilir. Projenin %25-30 arası bedeli bu kilometre taşı geçildikten sonra ödenir. Dolayısıyla güvenilirlik ve maddi açıdan önemlidir. PDR tamanlanınca ve açık işlem maddeleri kapatılınca, resmi yazı ile PDR'ın başarı ile tamamlandığı bildirilir.
CDR (Critical Design Review. Türkçesi Kritik Tasarım Gözden Geçirme Toplantısı)
Müşteri ile gerçek CDR toplantısı yapmadan önce, ekip içinde çatlak ses çıkmaması için bir prova yapılmasında fayda var.
Bazı projelerde CDR aşamasında artık nihai karar verildiği için sistemle/yazılımla ilgili ölçümler verilebilir veya talep edilebilir.
Development -->
FAT Dry Run (Fabrika Kabul Test Provası) -->
FAT (Fabrika Kabul Test) : Fabrika/Laboratuvar ortamında yapılan test provası --> Tüm paydaşların hazır olduğu noktada başlanabilir. Geciken bir paydaş, tüm takvimi öteleyebilir.
FAT-SYS, SEL vs. gibi farklı isimler olan bir aşama : Bu aşamada tüm sistem bir araya getirilerek gerçek sensörler simüle ediliyorlar. Bu aşamaya projesine göre farklı isimler veriliyor.-->
HAT : Eğer gerekiyorsa gerçek sensörlerin kullanıldığı aşama -->
SAT (Örneğin geminin denize açılıp test yapması veya mevzide test yapılması). SAT testleri genelde stresli olurlar. Bu aşamada konu başlıklarına göre testlerin yapılması işleri hızlandırabilir.
Donanım Tederaik Aşaması:
Önce RFQ (Request for Quote) istenir. RFQ yanıtları sonrası BAFO (Best and Final Offer)
MIL-STD-498
Savunma sanayimizin öncü kuruluşlarından olduğunu iddia eden bir çok firmada kullanılan yazılım geliştirme standardı MIL-STD-498. Vakti zamanında (1994 yılında) başlatılan bu standart 1998 yılında iptal edilmiş olmasına rağmen, maalesef iç piyasamızda halen kullanım görmekte. Bu sürecin yerini IEEE 12207 aldı. IEEE 12207, daha fazla yaşam döngüsü odaklı.
Sürecin ne kadar High Ceremony ( ki bence hantal kelimesinin daha kibarca söylenmiş hali ) olduğunu gösteren bir şekli buradan aldım.
Süreç boyunca üretilen bazı dokümanları gösteren bir şekli ise buradan aldım.
2012 yılında bile yazılımların şelale modelinde geliştirilmesine sebep olan bu süreci kullanmaya devam eden (bir doküman bir kere onaylanınca kimse geriye dönüp onunla bir daha oynamak istemiyor, dolayısıyla ister istemez şelale yöntemine doğru kayılıyor) firmaları anlayamıyorum !
Türk Silahlı Kuvvetlerini Güçlendirme Vakfı firmaları (Aselsan, Roketsan, Havelsan, İşbir, Aspilsan) sırtlarını vakfa dayadıkları için ticari kaygıları diğer firmalara göre daha az. Ancak vakıfın iştiraki olmayan ticari müesseselerin bu hantal model ile esnekliklerini kaybetmelerine rağmen, ısrarla bu alışkanlıktan vazgeçmemeleri bence çok yazık !.
Data Item Description (DID)
DID üretilmesi beklenen belge anlamında düşünülebilir. MIL-STD-498 tam 22 tane DID tanımlıyor. Her DID'in içeriği ve şekli belirli. Her ne kadar belgenin şeklini değiştirmek mümkün olsa da, tüm DID'lerin gerçekten işe yaradığını söyleyebilmek ve hakkını vererek yazıldığını söyleyebilmek çok zor. Bu DID'lerden hangilerinin müşteriye teslim edileceği, CDRL belgesinden tanımlanır.
Bazı Kelimeler ve Türkçeleri
SDP : Software Development Plan
SDP içinde genellikle aşağıdakine benzer başlıklar olur.
1. Scope
2. Referenced Documents
3. Project Organization
4. Work Packages, Schedule and Budget
5. Notes
Daha detaylı yazılmak istenirse aşağıdaki başlıklar olur
1. Scope
2. Referenced Documents
3. Overview of Required Work
4. Plans for Performing General Software Development
5. Plans for Performing Detailed Software Development
5.1 Project Planning and Oversight
5.2 Establishing a Software Development Environment
5.3 System Requirements Analysis
5.4 System Design
5.5 Software Requirements Analysis
5.6 Software Design
5.7 Software Implementation and Unit Testing
5.8 Unit Integration Testing
5.9 CSCI Qualification Testing
5.10 System Integration Testing
5.11 System Qualification Testing
5.12 Software Use
5.13 Software Transition
5.14 Software Configuration Management
5.15 Software Product Evaluation
5.16 Software Quality Assurance
5.17 Problem Resolution
5.18 Joint Technical and Management Reviews
5.19 User Training
5.20 Othe Software Development Activities
6. Schedules and Activities
7. Project Organization and Resources
8. Compliance Matrix
9 Notes
CSCI : Computer Software Configuration Item. Official definition of CSCI (Computer Software Configuration Item) başlılı soruya göz atılabilir. Aselsan'da Yazılım Konfigürasyon Birimi (YKB) kelimesi kullanılıyor. Kabaca geliştirilen uygulama anlamına geliyor. Bir proje altında birden fazla uygulama olabilir Her CSCI CSC'lerden oluşur. Her CSCI için SRS ve SDD gerekir.
ICD : Interface Control Document
Genellikle elektriksel arayüzler için kullanılır. Ancak bazen yazılım arayüzleri için hazırlanan belgelere de Software ICD deniliyor. ICD formatı, işlenmek için Engineering formatına dönüştürülür.
IDD : Interface Design Document
Yazılım arayüzünü belirten belge.
Sözleşme : Kontrat, Tender Document gibi isimlerle anılır. Sözleşme bir çok eklerden oluşabilir. Bir çok gereksinimim, çıkış noktası sözleşme ve ekleridir.
ECP: Engineering Change Proposal. Mühendislik Değişikliği Önerisi. Sözleşme kapanmadan yapılan değişikliği belirtir. ECP'ler ECP-1, ECP-2 olarak adlandırılır. Toplantı tutanağıyla kayıt altına alınır.
MKN : Mühendislik Koordinasyon Notu
SRS :
Software Requirements Specification başlıklı yazıya taşıdım.
SSDD: System/Subsytem Design Document
SSDD içinde genellikle aşağıdakine benzer başlıklar olur.
1. Scope
2. Referenced Documents
3. System-Wide Design Decisions
3.1 General Design Decisions - Buraya her türlü şey yazılabilir. Kullanılacak dosya formatından, sembolojiye, programlama diline ve metodolojiye kadar ilgili ilgisiz her şey belirtilebilir.
3.2 Software Architecture - The system shall be based on X (e.g J2EE) architecture. Eğer herhangi bir referans mimari kullanılmıyorsa, mimarinin modüler ve katmanlı olduğu yazılabilir. Sebep olarak ta çok katmanlı mimarinin (multi-layered) kohezyonu (cohesion) artırdığı ve coupling'i azalttığı, böylece test edilebilir ve idame ettirilebilir bir yazılım olduğu belirtilebilir.
3.2 Fault Management - The system shall provide hardware level redundancy.
4. System Architectural Design
4.1 System Components
4.1.1 Hardware Architectural Design
4.1.2 Software Architectural Design - Bu kısma "Open Architecture" kullanıldığı, yazılımın katmanlardan oluştuğu yazılabilir. Yazılım katmanları bir şekil ile gösterilebilir. Örneğin şekilde en alta ara katman/iletişim katmanı konulur. Üstüne "ortak işlevler", daha üste "ortak servisler", en üste ise modüller konulur.
4.2 Concept of Execution - Concept of Execution sistemin ana bileşenleri arasındaki etkileşimi göstermek amacıyla UML Sequence diagramları ile gösterilebilir. Bu kısma alternatif akışları koymak gereksizdir.
4.3 Interface Design
5. Requirements Traceability (SSS -> SSDD arasındaki izlenebilirlik)
6. Notes
SDD : Konuyu SDD başlıklı yazıya taşıdım.
CDR : Critical Design Review. Kritik Tasarım Gözden Geçirme cümlesi kullanılabilir. Yukarıdaki şekilde gösterilmese de SDD dokümanı hazırlandıktan sonra tasarımın geliştirme için yeterli olgunluğa ulaştığının teyit edildiği aşama. Örnek olarak Altay tankı CDR'ına veya SM-3 CDR'ına bakılabilir.
Aşağıdaki cümle olgunluğa dikkat edilmesi gerektiğini vurguluyor.
"The CDR verified that the missile's design will meet the stringent, specific operational performance requirements necessary to defeat the projected threats."
CDR aşamasında gelmeden önce bir prototip yapmak ve müşteri ile paylaşmak gerekir. Aşağıdaki cümleler, prototiplemenin CDR aşamasına gelmeden bitmiş olması gerektiğini belirtiyor. Yani tüm alt sistemler bitmese bile, kritik olanlar en azından test edilmiş ve tümleştirilmiş olmalı.
The SM-3 Block IIA program plan included building hardware early, supporting completion of critical subsystem testing prior to CDR. This "hardware rich" approach coupled with the design commonality with previous versions of SM-3 reduces integration risk.
CDR'dan kısa bir süre sonra örneğin CDR +1 gibi bir ayda ön entegrasyona başlanması iyi olabilir.
Bazı projeler hedeflerinden saptıklarında, CDR eklenmesi/çıkarılması düşünülen işlevlerin konuşulduğu, alternatif takvim ve maliyet seçeneklerinin konuşulduğu bir toplantıya dönüşüyor.
UTD : Unit Test Description. SDD'de tanımlı olan yazılım bileşenleri ve birim testleri arasındaki ilişkiyi içerir. Örneğin MyCSCI altındaki MyComponent altındaki Function1 için yazılan birim testler şunlardır diye bir tablo şeklinde tutulabilir.
STP : Software Test Plan. Aselsan'da Yazılım Test Planı (YTEP) kelimesi kullanılıyor. Genellikle proje müdürleri tarafından laf olsun torba dolsun mantığıyla yazılan testlerin koşturulması için kullanılacak araç, gereken ortam, kaynaklar vs. gibi konuları açıklayan doküman.
STD :
Software Test Document başlıklı yazıya taşıdım.
STR : Software Test Report. Aselsan'da Yazılım Test Raporu (YTER) kelimesi kullanılıyor. Koşturulan testler ve sonuçlarını gösteren rapor.
Kısaltmalardan sonra akışa bir göz atacak olursak aşağıdakine benzer bir silsile izleniyor. Aşamalar projelere göre farklı isimler alabiliyor. Farklı yöntemler de izlenebilir. Sadece örnek olsun diye yazıyorum.
Belgelerde Kullanılan Gizlilik Seviyeleri
Çok Gizli -> Top Secret
Gizli -> Secret
Özel -> Confidential
Hizmete Özel -> Restricted
Tasnif Dışı -> Unclassified
----------------------------------------------------------------------------------------------------
T0 (Proje Başlangıcı) --> Genellikle bir avans alınır.
SRR (System Requirements Review. Türkçesi Sistem Gereksinimleri Gözden Geçirme Toplantısı)
Sistem gereksinimlerinin ortaya konulduğu aşama
SRR'da teslim edilen bazı belgeler şunlar.
SSS : System/Subsystem Specification
PDR (Preliminary Design Review. Türkçesi Ön Tasarım Gözden Geçirme Toplantısı)
Ön Tasarım yapıldıktan sonra gelinen aşama. PDR'da teslim edilen bazı belgeler şunlar.
SSDD : System/Subsystem Design DocumentNot : PDR'dan önce bu belgelerde izlenebilirlik (traceability ) bilgisinin olması, gözden geçirilmiş olup, baseline yapılmış olması gerekir. Baseline (anahat) için bazen aşağıdaki kelimeler de kullanılır.
SRS : Software Requirements Specification
ICD : Interface Control Document
Functional Baseline (SSS)
Allocated Baseline (SRS,IRS)
Design Baseline (SSDD,SDD)
Product Baseline (Nihai ürün)
Müşteri ile gerçek PDR toplantısı yapmadan önce, ekip içinde çatlak ses çıkmaması için bir prova yapılmasında fayda var.
Bu aşamada yazılım gereksinimleri doğrulanır. PDR genellikle ödeme kilometre taşıdır. Bazen seçilen donanımın onayı da bu aşamada verilir. Projenin %25-30 arası bedeli bu kilometre taşı geçildikten sonra ödenir. Dolayısıyla güvenilirlik ve maddi açıdan önemlidir. PDR tamanlanınca ve açık işlem maddeleri kapatılınca, resmi yazı ile PDR'ın başarı ile tamamlandığı bildirilir.
CDR (Critical Design Review. Türkçesi Kritik Tasarım Gözden Geçirme Toplantısı)
Müşteri ile gerçek CDR toplantısı yapmadan önce, ekip içinde çatlak ses çıkmaması için bir prova yapılmasında fayda var.
Bazı projelerde CDR aşamasında artık nihai karar verildiği için sistemle/yazılımla ilgili ölçümler verilebilir veya talep edilebilir.
Development -->
FAT Dry Run (Fabrika Kabul Test Provası) -->
FAT (Fabrika Kabul Test) : Fabrika/Laboratuvar ortamında yapılan test provası --> Tüm paydaşların hazır olduğu noktada başlanabilir. Geciken bir paydaş, tüm takvimi öteleyebilir.
FAT-SYS, SEL vs. gibi farklı isimler olan bir aşama : Bu aşamada tüm sistem bir araya getirilerek gerçek sensörler simüle ediliyorlar. Bu aşamaya projesine göre farklı isimler veriliyor.-->
HAT : Eğer gerekiyorsa gerçek sensörlerin kullanıldığı aşama -->
SAT (Örneğin geminin denize açılıp test yapması veya mevzide test yapılması). SAT testleri genelde stresli olurlar. Bu aşamada konu başlıklarına göre testlerin yapılması işleri hızlandırabilir.
Donanım Tederaik Aşaması:
Önce RFQ (Request for Quote) istenir. RFQ yanıtları sonrası BAFO (Best and Final Offer)
Hiç yorum yok:
Yorum Gönder