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.
Örnek Proje Takvimi
Bazı Kelimeler ve Türkçeleri
SDP : Software Development Plan
SDP başlıklı yazıya göz atabilirsiniz.
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.
CSCI versiyon numaraları genellikle X.Y.Z (Major.Minor.Patch) şeklinde verilir. Açıklaması ise aşağıda.
ICD : Interface Control Document. Yazılım Arayüzü başlıklı yazıya göz atabilirsiniz.
IDD : Interface Design Document. Yazılım Arayüzü başlıklı yazıya göz atabilirsiniz.
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
FAR : Fault Analysis Report
SRS :
Software Requirements Specification başlıklı yazıya taşıdım.
SSDD: System/Subsytem Design Document
SSDD başlıklı yazıya taşıdım.
SDD :
SDD başlıklı yazıya taşıdım.
SBM : Software Build Manual. CM tarafından adım adım takip edilerek doğrulanır. Bazı şirketler SBM belgesinde izlenebilirlik istiyorlar. Ayrıca SBM gözden geçirilir ve yayınlanır.
CDR :
CDR başlıklı yazıya taşıdım.
UITD : Unit Integration Test Description
UTD :
Unit Test Description başlıklı yazıya taşıdım.
STP :
Software Test Plan başlıklı yazıya taşıdım.
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.
PDR'ı takiben CDR yapılır.
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 -->
Bir çok farklı test kademesi kullanmak faydalı. Özellikle pahalı donanımların olduğu projelerde gerçek donanıma gelmeden önce mümkün olduğunda simülatör, emülatörlerle testler koşturmak gerekir.
Ön Entegrasyon : FAT testinden önce yapılan tümleşim testi. Sistemi daha küçük parçalar halinde birleştirmek için kullanılır. Ön entegrasyon testinden önce kod için ayrı bir branch açmak iyi bir fikir olabilir. Geliştirme devam ederken, testte çıkan hatalar da branch üzerinde düzeltilebilir. Ön entegrasyon testi bittikten sonra tutanak tutulur.
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.-->
Konuyu FAT Testi yazısına taşıdım.
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.
Örnek Proje Takvimi
- Proje Başlangıcı : T0
- SRR (Sistem Gereksinimlerini Gözden Geçirme Toplantısı) : T0 + 3
- PDR (Ön Tasarım Gözden Geçirme Toplantısı) : T0 + 6
- CDR (Kritik Tasarım Gözden Geçirme Toplantısı) : T0 + 8
- Ön Entegrasyon 1 : T0 + 10
- Ön Entegrasyon 2 : T0 + 13
- FAT : T0 + 19
- Kesin Kabul : T0 + 27
Bazı Kelimeler ve Türkçeleri
SDP : Software Development Plan
SDP başlıklı yazıya göz atabilirsiniz.
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.
CSCI versiyon numaraları genellikle X.Y.Z (Major.Minor.Patch) şeklinde verilir. Açıklaması ise aşağıda.
Bug fixes not affecting the API increment the patch version, backwards compatible API additions/changes increment the minor version, and backwards incompatible API changes increment the major version.
ICD : Interface Control Document. Yazılım Arayüzü başlıklı yazıya göz atabilirsiniz.
IDD : Interface Design Document. Yazılım Arayüzü başlıklı yazıya göz atabilirsiniz.
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
FAR : Fault Analysis Report
SRS :
Software Requirements Specification başlıklı yazıya taşıdım.
SSDD: System/Subsytem Design Document
SSDD başlıklı yazıya taşıdım.
SDD :
SDD başlıklı yazıya taşıdım.
SBM : Software Build Manual. CM tarafından adım adım takip edilerek doğrulanır. Bazı şirketler SBM belgesinde izlenebilirlik istiyorlar. Ayrıca SBM gözden geçirilir ve yayınlanır.
CDR :
CDR başlıklı yazıya taşıdım.
UITD : Unit Integration Test Description
UTD :
Unit Test Description başlıklı yazıya taşıdım.
STP :
Software Test Plan başlıklı yazıya taşıdım.
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.
PDR'ı takiben CDR yapılır.
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 -->
Bir çok farklı test kademesi kullanmak faydalı. Özellikle pahalı donanımların olduğu projelerde gerçek donanıma gelmeden önce mümkün olduğunda simülatör, emülatörlerle testler koşturmak gerekir.
Ön Entegrasyon : FAT testinden önce yapılan tümleşim testi. Sistemi daha küçük parçalar halinde birleştirmek için kullanılır. Ön entegrasyon testinden önce kod için ayrı bir branch açmak iyi bir fikir olabilir. Geliştirme devam ederken, testte çıkan hatalar da branch üzerinde düzeltilebilir. Ön entegrasyon testi bittikten sonra tutanak tutulur.
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.-->
Konuyu FAT Testi yazısına taşıdım.
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)
Beğenmediğiniz savunma sanayii firmalarından birinde çalışan bir mühendis olarak eleştirilerinize cevap vermeye çalışacağım:
YanıtlaSil- MIL-STD-498 her ne kadar hantal bir yapı sunsa da hemen hemen her mil std'da olduğu gibi istediğiniz gibi kısıtlayıp-genişletmek (tailoring) elinizde. Ben özellikle standarttaki bazı doküman formatlarını (SSS,SSDD, IRS, IDD vs) çok beğenmekle birlikte bazılarını da kullanışsız buluyorum. Şirketimizde de bu dokümanların formatlarını içselleştrdikten sonra süreçlerimize ekleyerek tasarım sürecinde kullanılmasını şart koyduk. (Avusturalya'lı birinden de ülkelerinde aynısını yaptıını dinlemiştim). Bunu yaparken farklı ülkelerin kullandıkları standartları ve projeleri de inceledik ve dokümanların içeriklerini yeterli bulduk.
Şimdi gelelim ikinci eleştirinize, savunma sanayi firmalarının sırtını devlete dayadığına. Bunu benim farklı şirketlerde çalışan arkadaşlarım da söylerler. Bu arkadaşlarımdan biriyle başımızdan geçen bir anıyı kısaca anlatmak isterim. Yabancı ve sektörde lider firmalardan birini çağırdık. Adamlar geldiler ve birkaç Türk firmasının bulunduğu bir toplantıda ürünlerini tanıttılar. Bizim firmadan bir grup devamlı sorular sordu, sorular genelden çok işin detaylarına yönelikti. Bizimkiler sordukça adam da bizimkilere siz nasıl yapıyorsunuz diye sormaya başladı :). Ara verildi, arkadaşım sizin bu konuda çalışmanız var mı dedi. Bizim mühendisler ürünün şu parçasının 5 değişik kapasitede olanını tasarladık, şu projelerde kullandık, şimdi de en büyük kapasitelisini tasarlıyoruz dediler , bir başka parçasını da yurtdışına tasarlatıyoruz, bir taraftan da yerli bir firmada yerlileştirme çalışmalarımız sürüyor diye cevap verdi. Ben de arkadaşıma dönüp, "anladın mı devletin bize proje verme sebebini" dedim. Yani kısaca bizde yabancı ülkeden alabileceğin ürününün yerlisi çoktan tasarlanmıştı. Burada devletin iki seçeneği var, ya yurt dışına giderek vergilerimizi çarçur eder (ki bazen yapıyorlar, bakınız otoyol geçiş sistemi projesi-şu anda Polonya bile Türkiye'den OGS diye bilinen sistemi alırken, Türkiye yabancı bir firmanın Türkiye temsilcisi üzerinden HGS sistemi almıştır), ya da gelir bizden alır.
Son olarak size birilerini/birşeyleri tamamen kötülemeden önce iyi yanlarını görmenizi ve takdir etmenizi, kötü yanlarını da yapıcı bir üslupla eleştirmenizi öneririm. Unutmayınız ki bu ülkede araba ve uçak fabrikaları kapatılmamış olsaydı belki bugün Türk arabalarına binip Türk uçaklarında uçuyor olabilirdik.
Merhaba, Mühendisler süreçleri seçmezler. Sürece uyarlar. Mühendisleri eleştiren bir yazı değil bu. Kurumlara ve kısmen de olsa artık ortadan kalkmış bir süreci takip etmelerine eleştiri var. İlginiz için teşekkürler.
YanıtlaSilMühendislerin uyacağı süreçleri kim seçer diye sorsam? Açıkça söylemek gerekirse "süreç seçme" benim çok da onaylamadığım bir cümle. Elma, armut mu bu? Şöyle ifade etmek daha doğru olur: Kurumlar kendi yapılarına uygun bir süreci belirleyip, bunu kendi iç yapılarına en uygun şekle getirerek uygulamaya alırlar. Bu işlemi de tabi ki sürecin kullanımını en iyi bilen tecrübeli mühendislerden başkasının yapmasından daha doğal olan şey nedir ki?
SilBizim kullandığımız süreçler de aynen bu şekilde çeşitli standartarın birleştirilmesiyle (sizin beğenmediğiniz MIL-STD-498'deki bazı dokümanları da sürecin içine katacak şekilde) oluşturulmuştur ve sonuç bence iyi olmuştur. Daha iyi olamaz mı derseniz, tabi ki olur. Süreç kendi eksikliklerini bulur ve tamir eder. CMMI 4-5 seviyelerinde bu yapılmaktadır. Bizde de süreçler sürekli "mühendislerden gelen" geri beslemelerle güncellenmektedir. Bir önceki yazımda belirttiğim Avusturalya'dan gelen kişi dünya çapında tanınmış, bu işin piri denilen ve sürekli bu konuda eğitim veren biridir ve Avusturya Hukümeti tarafından başlatılan projelerde bu standartta kullanılan dokümanlardan türetilmiş (oldukça benzer) dokümanların üretilmesinin şart koşulduğunu söylemiştir, isterseniz bu kişinin adını size gönderebilirim.
çok başarılı bir paylaşım olmuş tebrikler alternatif olarak http://www.altanayan.com/index.php/yazilim-test/ incelemenizi önerebilirim iyi çalışmalar
YanıtlaSilTeknoloji gelişirken standartlara bağlı süreçlerin sabit kalmasını doğru bulmuyorum. Piyasada değişik araçlar yazılım geliştirme süreçlerini kısaltırken, ülke olarak vakit kaybetme lüksümüz yok. NASA bile Curiosity'yi geliştirirken Slack kullandığını söylüyor. Kabalık mail kutuları + Uzun süren verimsiz toplantılar + Standartlar mı yoksa, etkili iletişim araçları + standartların kendileri değil/güncel uygulama biçimleri mi olmalı? Standart bize dokümanı yaz diyor, abartıp saçmala demiyor.
YanıtlaSilİlk defa okuyacağım temel olarak bunu kullanmamızın amacı nedir? yazılımcının bilmesine gerek varmı?
YanıtlaSil