MIL STD 498 - Critical Design Review

Giriş
Critical Design Review (CDR) için Türkçe olarak genellikle  Kritik Tasarım Gözden Geçirme cümlesi kullanılıyor.

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
CDR toplantısına örnek olarak Altay tankı CDR'ına veya SM-3 CDR'ına bakılabilir.

Örnek
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 Öncesi Preliminary Design Review
Bazı projelerde CDR öncesi PDR yapılır.

CDR Öncesi Prototip
CDR aşamasına gelmeden önce bir prototip yapmak ve müşteri ile paylaşmak bence iyi bir fikir.

Kağıt üzerinde CDR gerçekleştirmek hoş değil. Modern yazılım süreçlerinde de prototip hazırlanması da vurgulanıyor. Bu amaç için simülatör(ler) kullanılabilir 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 Toplantısını Kim Gerçekleştirir
CDR'ı üst yüklenici şirket gerçekleştirir. Bazı projelerde alt yüklenicilerin de CDR'a girdi vermesi bekleniyor. Şartnamede bu beklenti yazılı olmalı.

Diğer
Bazı projelerde çift CDR da yapılabiliyor.

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.

MIL-STD-498 -SRS

Giriş
System Software Specification (SSS) ve Software Requirements Specification (SRS), Hardware Requirements Specification (HRS) bir çok projede karşımıza çıkan iki belge. Aşağıda bu belgeler ile ilgili aldığım notlar var. SSS, SRS ve HRS gibi belgelerin sadece yazıya dayalı olması iyi değil. Çünkü aşağıdaki cümlede ifade edildiği gibi yazıyı zihnimizde canlandırmak kolay değil.

Most people are bad at mentally mapping documentation to actions.

Dolayısıyla bu belgelerin şekiller ile desteklenmesi gerekiyor. SSS ve SRS genellikle CDRL listesine dahil edilirler.

Açık Kaynak/Open Source Projeler

Bu projelerin çoğunda SRS bulunmaz.

Requirements Analysis
SRS kullanılan yaşam döngüsü modeline göre Requirements Analysis (Gereksinim Analizi) safhasının veya yinelemelerinin sonucunda ortaya çıkar. Açıklaması şöyle.

Requirement Analysis is that it is a process and the document created during this process is SRS (Software Requirement Specification).

CDRL (Contract Data Requirements List) Nedir?

CDRL sözleşmenin bir lahikası olarak belirtirlir. Müsteriye teslim edilecek dokümanları listeler. Türkçesi SVIL'dir (Sozleşme Veri İsteri Listesi).

SRS

Bir CSCI'ın geliştirilmesi için kullanılan gereksinimleri içeren doküman. Projede her CSCI bileşeninin kendi SRS dokümanının olması gerekir. Bazı projelerde User Requirements diye bir belge de üretiliyor ama tam ne işe yarar bilmiyorum.

Türkçe Karşılığı
Yazılım Gereksinim Özellikleri (YGÖ) kelimesi kullanılıyor. Bence makul bir karşılık.

Dili
SRS belgesini bir çok firma İngilizce olarak hazırlamaya çalışıyor. Hazırlayanların ana dili İngilizce olmadığı için ifade bozuklukları, anlaması güç cümleler ile dolu olabiliyor. Türkçe hazırlanırsa da karşılıkları olmadığı için mecburen İngilizce kavramlar/kelimeler kullanılıyor. Her iki durum da hoş değil.

İngilizce yazılan gereksinimlerde niçin "shall" kelimesinin kullanıldığı burada açıklanmış. Türkçesi "yapacaktır" gibi düşünülürse, daha bir kesinlik manası sağladığı için "will" yerine "shall" kullanılıyor.

IEEE SRS
IEEE SRS dokümanında şu konulara değinilmesini istiyor

1.Interfaces
2.Functional Capabilities
3.Performance Levels
4.Data Structures/Elements
5.Safety
6.Reliability
7.Security/Privacy
8.Quality
9.Constraints and Limitations

Başlıklar olarak şöyle yapılabilir.

1.Introduction 1.1 Purpose 1.2 Document conventions 1.3 Intended audience 1.4 Additional information 1.5 Contact information/SRS team members 1.6 References

2.Overall Description 2.1 Product perspective 2.2 Product functions 2.3 User classes and characteristics 2.4 Operating environment 2.5 User environment 2.6 Design/implementation constraints 2.7 Assumptions and dependencies

3.External Interface Requirements 3.1 User interfaces 3.2 Hardware interfaces 3.3 Software interfaces 3.4 Communication protocols and interfaces

4.System Features 4.1 System feature A 4.1.1 Description and priority 4.1.2 Action/result 4.1.3 Functional requirements 4.2 System feature B

5.Other Nonfunctional Requirements 5.1 Performance requirements 5.2 Safety requirements 5.3 Security requirements 5.4 Software quality attributes 5.5 Project documentation 5.6 User documentation

6.Other Requirements Appendix A: Terminology/Glossary/Definitions list Appendix B: To be determined

Interfaces Nedir
1. User Interfaces
2. Hardware interfaces
3. Software interfaces
4. Communication Interface

olarak düşünülebilir.

User Interfaces başığı altına (the buttons, sliders, text boxs etc..) gibi şeyler yazılabilir deniyor. ancak ben hiç yazıldığını görmedim.

SRS Mimari ve Tasarım
SRS problem uzayı, tasarım ve mimari ise çözüm uzayında gibi düşünülüyor. Ancak bence tam olarak birbirlerinden bu kadar bağımsız şeyler değiller.

Örnek
Şöyle bir soru olsun.

A software Requirements Specification (SRS) document should avoid discussing which one of the following ?
(A) User interface issues
(B) Non-functional requirements
(C) Design specifications
(D) Interfaces with third party software

Cevabı (C) Design Specifications.

Örnek
"A Comparison of Requirements Specification Methods from a Software Architecture Perspective" makalesi SRS maddelerinin, yazılımın mimarisini ne kadar etkilediği konusunu işliyor. Makaleden bir kaç cümle şöyle.

"If functionality is the only concern in designing an architecture, any structure will do. This conclusion stems from the work of Parnas more than 30 years ago."

Devam ediyor.

"Connecting requirements to architecture can be viewed as a special case of connecting a system's problem space and its solution space".

SRS Geliştirme Eforu
Geliştirme eforunun yaklaşık yüzde 40'ı gereksinim ve tasarım aşamasına ayrılırsa iyi olur.

SRS Belgesinde Kullanılan Bazı Sütünlar

Derived Requirement

Aşağıda açıkladım
Verification Method

Doğrulama yöntemi. Test, Analysis, Inspection (Code Review, Design Review), Demonstration olabilir. Verification (doğrulama) yöntemi olmayan madde olmamalı.
Notes

Gereken notlar

Derived Gereksinimler Nedir
Bazı projelerde gereksinimler "Derived" olarak işaretlenirler. Derived Requirement sistem tasarımından kaynaklanmayan, sistem izlenebilirliği olmayan ister anlamına geliyor. Örneğin sistem tasarımı, yazılımın kaç bölümlenmeden (partition) oluşacağını söylemeyebilir. Ancak SRS'te bu ister bulunabilir. Bu durumda SRS'teki ister "Derived Requirement" olarak işaretlenir. Aşağıdaki cümle de önemli.

"These are requirements that are generated by the development team, based on a number of sources such as regulatory agencies, corporate guidelines, and past experiences on similar projects."

DO-178B kullanan projelerde bir gereksinimin derived olarak işaretlenebilmesi için "Safety Assesment" süreci tarafından onaylanmış olması gerekir.

Non-Functional Gereksinimler Nedir?
Non-Functional Gereksinimler yazısına taşıdım.

SRS ve Tasarım Arasında İzlenebilirlik Tablosu
Her SRS dokümanında, isterlerin hangi CSC'de ele alındığını gösteren bir izlenebilirlik tablosu bulunur. Aslında bu tablo genellikle işe yaramaz, çünkü SRS ve gerçek tasarım/kod arasında çoğunlukla büyük boşluklar bulunur. Mühendisler izlenebilirlik tablosunu kabaca kestirimlerine dayanarak doldururlar. SRS'i eline alıp okuyarak geliştirmeye başlayan bir mühendis, tek bir maddenin kaç bileşene dokunacağını, maliyetinin ne olacağını kestiremeyebilir.

DO-178B gibi süreçlerde ise bu boşluğu doldurmak üzere, High Level (bahse konu SRS belgesi) ve Low Level Requirements isimli iki belge üretilir. Low Level Requirements belgesi SRS ve kod/arasındaki boşluğu kapatır.

SRS ve Test Arasında İzlenebilirlik Tablosu
SRS ve Test (STD) arasında da izlenebilirlik kurmak gerekir. Hatta Test ve Test Sonuçları arasında da bağlantı kurulur.

Yazılım Kalite Etkenleri ile İlgili Gereksinimler

SRS belgelerinde bazen aşağıdakine benzer yazılım kalite etkenleri (software quality factors) görüyorum. Bunları not etmek istedim.

Functionality Requirements
Örnek yaz

Reliability Requirements
Örnek

X shall be able to process following data during N hours.

Maintainability Requirements
Örnek yaz

Availability Requirements
Örnek yaz

Flexibility Requirements
Örnek yaz

Portability Requirements

X shall be developed independent from OS specific system calls.

Reusability Requirements
Örnek yaz

Testability Requirements
Bu iyi bir örnekmi bilmiyorum ancak aşağıdakine benzer cümleler gördüm.

X shall provide health status. X shall perform BIT upon request.

Efficiency Requirements
Örnek yaz

Usability Requirements
Örnek yaz

Kalite Etkenleri Nasıl Test Edilir
Sistem veya Yazılım Kalite Etkenleri netice itibariyle birer gereksinim olduklarına göre, test edilmeleri de gerekir. Bu iş için "Fonksiyonel Olmayan Testler" başlığı altında toplanabilecek bazı faaliyetler gerçekleştirilir.
Performans Testleri :
Yükleme (Load) Testleri : Sistemin belli bir yük altında testi
Stres Testleri: Sistemin aşırı yük altında testi
Uyumluluk (Compatibility) Testleri :
Güvenlik Testleri :
Kullanılabilirlik Testleri :
Yerelleştirme (Localization) Testleri : Çeviriler, tarih, saat formatı vs.

SRS Hataları
SRS'e donanım özelliklerini yazmak gördüğüm hatalardan birisi. Örneğin software shall run on 1 GB memory, 1GHz processor gibi. Bu tür bir gereksinim bence sistem seviyesinde olmalı.

Yazılımın kapasitesini belirten ancak throughput, gecikme, bir işin ne kadar birim zamanda yapılacağını belirtmeyen gereksinim maddeleri bence doğru değiller. Örneğin bir yazılım 5000 nesneyi bellekte tutacaktır denirse ancak bu 5000 nesneyi veya 1 tanesini ne kadar zamanda işleyeceği belirtilmezse, yazılımı test etmek için referans zamanı verilmemiş olur.


SRS Hangi Ölçütlere Göre Gözden Geçirilebilir
SRS Kontrol Listesi yazısına taşıdım.

Müşterinin SRS'e Yorum Vermesi
Sözleşmede genellikle SRS teslim edildikten X gün sonrasına kadar müşteri yorum verebilir şeklinde bir madde bulunur.

Benzer şekilde SRS'i hazırlayan taraf ta yine Y gün içerisinde yorumlara cevap vermekle mükelleftir, şeklinde bir madde ile taraflar SRS'i ciddiye aldıklarını belirtirler.

SRS Örnekleri
SRS Örnekleri yazısına taşıdım.

Baseline
İngilizce açıklaması şöyle

A specification or software product that has been formally reviewed or agreed upon, that thereafter serves as the basis for further development, and that can be changed only through a formal change control process.

Türkçe açıklaması şöyle

Resmi olarak gözden geçirilmiş veya üzerinde anlaşılmış ileriki geliştirmeler için temel teşkil edecek ve sadece resmi değişiklik kontrol süreci ile değiştirilebilen özellik veya yazılım ürünü.

SRS Değişiklikleri
SRS değiştiğinde eski ana hat (baseline) ile yeni anahatın farkını çıkarıp ekibe dağıtmak gerekir. Doors'ta Baseline Comparison Report alınabilir.

MIL-STD-498 -SSS

Giriş
System Software Specification (SSS) ve Software Requirements Specification (SRS), Hardware Requirements Specification (HRS) bir çok projede karşımıza çıkan iki belge. Aşağıda bu belgeler ile ilgili aldığım notlar var. SSS, SRS ve HRS gibi belgelerin sadece yazıya dayalı olması iyi değil. Çünkü aşağıdaki cümlede ifade edildiği gibi yazıyı zihnimizde canlandırmak kolay değil.

Most people are bad at mentally mapping documentation to actions.

Dolayısıyla bu belgelerin şekiller ile desteklenmesi gerekiyor.

SSS ve SRS genellikle CDRL listesine dahil edilirler.

CDRL (Contract Data Requirements List) Nedir?
CDRL sözleşmenin bir lahikası olarak belirtirlir. Müsteriye teslim edilecek dokümanları listeler. Türkçesi SVIL'dir (Sozleşme Veri İsteri Listesi).

Sistem Kalite Etkenleri ile İlgili Gereksinimler
SSS belgelerinde bazen aşağıdakine benzer sistem kalite etkenleri görüyorum. Bunları not etmek istedim.

Sistem kalite etkenleri, işlevsel olmayan ancak bir yazılımın "iyi", "sürdürülebilir", "güvenilir", "verimli", "kabul edilebilir" olması gibi "yüksek kalite" özelliklerini belirtirler.

Kalite ile "ölçülebilirlik" ayrılmaz ikilidirler. Aşağıdaki kavramların bir çoğu dolaylı olarak ölçülebiliyor.

Reliability
Reliability -Güvenilirlik yazısına taşıdım.

Maintainability
System shall have ethernet interface for maintenance purpose.
System shall record failures onto disk.

Availability
Örnek yaz

Flexibility
Örnek yaz

Portability
Bu kavram ile Adaptability, Instability, Co-existance, Replacability kelimeleri genellikle iç içe kullanılırlar.
Örnek yaz

Reusability
Örnek yaz

Testability
Örnek yaz

Usability
Bu kavram ile Undestandability, Learnability, Operability, Attractiveness kelimeleri genellikle iç içe kullanılırlar.
Örnek yaz

Deployability
Örnek yaz

SSS'in SRS'e Aktarımı
SSS belgesi SRS için girdi teşkil eder. Aktarımın tam yapıldığından emin olmak için izlenebilirlik (traceability) matrisinin olması ve her iki belgenin de gözden geçirilmesi (review) gerekir.
SSS'in HRS'e Aktarımı
SSS belgesi HRS için girdi teşkil eder.Aktarımın tam yapıldığından emin olmak için izlenebilirlik (traceability) matrisinin olması ve her iki belgenin de gözden geçirilmesi (review) gerekir.

SSS ve Backlog
Bazı SSS dokümanlarında ileride yapılacak (5 sene sonra) işlerin de yazılı olduğu durumlar gördüm. Bu maddeler Phase X olarak işaretliydi. Böylece izlenebilirliği kurulmasa bile dokümanda yer alıyorlardı. Bu kullanım şekli bence doğru değil.

MIL-STD-498 Software Test Plan

Giriş
MIL-STD-498 ile ilgili yazılara Software Test Plan ile devam ediyorum.

Bazı şirketlerde bu belgeye kardeş olan SysTP yani System Test Plan de mevcut. SysTP ile SSS arasında izlenebilirlik kurulur.

Software Test Plan (STP)
Türkçesi Yazılım Test Planı (YTEP) kelimesi
kullanılıyor. Yazılan testlerin koşturulması için kullanılacak araç, gereken ortam, kaynaklar vs. gibi konuları açıklayan doküman. İyi bir tanım burada.

A document describing the scope, approach, resources and schedule of intended test activities. It identifies amongst others test items, the features to be tested, the testing tasks, who will do each task, degree of tester independence, the test environment, the test design techniques and entry and exit criteria to be used, and the rationale for their choice, and any risks requiring contingency planning. It is a record of the test planning process.

Test Plan vs Test Strategies

Farklar şöyle. Test Strategy, Test Plan'dan önce hazırlanır

Test Plan	Test Strategies
Test plan can be derived from the Software requirement traceability matrix.	Test strategies can be derived from Business requirement specifications.
The test plan should be revised if there are any modifications to the requirement.	While preparing documents, test methodologies stay unchanged.
Based on the project, we can create a test plan.	Test strategies can be applied to a variety of tasks.
A test plan is written after gathering all information.	Test strategies made before test plan.
A test plan should be clear and concise.	Test strategies serve as a roadmap for evaluating apps.

IEEE 829 ile verilen Test Plan Outline ile benzerlik gösteriyor. IEEE dokümanının başlıkları şöyle.

1) Test Plan Identifier
2) References
3) Introduction
4) Test Items
5) Software Risk Issues
6) Features to be Tested
7) Features not to be Tested
8) Approach
9) Item Pass/Fail Criteria
10) Suspension Criteria and Resumption Requirements
11) Test Deliverables
12) Remaining Test Tasks
13) Environmental Needs
14) Staffing and Training Needs
15) Responsibilities
16) Schedule
17) Planning Risks and Contingencies
18) Approvals
19) Glossary

MIL-STD-498 dokümanının başlıkları ise şöyle:

3. Yazılım Test Ortamı
  Hangi CSCI'ların test edileceği ve hangisi için STD hazırlanacağı belirtilir. Test ortamını gösteren bir     şekil verilebilir.
  3.1 Yazılım Kalemleri
  3.2 Donanım Kalemleri
  3.3 Kurulum, Test ve Kontrol
   3.4 Personel
başlıkları altında bilgi verilir.

4. Test Tanımlamaları
5. Test Takvimi

Test sonucunda şöyle ideal olarak şöyle bir çıktı beklenir.

Yani zaman içinde çıkan hata sayısında düşüş olması gerekir.

MILT STD 498 - SSDD - System/Subsystem Design Document

System/Subsystem Design Document (SSDD)
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. 

Aslında genel kararları yazmak önemli olabiliyor. Açıklaması şöyle

Part of maintaining quality architecture requires an understanding of how the current architecture has evolved over time, and what the decisions, assumptions, and constraints at critical points in time.

Örnek 1

Operating System :  System will be based on POSIX API and will run on any POSIX compliant    system.
 Rationale : POSIX provides a general purpose interface between the operating system and the  software.

Örnek 2

 Positional Data : Positional data will be in WGS-84 format
 Rationale : WGS-84 is a widely used standard

Örnek 3

 Logging : System will use multi-level logging.
 Rationale : Multi level logging increases maintainability of the system

Örnek 4

 Fault Management : Fault management and redundancy will be provided.

4. System Architectural Design
 4.1 System Components
  4.1.1 Hardware Architectural Design
  4.1.2 Software Architectural Design
  Yazılımın bir taxonomy içine almak kolay değil. Burada yazılımın uyacağı açık sistem standardını belirtmek faydalı olur. Örnek:

The system shall be based on X (e.g J2EE) architecture.

 Bazı yazılım özellikleri şöyle. Belki bunlar vurgulanabilir.

• Open source vs. proprietary
• Publicly available vs. in-house only
• Extensible API or not?
• Plugin support?
• Platform (i.e. what infrastructure does it depend upon)
• Extent of specific customisation for user / company
• Scriptability (i.e. embeds own programming language for users)
• Client type (web vs. desktop GUI vs. console app vs. REST API etc.)
• Monolithic structure vs. composable components?
• Support for distribution (clustering, redundancy failover etc.)
• Stable vs. experimental (in development)

Failover
Elimizde bir broker olsun. Client A'nın isteklerini Broker MainSubscriber'a versin. O da veri tabanına yazdın. Eğer MainSubscriber istekleri zamanında işleyemiyorsa, Broker isteği FailoverSubscriber'a versin. Şöyle yaparız.

                   -----> MainSubscriber ----
                  /                          \
ClientA --> Broker                            ---> Database
                  \                          /
                   ---> FailoverSubscriber --

Diğer
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. Layered Architecture için açıklama şöyle

The idea of the Layered Architecture is that each layer provides an abstraction to the previous layer, so a layer depends only on the previous layer.

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

MIL-STD-498 Software Test Document

Giriş
MIL-STD-498 ile igili yazılara Software Test Document ile devam ediyorum.

Bu belgenin kardeşi olan System Test Document (SysTD) sistem seviyesinde. Dolayısıyla SSS dokümanına göre hazırlanır. STD ise SRS'e göre hazırlanır.

Yazılımları test ederken

1. Structured Test
2. Exploratory Test

yöntemleri kullanılabilir. MIL-STD-498 Structured Test yöntemini benimsiyor. Bu yöntemi gerçekleştirmek için test adımlarının tanımlı olduğu bir doküman üretilmesini şart koşuyor.

Software Test Document (STD)

Türkçesi Yazılım Test Tanımı (YTET). Yazılım Gereksinim Özellikleri (YGÖ) dokümanındaki gereksinimleri karşılayacak şekilde yazılmış yazılım testlerini detaylarıyla anlatan doküman. İçeriği aşağıdakine benzer

1. Scope
2. Referenced Documents
3. Test Preparations - Yazılım ve donanımın kurulacağı test yatağını anlatır
4. Test Descriptions
Test Descriptions kısmında bana en zor gelen şey testin başında sistemin belli bir durumda olması gerekliliği. Bazı testlerde sistemi bir kere ilklendirmek ve sonraki adımları çalıştırmak mümkün. Bazı testlerde sistemi her testin başında temiz bir duruma getirmek, hatta açıp kapamak bile gerekebiliyor.
5. Requirements Traceability - Genellikle bir tablo şeklinde olur.
6. Notes

STD genellikle FAT testinden belli bir süre (örneğin 60 gün önce) önce son halini alıp yayınlanır ve müşteriye teslim edilir. Tarihler sözleşmede belirlidir.

STD Dokümanını teslim etmeden önce, CSCI testi/testleri koşulmuş olmalıdır. Eğer varsa diğer sistemler ile bir veya birkaç ön entegrasyon testi koşulması gerekir. Ön entegrasyon yapılacaksa, simülatör, emülatör, ICD gibi testte kullanılacak şeylerin son halini almış olması gerekir.

CSCI Testi
CSCI testinin amacı discard case'ler, logical case'ler gibi koşulları test etmektir.
Sistem Entegrasyon testinin amacı mesajların uçtan uca gittiğini test etmektir. Sistem testleri yapısal ve içerik olarak CSCI testi ile aynı olup sadece test ortamı değişebilir.

Software Test Result veya Software Test Report 
STD her yayımda koşulur. Arkasından STR hazırlanır.

Test Statüsü Nasıl Takip Edilir
STD koşturulurken haftalık test statüsünü görmek faydalı olabilir. Bu basit bir rapordur.

Test Adım Sayısına Göre Rapor

Total Number of Test Steps : 2000
Total Steps Executed : 100
Percentage of Test Steps Executed : 50%

Test Sayısına Göre Rapor

Total Number of Test Cases : 50
Not Executed : 22
PASS : 1
FAIL : 14
PASS with RE-RUN : 13

Yazılım Geliştirme ve Test Koşusu Zamanlaması 
Test faaliyeti başlarken yazılım geliştirilmeye de devam eder. Bazı firmalar test edilecek kodu yeni bir branch olarak açıp testte çıkan hataları hem branch hem de trunk'ta düzeltirler.

Bazı firmalarda test edilecek koda tag atarlar. Testte çıkan hatar yine trunk üzerinde düzeltilir ve svn'deki tag'i, değişen dosyalarda ilerletmeyi tercih ederler.

MIL STD 498

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

• 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 Document
SRS : Software Requirements Specification
ICD : Interface Control Document

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

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)