İşlevsel Ayrıştırma - Functional Decomposition

Giriş

Bu yazıyı yazma ihtiyacı son derece uzun ve sıralı çalışan bir işlevler zincirinin kodunu görünce ortaya çıktı. Kod şuna benziyordu. 

- Anteni yönlendir

- Sistem bozulmalarını kontrol et

- Automatic/Manuel mod değişiklik emirlerini işle

- Frekans atla

- Sinyal gönder

- Sinyal al

- IFF sorgulaması yap

- İzleri takip et

- Gürültü seviyesini düzenle

- Karıştırmaları tespit et

-  ...

ve onlarca adım daha. Aslında adımların isminin bir önemi yok. Sadece bunların belirli bir sıraya göre çalışması gerekiyor. Bu kadar karışık işlemler zinciri nasıl tasarlanır ve nasıl kodlanır ?

Tasarım Aşamasında Functional Decomposition

Açıklaması şöyle. Sistem Tasarım veya Yazılım Tasarım aşamasında "Functional Decomposition" yöntemi kullanılabilir ve bence kullanılmalı. Çünkü tüm akışı, sıralamayı görmenin en kolay yolu bu.

Practically, functional decomposition is used by engineers to describe the steps taken in the act of breaking down the function of a device, process, or system into its basic components. As a result of the analysis, a functional decomposition diagram will detail the functions–tasks and sub-tasks and how they work together. The diagram may also address any problems, as well as suggest solutions to those problems.

Yani Functional Decomposition bir mühendislik yaklaşımı. Ancak özellikle karmaşık yazılımlarda çok önemli. Açıklaması şöyle.

Functional decomposition is especially important in programming. Once a diagram has been created, coding may begin as the programmer may then work on the most basic components first and then build out an application. As such, functional decomposition helps focus and simplify the programming process. One drawback, however, is that functional decomposition can be especially labor-intensive and time-consuming.

Örnek

Şöyle bir ayrıştırma örneği verilebilir.

You can think of programming the same way. Think of the software running that ATM:

Code for reading the card

PIN verification

Transfer Processing

Functional Decomposition ve Altyapının (Infrastructure) Da Ayrılması

Bazen Functional Decomposition yapılsa bile altyapı ile business logic yani işlevsel kod iç içe geçebiliyor. Bunu da ayırmakta fayda var.

Örnek

Doom oyun motorunun ve oyun içeriğinin ayrı şeyler olması örnek verilebilir.Bu sayede oyunun parasız/deneme sürümleri de verilebilmiş. Açıklaması şöyle

Works well with any application that uses a clean separation of content and engine.

Object Oriented Decomposition

Açıklaması şöyle. Functional Decomposition diyagramındaki bir kutunun içinin hangi nesnelerde gerçekleştirileceği gösterir. 

Object-oriented decomposition emphasizes the entities that cause the operations.It is very useful after initial functional description. It helps to deal with change(usuallyobject don’t change often, but the functions attached to them do). Inobject-oriented decomposition, the system is decomposed into classes (objects).Each class is a major entity in the application domain. Classes can be decomposedinto smaller classes.

DO-178B

Not 1: Uçuşa Elverişlilik Açısından Yazılım Sertifikasyonu Konferansı başlıklı yazıyı okumakta fayda var.

Not 2: DO1-78B RTCA ve EUROCAE ile ortak geliştirilmesine rağmen, Amerika'da DO-178B, Avrupa'da ED-12B ismi kullanılıyor. Her iki kurum birbirlerinin verdikleri sertifikaları kabul ediyorlar.

Not 3: DO-178B yazılım geliştirmek için var. Donanım geliştirmek için DO-254 Design Assurance Guidance for Airborne Electronic Hardware kullanılıyor. Avrupa'da DO-254 yerine ED-80 ismi kullanılıyor.

Dolayısıyla bazı yazılarda DO-178C/ED-12C ve DO-254/ED80 şeklinde kullanımlar görülebilir.

DO-254 karmaşık (complex) olarak nitelenen donanımlarda kullanılır. Karmaşık tabiri ile ne kast edildiğini tam olarak bilmiyorum.

Not 4 : http://www.do178blog.com ve http://www.do178site.com faydalı siteler gibi görünüyorlar.

Not 5:  Demiryolları için CENELEC EN 50128 kullanılıyor. Bu standart DO - 178B gibi yazılımın nasıl geliştirileceğini anlatıyor. Tren'in nasıl çalışacağı ise European Rail Traffic Management System (ERTMS) standardında anlatılıyor.

DO-178C
Konuyu DO-178C başlıklı yazıya taşıdım.

DO-178B nedir ?
DO-178B sivil havacılık sektöründe hava araçlarında kullanılan emniyet kritik yazılımın geliştirilmesi esnasında kullanılan bir yazılım geliştirme sürecidir. Süreç kısaca DO-178B olarak bilinir uzun ismi ise "DO-178B Software Considerations in Airborne Systems and Equipment Certification"

Bu sürecin  uluslararası ortak hava sahasını kullanan sivil uçakların yazılım geliştirilmesinde kullanılması kanunen zorunlu. Askeri uçaklar ortak sivil hava sahasını kullanmadığı için yazılımları DO-178B ile geliştirilmek zorunda değil. Ancak bir çok askeri aviyonik yazılımı üreten firma benzer süreçleri takip ediyor.

Sovyetler Birliği sivil havacılıkta D0-178B'yi uygulamıyordu, şimdiki Rusya da uygulamıyor. Bu yüzden Rus uçakları sivil uluslararası havayollarına örneğin Avrupa hava sahasına özel izin ile girebiliyorlar. Fakat kendi ülkelerinde diledikleri gibi uçabiliyorlar.

Askeri Havacılık

Askeri havacılıkta ABD'de uçakların uçuşa elverişlilik (airworthiness) sertifikasyonunu FAA değil, Naval Air System Command for USN yapıyor. Avustralya'da ise ADF yapıyor ancak sertifikasyon için DO-178 kullanıyor.  Özetle askeri alanda işler sivil uluslararası havacılığa göre biraz daha karışık. FAA'in askeri uçaklarda hükmünün olmadığı şöyle ifade edilmiş.

No FAA issued Type Certificate or Airworthiness Certificate is required for aircraft owned and operated under military registration- FAA is not the A/W authority for these Aircraft.

Askeri uçaklar FAA sertifikasyonuna tabi olmasa da halen uçuşa elverişli olması gerekiyor. Air Force Policy Directive dokümanı şu cümle ile başlıyor.

The Air Force (AF) is responsible for assuring the airworthiness of the aircraft which it operates.

Bir başka açıklama şöyle

... the military isn't actually under the jurisdiction of the FAA. So, even if the FAA still required two pilots for all aircraft over a certain weight, that wouldn't apply to a military aircraft.

Bu yüzden FAA ve askeri uçuşa elverişlilik sertifikaları bazı noktalarda örtüşürler. Mesela FAA bazı tip uçaklarda karakutu olmasını ister. Bu kural askeri uçakları bağlamaz, ancak bir çok askeri uçakta da karakutu bulunur.

Bazı terimlerin anlamı şöyle:

Airworthiness— The verified and documented capability of an air system configuration to
safely attain, sustain, and terminate flight in accordance with approved usage and limits

Emniyet kritik yazılım geliştirilmesinde kullanılan tek standart DO-178 değil. Örneğin NASA NASA-STD-8739.8 ile kendi standardını uyguluyor. MIL-STD-498 artı MIL-STD-882D "Standard Practice for System Safety" ile yazılım da geliştiriliyor. Fakat bu ürünler sivil havacılıkta kullanılmıyor.

DO-178B'yi nereden okuyabilirim?
DO-178B belgesi açık kaynak değil. www.rtca.org sitesinden satın alınabilir.

Tarihçesi Nasıldır?
Belgeleri yayınlayan kurum RTCA (Radio Technical Commission for Aeronautics). 

RTCA Kimdir?

Belgenin başındaki açıklama şöyle. Yani RTCA resmi bir kuruluş değil.

RTCA, Incorporated is a not-for-profit organization formed to advance the art and science of aviation and aviation electronic systems for the benefit of the public. The organization functions as a Federal Advisory Committee and develops consensus-based recommendations on contemporary aviation issues..

...

Since the RTCA is not an official agency of the United States Government, its recommendations many not be regarded as statements of official government policy unless so enunciated by the U.S. government organization or agency having statutory jurisdiction over any matters to which recommendations relate.

Süreci denetleyen ve yürüten kurum ise 1958 yılında kurulan FAA. Belgenin ismindeki DO Document kelimesinden geliyor. 178 sayısı ise yayınlandığı zamanki verilen numara. RTCA kar amacı gütmeyen (non-profit) bir kurum. Uzlaşmaya dayalı (consensus based) belge ve öneriler yayınlıyor.

DO-178
1982 yılında yayınlandı. Bu yıllarda uçaklarda yazılım kullanılmaya başlandığı için bu belgede genel yazılım geliştirme döngüsü anlatılıyor.  Örneğin gereksinim yazılmalı, doğrulama yapılmalı vs. gibi. Belgenin bu ilk sürümünde MIL STD 498'de olduğu gibi doldurulması gereken dokümanların içeriği bile vardı. Bu fikirden hızla vazgeçildi.

DO-178A 
1985 yılında yayınlandı. Bu belge ile Konfigürasyon Yönetimi sürece dahil ediliyor. Bir yazılım sürecinin olması ürünün emniyetli olduğu güvencesini vermez. Bu belgede ilk defa havacılık yazılımında kritiklik seviyeleri 1,2,3,4,5 vs. olarak belirtilmiş ve süreç seviyeye göre düzenlenmiş. Daha sonra bu belirtimden vazgeçildi.

DO-178B 
1992 yılında yayınlandı. Bu belgede doğrulama ve analize yönelik eklemeler var. Bu belge ile yazılımın kritiklik seviyeleri A,B,C,D,E olarak belirlendi. Bu belge üretilirken endüstrinin bir çok dalından uzmanlar bir araya gelerek çalışmış ve uzlaşmaya dayalı (consensus based) bir yöntem izleyerek yazıya dökülmüş.

Belgede Guideline (yönerge) ve Guidance (rehber) kelimeleri bolca kullanılıyor. Gerekçe olarak ta yazılımı geliştiren ekibin Objective'leri yerine getirdiği müddetçe istediği yazılım modelini (waterfall, spiral vs.)  kullanabilmesi belirtilmiş.

Ben bu yazıda bu kelimeler yerine DO-178B için "standart" kelimesini kullanmayı tercih ettim.

DO-178C 
2011 yılında yayınlandı. Nesneye Yönelik geliştirme için eklemeler var. DO-178C belgesinde Guideline ve Guidance kelimeleri mümkün olduğunca az kullanılmış.

Seviyeler Nelerdir?
DO 178B/C Seviyeleri yazısına taşıdım

Maliyet Nasıl Etkilenir?
Emniyet seviyesi arttıkça maliyetler de artıyor. Aşağıdaki şekilde durum görülebilir.

Buradaki bir değerlendirmede, askeri havacılıkta emniyet seviyesinin sivil havacılığa göre daha önemsiz olduğuna dair bir şekle denk geldim. Ancak ister sivil ister askeri amaçlı olsun, DO-178B yazılım açısından hep aynı kuralları işletir. Kaza olasılığının değişmesi, yazılımdan çok sistem gereksinim ve tasarımından kaynaklanıyor olmalı diye düşünüyorum.

DER Nedir?
DER (Designated Engineering Representative) FAA adına DO-178B/C ile geliştirilen yazılımı denetleyen ve sertifiye eden kişidir. DER sertifikasyonda attığı imza ile kişisel sorumluluk (liability) alır. Bir kazada yazılım hatası bulunursa ve DER'ın işini yapmadığı ortaya çıkarsa DER cezalandırılır. Bu yüzden DER'lar son derece titizdirler her türlü süreç adımı için delil (evidence) talep ederler.

SOI nedir ?
Stage of Involvement (SOI) aşamasında DER denetlemede bulunur. SOI bir kaç sefer yapılabilir. Projenin aşamasına göre planlara, gereksinimlere, tasarıma, koda ve teste bakılır. Bu belgeler arasında izlenebilirlik olup olmadığı örnekleme yöntemiyle denetlenir. Eğer sistematik bir hata varsa, bulunmaya çalışılır. 4 aşamadan oluşur.

SOI'lerde kontrol listeleri (check list) kullanılır.

SOI-1 Planning Review
SOI 1 - Software Planning Review Checklist yazısına bakabilirsiniz. 

SOI-2 Development Review
SOI 2 - Development Review yazısına bakabilirsiniz. 

SOI-3 Verification Review
SOI-3 Verification Review yazısına bakabilirsiniz. 

SOI-4 Final Review
Amacı yaz

Seviye D projelerde SOI yapılmaz.

Üretilen Planlar
DO-178B ile 5 tane ana plan kullanılıyor.
PSAC : yazısına taşıdım
QA : Quality Assurance Plan
CM : Configuration Management Plan
SWDP : Software Development Plan
SWVP : Software Verification Plan

Diğer Belgeler
Bu planların yanında bir çok belge de üretiliyor. Bunlardan önemli olanları requirements, design ve coding standartları.

Software Requirements Standard:
Gereksinimin nasıl yazılacağını belirtir.

Software Requirements Checklist:
Gereksinimin gözden geçirme kontrol listesi.

Software Design Standard:
Alt Seviye Gereksinimler (Low Level Requirements) D0-178B sürecinde tasarım olarak kabul edilir. Dolayısıyla tasarım denilince ilk akla gelen UML diyagramları olmamalıdır.

Coding Standard :
Kapsama analizinde işi zorlaştıracak hususlar coding standard (yazılım kodlama standardı) ile kullanılmayacak şeklinde belirtilir. Ayrıca kullanılmayacak API'ler de belirtirlir. Açıklaması şöyle

While developing it is common to use a limited subset of assemblies (APIs) in order to prevent developers from preforming dangerous operations. This type of restriction can also ensure that developers utilize the APIs correctly, such as cleaning up objects as a requirement.

İlaveten static analizin nasıl yapılacağı belirtilir.

Code Review Checklist :
Kod gözden geçirmesi kontrol listesi. Kod gözden geçirmesi otomatik mi olacak belirtilir.

Software Environment Configuration Index :
Yazılımı geliştirirken kullanılan tüm araçların isim ve sürümlerinin olduğu liste. Yazılımı tekrar geliştirmek istersek bu listedeki araçları kurarak tekrar başlayabiliriz.

Software Accomplishments Summary :
Yapılan işlerin özeti. Eğer varsa, sapmaların izah edildiği yer.

DO178B Standardı Nasıl Okunur
Tablolarda bulunan boş yuvarlaklar independent review gerektirmez. Dolu olanlar gerektirir.
CC1 ile işaretlenenler için değişiklik talep kaydı gerekir. CC2 olanlar için belgenin son hali yeterlidir. Açıklaması şöyle

Configuration Management in DO-178C

Configuration items that you track through configuration management fall into two Control Categories, which determine the level of control that must be applied to items in that category.

DO-178C specifies which items must be treated as Control Category 1 or 2 items based on the project’s Design Assurance Level.

Items treated as Control Category 1 (CC1) must undergo full problem reporting processes, and formal change review and release processes.

Configuration items classified as Control Category 2 (CC2) items do not need to undergo these more formal processes, but items in this category must still comply with configuration identification and traceability needs, be protected against unauthorized changes, and meet applicable data retention requirements.

Kodlama Önerileri 
Konuyu DO-178B Object Oriented Technology in Aviation başlıklı yazıya taşıdım.

Sertifikasyon
Sertifikasyon tanım olarak kişi, organizasyon, ürün, parça ya da cihazların düzenlemelere  uygunluğunun tanınması / belgelendirilmesi durumudur.

Üretilen yazılımı sertifikasyona tabi tutulması ile ilgili olarak Uçuşa Elverişlilik Açısından Yazılım Sertifikasyonu Konferansı başlıklı yazı da okumaya değer bir yazı.

Grandfathering Yöntemi
FAA eskiden üretilmiş ve sertiye edilmiş bir hava aracının yeni bir varyasyonu üretilince sadece değişen kısımları sertifiye ediyor. Örneğin 1972 yılında üretilen bir uçağın yeni bir varyasyonunda sadece motoru değişmiş olsun. Bu durumda sadece motor sertifiye ediliyor. Aracın geri kalan kısmının halen emniyetli olduğu kabul ediliyor. Bu yönteme "grandfathering" deniliyor. Yöntemin yanlış olduğuna, emniyeti değil üreticiyi koruduğuna dair eleştiriler var.

Örnek
Hatta bir kazada 1978 yılında sertiye edilmiş bir helikopterin, yeni modelinin halen daha acrylic cam kullanması yüzünden ölümcül kaza yapması çok eleştirildi. 1996 yılında acrylic cam kullanımının FAA tarafından yasaklanmasına rağmen, yeni olan bu helikopter "grandfather rules" yüzünden ana tasarım değişmediği için eski tip cam ile sertifiye edilebilmiş.

Örnek
Boeing 737'de "trim wheel" artık legacy kabul edilse bile tüm modellerde var. Sebebi ise yine grandfathering. Açıklaması şöyle

When an aircraft is certified with particular equipment, changing that can be difficult and may require the filing of a MAJOR REPAIR AND ALTERATION form. Its likely cheaper for Boeing to keep the trim wheels the way they are. The common 737 type certificate notes that the airframe was certified against (and must be rigged in accordance with) a particular set of Boeing drawing.

Sertifikasyonda Kullanılan Bazı Kelimeler
Certified
Belli bir hava aracı için sertifikasyonu olan yazılım

Certifiable
Sertifikasyona hazır yazılım. Daha önce başka bir platformda sertifiye edilmiş ve kullanılan yazılım, yeni bir platform için certifiable'dır. Yeni platform için bir kere daha sertifiye edilmesi gerekir.

Qualified
Geliştirmede kullanılan ancak uçakta uçmayan bir yazılım geliştirme aracını belirtir. Örneğin yer bakım yazılımı.

Compliant
FAA haricindeki bir başka oluşum tarafından sertifikalandırılan yazılımı nitelendirir. Bu yazılım uluslararası sivil hava sahasında uçamaz ancak ülkeler kendi dahilinde bulunan ve ortak sivil hava sahasını kullanmayan diğer hava araçlarını bu şekilde sertifiye edebilirler

DO-178B ve Sistem Gereksinimleri
Aşağıda bazı örnek sistem gereksinimleri var:

* The avionics system shall provide maintenance access to the system LAN.
* The avionics system primary flight display shall consist of the following
      - Airspeed indicator
      - Altitude indicator
      - Vertical speed indicator
        ....

Süreç

Süreç temel olarak şu safhalardan oluşuyor

Planning Process

Design Process

Verification Process

DO-178B ve Yazılım Geliştirme Faaliyeti(Software Development Activities)

Bu süreçte iki seviye faaliyet var. High Level Requirements geliştirilmesi ve Low Level Requirements geliştirilmesi . Aşağıda bir açıklama mevcut.

The software development processes are composed of

1. The Software requirements process, which usually produces the high level requirements (HLR)

2. The Software design process, which usually produces the low level requirements (LLr) and the software architecture

Şekilde sistem gereksinimlerinin, HLR ve LLR haline nasıl geldiği gösterilmiş.

HLR yazılırken doğal dil kullanılıyor. Aşağıda bazı örnek HLR gereksinimleri var:

* For each X, the X shall be imported from Y database
* When a BIT failure is detected, the LRU shall log the failure toZ
* The A software shall verify the CPU bus interface to the graphics chip is  operational and is showing a status of good.

DO-178B Software Design Process yazısına bakabilirsiniz

DO-178B ve Yazılım Doğrulama Faaliyet (Verification Process) 
Yazılım doğrulama faaliyeti şu ana başlıklar altında yapılıyor. Burada şu cümle önemli.

Who does the testing in DO-178C?

Many DO-178C objectives that involve testing require independence in testing at some DALs.

When this is required, the person (or group) implementing a particular item and the person (or group) verifying that item must be different.

Independence requirements are identified within DO-178C’s objective tables.

Higher DAL developments require independence on a larger number of objectives than lower DAL developments.

Test edilecek sistemler şöyle olabilir

Doğrulama Süreci Es Geçilemez
Bazen mülakatlarda adaya şöyle bir soru soruluyor. Soru direkt olarak havacılık ile ilgili değil ancak benzerlik içeriyor.

Just imagine you are working on some important simulation system and a client call you at 8 pm. He's kind of upset because your simulation tool doesn't work at his place. If it does not work tomorrow at 8 am he'll give up on your company and it will lose hundreds of millions. What do you do?

Süreçler es geçilemez. Açıklaması şöyle.

- There's urgency in time and money. This is to cloud your judgment.

- You're being asked to circumvent normal procedures for pushing changes. Especially for big clients, and doubly so for something as tightly regulated as aeronautics, this is a no-go. Just look at what's happening to Boeing right now if you're curious what happens in this industry when things aren't taken seriously and regulations are skirted.

Tool Qualification
Amaç yazılım geliştirmede kullanılan araçları doğrulamaktır. 3. parti araçların yeterliliği test edilir, test sonuçları yazılır.  Eğer araç kendi geliştirdiğimiz bir yazılımsa SRS, test ve test sonuçları yazılır.

Kendi geliştirdiğimi araç bağımsız bir şekilde doğrulanmalıdır. Örneğin simülatör geliştiriyorsak, simülatörü doğrulamak için simülatörün besleyeceği yazılımı kullanamayız. Bu tür bağımlılıklar DER tarafından hemen yakalanır.

Software Review
Üretilen her şeyin gözden geçirilmesi

Software Testing
Bu faaliyeti gerçekleştirirken iki önemli madde yapılmalı. İlki 

- Requirements Based Test Case Selection, diğeri ise 

- Test Coverage Analysis.

Requirements Based Test Case Selection:
Süreçte gerçekleştirilen yazılım testi faaliyetini diğer süreçlerden ayıran en önemli konu, tüm testlerin gereksinimlere bakılarak yazılması. Aşağıdaki cümle daha iyi açıklıyor.

DO-178B imposes that all test cases are requirements-based. Blind testing based on code, without clear relationship with the requirements is not valid.

Bu faaliyet çevik metodlarda kullanılan Test Driven Development'a (TDD) benziyor. TDD'de amaç her Feature için test yazmak. Featue gereksinim olarak düşünülebilir. İki yöntemin ayrıldıkları nokta TDD'nin kodu yazmadan önce testin yazılmasını istemesi. DO-178B'de test'ten Test Coverage Analysis çıkarıldığı için ve bu işlem maliyetli olduğundan kodun bitmiş olması gerekir.

Test Coverage Analysis :
Testler geliştirildikten sonra, target ortamda koşturulurlar ve test çıktılarına bakılarak analiz yapılır. DO-178B Level C ve üstü seviyelerde iki temel analiz yapılmasını şart koşmaktadır.

> 1. Gereksinim Kapsama Analizi : İngilizcesi Requirements based coverage analysis. Analiz sonucunda her yazılım gereksinimi için bir test olduğunu doğrulanmalıdır. Ayrıca testlerin normal ve sağlamlık (robustness) kriterleri göz önüne alınar yazıldığı gösterilmelidir. Bu analiz sonucunda bazı gereksinimler için daha fazla test yazılması gerektiği kanaatine varıldıysa, yeni testler geliştirilir.

2. Yapısal Kapsama Analizi : İngilizcesi Structural Coverage Analysis. Analiz sonucunda koşturulan testlerin hedeflenen sertifikasyon seviyesine göre kodu kapsandığını doğrular. Bu analiz sonucunda. testlerde yetersizlik varsa, yeni testler geliştirilir veya mevcutlar iyileştirilir. Yazılım gereksiniminde yetersizlik varsa - örneğin tek bir gereksinim varken çok daha fazla kod yazılmışsa - gereksinim iyileştirilir. Ölü kodlar (dead code) silinir. Deactivated kod - test edilen kofigürasyonda çalışması gerekmeyen kod - varsa, bu kodlar işaretlenir ve geliştirme ortamının doğru konfigürasyonda olduğu gösterilir.
Kuralların en sıkı olduğu seviye A seviyesidir. Bu seviyede derleyici tarafından üretilen makine koduna kadar izlenebilirlik ve analiz uygulanır. Does “DO-178B level A” prohibits optimizing compilers? sorusuna verilen cevaplarda da görülebildiği gibi derleyicinin kod optimizasyon yetenekleri de mümkün olduğunca kapatılır.

Yazılım Kapsama Analizi yani Structural Coverage Analysis (SCA)
Konuyu Structural Coverage Analysis başlıklı yazıya taşıdım.

Programlama Dili
Programla dili genellike C veya C++. Ancak hava aracına girmeyecek kodlar örneğin yardımcı araçlarda diğer diller - Python gibi -  kullanılabilir.

İşletim Sistemi
Emniyet kritik sistemlerde genellikle Green Hills firmasının Integrity, Wind River firmasının VxWorks, LynxOS işletim sistemleri kullanılır.

DO-178B ve Gerekircilik (Determinizm)
DO-178B ve Determinizm yazısına taşıdım.

DO-178B, Cihazlar ve Built-in Test (BIT)
Bir çok cihaz Built-in Test (BIT) yapılmasını destekliyor. BIT ile cihazın durumunu ve varsa hatalarını görebilmek mümkün. DO-178B projelerinde BIT 3 çeşide ayrılıyor.

PBIT (Power up BIT) : Cihaz ilk elektrik aldığından yapılan oldukça kapsamlı BIT. Cihazın güvenilir olduğunu söyleyebilmek için vazgeçilmez bir adımdır. Register, memory, interrupt vs. gibi şeyler test edilir.

IBIT (Initiated BIT) : Genellikle bir hata alınması sonucunda elle çalıştırılan BIT. Hatayı tespit etmeye yöneliktir. Yazılımın zamanlamasını (scheduling) etkilediği için pek tercih edilmez.

CBIT (Continuous BIT) : Belli aralıklarla çalıştırılan BIT. Sürekli tekrar ettiğinden dolayı zamanlamada biraz yer ayrılarak rahatlıkla yapılabilir.

DO-178B ve Entegrasyon Lab Ortamı
Yazılım hava aracına yüklenmeden önce Sistem Entegrasyon Labında (SEL) denenir. Burada dikkat edilmesi gereken nokta, tüm ortamın , kablolama  dahil , hava aracındaki ortam ile birebir aynı olması. Amaç yazılımı ve cihazları havadaki ortamdaymış gibi, yerde test etmek olmalı.

Software Corruption
Bu konunu DO-178B ile direkt bağlantısı yok. Sadece not almak istedim. Bir kaza incelemesinde geçen cümle şöyle

A number of potential trigger types were investigated, including software bugs, software corruption, hardware faults, electromagnetic interference and the secondary high-energy particles generated by cosmic rays.

 Burada geçen software corruption yazılımın algoritmasında olan hata değil, yazılımın depolandığı ortamda olan bozulma anlamına geliyor. Yani yazılımın bitlerinin bir şekilde değişmesi/bozulması

Amazon Web Service (AWS)

Giriş

Amazon Web Service notlarım. AWS 2015 yılında popüler olmaya başladı. Açıklaması şöyle

Furthermore, around 2015, AWS had become popular. AWS had been around for a while by then but it's around 2015 when the whole concept of infrastructure as a service (IaaS) really took off and it became extremely convenient to spin up EC2 instances for cheap. 

Loglama

Loglama şöyle

AWS Relational Database Service (RDS)

AWS Veri Tabanları yazısına taşıdım.

Amplify

Açıklaması şöyle

Today’s developers are overwhelmed with the amount of services AWS offers.

The solution? AWS Amplify, which helps developers to easily build and deploy complete mobile and web apps by providing a collection of CLI tools, libraries, frameworks, and cloud services.

How AWS Amplify Works
Your main interaction point when using Amplify is the CLI tool, which comes with many commands that help you set up and maintain a serverless project. The Amplify CLI can create infrastructure by generating and deploying CloudFormation code. It also includes code generators for mobile and web apps that use the following languages: JavaScript/TypeScript, Dart, Swift, Java, and GraphQL.

This way, you get new AWS resources deployed to the cloud, configured with best practices, and the boilerplate code needed to connect your frontend with these resources.

Cloud Watch

Cloud Watch yazısına taşıdım

Identity and Access Management (IAM)

Identity and Access Management (IAM) yazısına taşıdım

AWS Pinpoint

Şeklen şöyle. SMS almak için kullanılabilir.

Adımlar şöyle. Burada SMS'leri tüketecek bir pinpoint yaratılıyor

 - From Services, click on Pinpoint.

- On the Pinpoint main page, click on Manage Projects.

- Create a new project.

- Skip Project Features for now.

- In Project Dashboard, click on Settings -> SMS and Voice.

- In the SMS and voice page, under Number settings, click on the long/short code you have.

NOTE: This is the code you will get after you asked for in the first step.

- Go all the way down until you see Two-way SMS. Click on it.

- First thing, enable it.

- In incoming messages destination, choose an existing SNS topic, and select the one we created earlier.

- Done! easy right?

AWS Batch

AWS Batch yazısına taşıdım

AWS Step Functions

Açıklaması şöyle. Rakipleri Azure Logic Apps, Google Cloud WorkFlows, Apache Airflow

A cloud-based workflow engine managed by AWS. Workflows are defined using a JSON like syntax or using the visual editor, and the service offers a visual representation of your definition. Executions, which are also visualized, can be triggered manually, or via events.

AWS Systems Manager

AWS Systems Manager yazısına taşıdım

AWS Simple Email Service - SES

AWS SES yazısına taşıdım

AWS Simple Notification Service - SNS

AWS SNS yazısına taşıdım

Kinesis - General Purpose Data Queue

AWS Kinesis yazısına taşıdım

Amazon Simple Queue Service - AWS SQS

AWS SQS yazısına taşıdım

Amazon S3 - Simple Storage Service - Object Storage

AWS - Storage Services yazısına taşıdım

Amazon Elastic Block Store (EBS)

AWS - Storage Services yazısına taşıdım

Amazon Elastic Cache

Redis kullanan cache

Amazon Elastic Compute Cloud (EC2)

AWS EC2 yazısına taşıdım

Amazon Elastic Container Service (ECS)

AWS ECS yazısına taşıdım

Amazon Elastic Container Registry (ECR)

Açıklaması şöyle

AWS’s Elastic Container Registry (ECR) is a service that lets you “store, share and deploy your container software anywhere.” You create repositories to easily store and manage container images that you or anyone you share them with will pull later to deploy applications on containers -- using, for example, a Task Definition on AWS’s Elastic Container Service. ECRs offer other excellent features, such as scanning the stored container images for vulnerabilities -- and their API lets you streamline the management of images and version lifecycles as part of your deployment process.

Amazon Elastic Kubernetes Service (EKS)

AWS EKS yazısına taşıdım

Amazon Lambda

AWS Lambda yazısına taşıdım

Amazon Fargate

AWS Fargate yazısına taşıdım

Amazon App Runner

AWS Runner yazısına taşıdım

AWS Transcribe

AWS Transcribe yazısına taşıdım

CloudFormation - Programmatically Configure AWS Resources

Şikayetler burada

Redshift

Bir Datawarehouse. Açıklaması şöyle

The service handles datasets of various sizes ranging from a few gigabytes to a petabyte or more.

Users initially launch a set of nodes and provision them, after which they upload data and carry out an analysis. Part of a broader Amazon Web Services (AWS) ecosystem, the Redshift data warehousing service offers various features. For instance, users can export data to and from their data lake and integrate with other platforms such as Salesforce, Google Analytics, Facebook Ads, Slack, Jira, Splunk, and Marketo. The warehouse service achieves high performance and efficient storage using columnar storage, data compression, and zone maps.

Şeklen şöyle

COGNITO — User Management/Mobile Login

Açıklaması şöyle

Cognito sounds great on paper. It will take care of user management for you, including Google Sign-in, Facebook Login, and handle user role assignments, reset passwords, and define password rules. It can do both Desktop and Mobile. It can work with public user pools, and private user pools (to restrict enterprise private resources).

Cognito will help you save time by presenting its own UI when requesting permission from users.

Cognito has competitors: Auth0, OneLogin, Okta, to name a few. It is also possible to implement all of those above login workflows yourself, given enough time and team size.

But, if you do use Cognito for a while, ugly edges will reveal themselves. You will discover that Cognito cannot be used for Native Mobile logins. When you are making a mobile application, and attempting to get user to login via Facebook, if you had integrated with Firebase, it will prompt the user to open the Facebook App, and allow user to simply authenticate/authorize (assuming they are already logged in on the Facebook App).

With Cognito, they are presented with an embedded WebView, prompting the user to log into Facebook again in the embedded WebView.

Ekip Kurma (Team Building) Takım Lideri - Team Lead

Team Lead (Takım Lideri)

Ekipten sorumlu kişi. 

Takım Lideri ve Şirket Süreçleri

Yeni ve tecrübesi takım liderleri şirketin süreçlerini önemserler ve uymak isterler. Daha kıdemli olanlar şirketin süreci olmasa dahi kendi geliştirdikleri yöntemlerle bu işi kotarabilirler. Açıklaması şöyle. 

There were team leads who had been working in software development for 25+ years and others that had just gotten promoted. The younger leads liked having a more strict process to follow, whereas the more senior managers had a process they had customized over the years.

Takım Lideri vs Senior Software Engineer

Senior Software Engineer yazısına taşıdım

Takım Lideri ve Teknik Bilgi

Takım lideri teknik açıdan önde olmalı ve çalışılan alanı bilmelidir. Ayrıca Takım liderinin teknik bazı önemli kararlarda öncülük etmesi beklenir. Bazı önemli karar örnekleri

"Should we use WCF or reinvent our own communication layer?"

"Should we implement caching?"

"Should caching be distributed?"

"What's better for our project, WinForms or WPF?"

Takım Lideri Olmayan Ekip Olur mu ?

Pek yaygın bir uygulama değil ancak bazı projelerde yöneticinin ipleri elinde sıkı tutmak istemesi nedeniyle uygulandığını gördüm ve bence çok yanlış bir yöntem.

Takım Lideri ve Dış Dünya ile İletişim
Bazen ekip içindeki iletişim yeteneği en zayıf olan kişi, teknik kabiliyetinden ötürü dış dünya ile en çok iletişim kurması gereken insan olabiliyor. Bu durumda yanlış anlaşılmalara ve tartışmalara yer vermemek için takım liderinin arabulucu veya tampon gibi davranması gerekebilir. 

Takım Liderinin Ekibi Koruyan Bir Kalkan Görevi Görmesi Beklenir

Açıklaması şöyle.

You are the team lead and so you are the shield protecting your developers from above. Pointing fingers might be good for you in the short term, but it will hurt team morale in the long term and come around to bite you. Blame culture is toxic and good programmers rarely stay around in one.

Bir örnek şöyle

An anecdote to support this -- When I was a junior developer, I made a change and accidentally left a file handle open. That segment of code gets called a few times per hour, and we didn't find out until it was in production and after a few months a customer's machine got knocked offline due to open file handles. That's super bad. When we discovered what the error was, instead of playing the blame game (Who did this-Who reviewed-Who tested it?!), my boss calmly said "We need to get this fix out," supported us, kept morale high, and we had a fix in the field in 3 days (That's very fast for us).

Takım Liderinin ve Hedefler

Sevilen takım liderleri, çıta çok yükse konulsa ve hedefin tutturulamayacağını düşünse bile her iyi gelişmeyi kutlarlar. Açıklaması şöyle

- Celebrate every victory. If someone is improving, celebrate it even if it's not up to your standards, they're advancing. It motivates them.

- Have a series of milestones and goals towards where you want them to perform. Acknowledge each one.

- Tell them you appreciate their improvement, and encourage them to reach the goals.

- Join in the celebration, share in their small victories.

- Push them to do more. Have stretch goals.

Takım Liderinin Yapılan Hataların Tekrar Etmemesi İçin Tedbir Alması Beklenir

Açıklaması şöyle.

While the reason it happened might have been one specific developer, your whole team (and you) are at fault for letting it get that far. Your process for deployment is obviously lacking, which is specifically your job to fix.

Free Friday

Ekipteki insanlar genellikle bir şey öğrenip kendilerini geliştiremediklerinden şikayet ederler. Google ve Microsoft bir aralar "Free Friday" yöntemini denemişler ve faydalı bulmuşlar. Aslında bu konu tartışmalı. Çünkü Google ve Microsoft artık bu yöntemi uygulamıyorlar ve bir ara Free Friday gününün "work related" yani iş ile ilgili olması gerektiği kısıtını da getirmişler. 

Ancak şirketteortam uygunsa takım lideri tarafından teklif edilebilir.

Regresyon Testi Nedir - Geriye Yönelik Test İle İşlevin Bozulmadığından Emin Olmak

Regresyon Testi neden Lazım?

Biraz daha kapsamlı test yaparak bizi istenmeyen durumlara karşı korur

1. İyileştirme Sonrasında Çıkan Hatalar

Müşterinin iki tane yedekli sistemi vardı. Bir iyileştirme istediler. İyileştirme geliştirildi, laboratuvarda test edildi, müşteri test ortamında test edildi ve canlı sistemlerden birisine kuruldu. Ancak bu aşamadan sonra problemler çıkmaya başladı. Güncellenen canlı sistem bazı girdileri işlememeye başladı. Güncellenmeye sistem ise doğru çalışıyordu. 

Daha sonra yapılan incelemede, sistemlere deneme amaçlı bir hot patch kurulduğu ancak güncellemenin bunları dahil etmediği anlaşıldı. Bundan sonra işler karışıyor. Hot patch bir daha incelendi ve yanlış kodlandığı anlaşıldı. Akla gelen seçenekler şöyle

1. iyileştirme + hot patch düzelmesini birlikte mi yüklemek lazım ?

2. yoksa sadece iyileştirmeyi yükleyip, hot patch hatasını müşteriye bildirmek mi lazım ?

3. müşterinin şikayeti yok, yanlış hot patch'i halının altına süpürmek mi lazım ?

Büyün bunlar nereden kaynaklanıyor ? Hot patch yüklenirken, hiç regression koşulmadığı için işlevin bozulmadığı test edilmemiş.

Regression Kelimesi
Tam Türkçe karşılığı yok. Zaten herkes regresyon diye kullanıyor."Geriye yönelik" anlamına geliyor sanırım.

Amacı Nedir?
Regresyon testi yeni eklenen bir yama, iyileştirme, hata gidermeden sonra eski testleri çalıştırarak işlevin bozulmadığını ve yeni hataların yazılımına girmediğini test etmek demek.

Aslında şu sorunun cevabını veriyor.
- How to effectively work with teammates whose fixes to bugs cause more bugs?

Örnek
Bir örnek şöyle.

Often during software testing, some bugs are detected and a quick bug fix is carried out. Regression testing is executed in order to ensure that the bug fix didn’t cause any abruption in the application’s intended functionality. When some bugs are found to be occurring as a result of the bug fix, those are known as regression bugs. For example, let’s say your login page is having some errors and the developer fixed it. Now, the login page is working fine, but the registration page is causing some validation or other errors that did not exist earlier. The new error may have been caused because of the fix on the login page. This is a regression defect and it is relevant to deal with for delivering a more robust product in the market.

Regresyon Testi
Eski testleri çalıştırırken temel 2 yöntem seçilebilir.

1. Tüm testleri çalıştırmak. 

Bu yöntem maliyetli olabilir. Açıklaması şöyle.

This is the technique where test engineers execute all the existing test cases without missing any. This is quite expensive as it requires a huge amount of time and resources.

Bu yöntemle ilgili bir karikatür şöyle :)

2. Belli testleri çalıştırmak

Açıklaması şöyle.

In this technique, test engineers select a subset of test cases based on the impact analysis.

2.1 Belli Testlerin Seçilmesi

Burada en bu belli testlerin neye dayanarak seçildiği. Seçilen testler Regresssion Test Report'a kaydedilir.

Örneğin yama X hesaplaması için yapılmıştır. Bu durumda test gruplarına bakarak Hesaplama testleri grubundaki testleri koşmak mantıklı olabilir.

Örneğin yama kullanıcı doğrulaması için yapılmıştır. Bu durumda Login test grubundaki testleri koşmak mantıklı olabilir.

Sadece aklımıza gelenleri seçtik derse şüpheyle yaklaşmak gerekir.

2.1 Belli Testlerin Önceliklendirilmesi

Belli testleri çalıştırırken bir önceliklendirme yapmak gerekebilir. Şu 6 maddelik yöntem kullanılabilir.

Prioritize. A common heuristic is RCRCRC:

Recent: new features

Core: essential functionality of your product

Risk: risk is defined as the Probability of occurrence (how likely is it to happen) multiplied by the affect (what's the damage, in money hours lost or anything relevant), Risk hides under it a lot and can be calculated at different levels from module to system to environments.

Configuration sensitive: this represents both internal configuration and environment settings, for example the type of the device or operating system

Repaired: recently repaired bugs represents untested area

Chronic: some areas are known to be vulnerable. This can be due to complexity, the level of the developers or an area that falls in between responsibilities

Take your list of test cases and grade them for each item, let's say 1 - 5 (don't use zero since it will interfere with the next step), multiply then the six figure and sort by the result. This will give you a first estimation as to what should be tested first and why.

Enterprise Service Bus (ESB)

Enterprise Service Bus Nedir?

Birbirlerinden çok farklı uygulamaların konuşabilmelerini sağlar. Ancak sadece bir iletişim mekanizması değildir. Aynı zamanda üzerinde logic barındırır. Böylece mesajların dönüşümü, zenginleştirilmesi gibi işlevleri ve Enterprise Integration Patterns kitabındaki örüntüleri de yerine getirebilmeyi sağlar.

Enterprise Service Bus (ESB) became the most popular middleware pattern/integration patterns to solve most of the integration problems in monolithic applications. ESB's main features include message transformation, protocol conversion, service orchestration, and payload enrichment. These features are readily available in all majorities of ESB implementations from different vendors. The features help the solution to be integrated with different types of systems within the Enterprise seamless.

Şeklen şöyle. 

ESB ve Microservice Mimarisi Karşılaştırması

ESB yazılımları cloud üzerinde çalışmıyorlar. Dolayısıyla microservice mimarisi ile pek uyumlu değiller. ESB mi microservice mi sorusunun cevabı daha çok sistemdeki uygulamaların ne kadar birbirinden farklı ve eski olduğuna dayanıyor. Açıklaması şöyle

Both the ESB and Microservice approaches have their advantages and disadvantages. Choosing the best solution depends on how large and diverse the new application environment. Microservices give added advantages compared to ESB’s due to the support of the latest cloud deployment platforms. Larger, more diverse environments choose ESB solution, whereas Smaller environments, including web and mobile applications, would choose microservices architecture.

Frederick Brooks

Giriş
Frederick Brooks'un çokça atıfta bulunulan bazı eserleri ile ilgili notlarım aşağıda.

Mythical Man-Month Kitabı
İlk basımı 1975 yılında olan bir kitap halen okunuyor ve tartışılıyor. Bu kitaptaki bir cümle şöyle

"The programmer, like the poet, works only slightly removed from pure thought-stuff. [They] build castles in the air, from air, creating by exertion of the imagination."

1. Bölünebilen İşler
Bu kitapta bazı işlerin bölünüp parçalanabildiği, bazılarını ise bölünemeyeceği anlatılıyor.

It takes a woman nine months to have a baby. Nine women will not reduce this nine month interval one iota.

Bu söz aslında başka birine ait ancak Frederick Brooks meşhur hale getirmiş. Açıklaması şöyle

and originated from Theodore von Kármán in the unique form “Everyone knows it takes a woman nine months to have a baby. But you Americans think if you get nine women pregnant, you can have a baby in a month.” Fred Brooks made this a very popular statement in the software industry ...

Bölünebilen işler için ekibe daha fazla adam eklemek aslında iletişim yükünü artırdığı için belli bir noktadan sonra hızlanma yerine yavaşlamaya sebep olur. 

9 adam/aylık bir proje için ideal sayının 3 olduğu belirtiliyor.

2. Surgical Team

Bir işi yaparken cerrah en önemli işi yaparken diğerleri ona yardımcı olur. Yönetici açısından ideal, ancak yan rolü oynayan kişinin egosu açısından ideal değil :)

Mills proposes that each segment of a large job be tackled a team, but that the team be organized like a surgical team rather than a hog-butchering team. That is, instead of each member cutting away on the problem, one does the cutting and the others give him every support that will enhance his effectiveness and productivity.

3. Second System Effect Nedir?
Aynı işi ikinci kere yaparken, sistemin gereksiz bir sürü özellik ile şişebildiğini anlatıyor.

An architect’s first work is apt to be spare and clean. He knows he doesn’t know what he’s doing, so he does it carefully and with great restraint.

As he designs the first work, frill after frill and embellishment after embellishment occur to him. These get stored away to be used “next time.” Sooner or later the first system is finished, and the architect, with firm confidence and a demonstrated mastery of that class of systems, is ready to build a second system.

This second is the most dangerous system a man ever designs. When he does his third and later ones, his prior experiences will confirm each other as to the general characteristics of such systems, and their differences will identify those parts of his experience that are particular and not generalizable.

The general tendency is to over-design the second system, using all the ideas and frills that were cautiously sidetracked on the first one. The result, as Ovid says, is a “big pile.”

4. No Silver Bullet Makalesi
1986 yılında yazılan bu makalede yazılım geliştirirken karşılaşılan sıkıntıları, 

- yazılımın doğasından kaynaklananlar (essential complexity) ve 

- iyileştirilebilecek olanlar (accidental complexity) 

şeklinde ayırmış. 

Essential Complexity

Yazılımın doğasından kaynaklanan complexity, conformity, changeability, invisibility gibi özelliklerin ne yaparsak yapalım giderilemeyeceğini, ancak araç/gereç, insan ve süreçlerin iyileştirilebileceğini söylüyor. 

Acidental Complexity
İyileştirmeler için ise hiç bir iyileştirmenin 10 kat verimlilik artışı getirmeyeceğini söylüyor.

There is no single development, in either technology or in management technique, that by itself promises even one order-of-magnitude improvement in productivity, in reliability, in simplicity.

Bir başka açıklama şöyle

Complexity: One reason for a muddled architecture is that software often reflects the inherent complexity of the application domain. This is what Brooks called “essential complexity” [Brooks 1995]. In other words, the software is ugly because the problem is ugly, or at least not well understood. “