Karar genelde makul bir gerekçeyle veriliyor: kart tasarımını bu firma daha iyi yapıyor, yazılımı da şu ekip. İkisi birleştirilince ortaya en iyi ürün çıkacak.
Sahada olan bu değil.
Kısa cevap
İki tarafı ayırmak teknik bir bölme değil, bir sorumluluk bölmesi.
Kart ile yazılım arasında, hiçbir sözleşmede tam olarak tanımlanamayan bir alan var: cihazın gerçekten çalışıp çalışmadığı. Kart tek başına ölçülebiliyor, yazılım tek başına çalıştırılabiliyor, ama cihaz ikisinin birlikte davranışı.
Bir sorun çıktığında iki taraf da kendi tarafının doğru olduğunu gösterebiliyor ve genelde haklılar. Kaybedilen zaman o tartışmada geçiyor.
Sorumluluk boşluğunun çıktığı dört nokta
Bölünmüş projelerde sorunlar rastgele yerlerde çıkmıyor. Dört nokta her seferinde aynı.
Birincisi ölçüm erişimi. Yazılımın hata ararken kart üzerinde bakması gereken noktalar var. Bunlar tasarım aşamasında düşünülmediyse, sonradan eklenmesi mümkün değil. Yazılımcı elinde ölçemediği bir kartla hata arıyor.
İkincisi güç davranışı. Pille çalışan bir cihazda yazılımın ne zaman uyanıp ne zaman uyuduğu, pil ömrünü donanım kadar belirliyor. Kart tarafı hedefi bilmeden tasarlarsa, yazılım tarafı sonradan ne yaparsa yapsın hedefe ulaşılamıyor.
Üçüncüsü güncelleme yolu. Cihazın sahaya çıktıktan sonra güncellenebilmesi, kartın buna uygun tasarlanmış olmasını gerektiriyor. Bu, yazılım tarafının sonradan ekleyebileceği bir yetenek değil.
Dördüncüsü kararsız davranış. Ofiste sorunsuz çalışan, sahada haftada bir takılan cihaz. Bu sınıf sorunda kartı ölçen ekiple kodu okuyan ekip ayrıysa, sebebin bulunması aylar sürebiliyor. Bulunamadığında ise cihaza zamanlayıcı takılıp düzenli yeniden başlatılıyor; sorun çözülmüyor, görünmez oluyor.
Karar noktaları hangi tarafa ait
Bölünmüş bir projede en çok atlanan şey, bazı kararların iki tarafa da ait olmaması. İkisinin birlikte vermesi gereken kararlar var.
Cihazın ne sıklıkla ölçüm alacağı böyle bir karar. Donanım tarafı için bu bir güç bütçesi, yazılım tarafı için bir zamanlama, işletme için bir veri sıklığı. Üçü aynı anda konuşulmadığında biri diğerini bozuyor.
Hata durumunda cihazın ne yapacağı da öyle. Bağlantı koptuğunda veri cihazda bekleyecek mi; bekleyecekse ne kadar. Bu, saklama alanı demek ve saklama alanı kart kararı.
Cihazın kendi durumunu bildirip bildirmeyeceği de ortak bir karar. Çalışma süresi, hata sayısı ve sürüm bilgisinin merkezden görülmesi, hem yazılım hem donanım tarafında yer tutuyor.
Bu kararların ortak olduğu kabul edilmediğinde, her biri iki kez ve farklı varsayımlarla veriliyor.
Aynı çatı altında ne değişiyor
Fark, iyi niyetle ilgili değil. Bilgi akışının hızıyla ilgili.
Kartı çizen ekiple yazılımı yazan ekip aynı yerdeyse, bir ölçüm sorusu bir gün değil bir saat sürüyor. Bu, tek başına küçük bir kazanç gibi görünüyor ama bir projede yüzlerce kez tekrarlanıyor.
İkinci fark tasarım kararlarında. Yazılımın neye ihtiyaç duyacağı kart çizilirken biliniyorsa, test noktası ve güncelleme yolu baştan yerine oturuyor. Sonradan eklemek çoğu zaman mümkün olmuyor.
Üçüncü fark saha aşamasında. Cihaz beklenmedik davrandığında, iki tarafın da erişebildiği tek bir kayıt üzerinden bakılıyor ve sebep hangi taraftaysa oradan düzeltiliyor.
Bu ayrım gömülü yazılım nedir ve elektronik devre tasarımı süreci yazılarında iki tarafın kendi içinden de anlatılıyor.
Bölmek zorundaysanız
Her proje tek elden yürütülemiyor. Elinizde zaten çalışan bir kart olabilir, ya da bir taraf kurum içinde yapılıyor olabilir. Bu durumda bölünmeyi yönetilebilir kılan birkaç madde var.
Sınırın nerede olduğu yazılı olmalı. Hangi davranışın hangi tarafın sorumluluğunda olduğu, cümlelerle değil örneklerle tanımlanmalı: “cihaz sahada kilitlenirse kim bakar” sorusunun tek bir cevabı olmalı.
Ölçüm noktaları tasarım şartnamesine girmeli. Yazılım tarafının hangi noktalardan ne ölçebileceği, kart çizilmeden önce yazılmalı.
Ortak kararların listesi baştan çıkarılmalı. Ölçüm sıklığı, güç hedefi, kesinti davranışı, güncelleme yolu ve durum bildirimi; bu beş başlık iki tarafın birlikte imzaladığı bir belge olmalı.
Ve bir arabulucu tanımlanmalı. İki taraf anlaşamadığında kararı verecek kişi belli değilse, tartışma kendiliğinden bitmiyor.
Bir cihaz projesinde nasıl yaşandı
Not: Aşağıdaki örnek gerçek bir müşteriye ait değildir; sahada sık karşılaşılan durumlardan oluşturulmuş bir senaryodur.
Bir işletme, sahaya dağıtacağı ölçüm cihazı için iki ayrı firmayla çalışmaya karar verdi. Kart tasarımı bir firmaya, gömülü yazılım başka bir ekibe verildi.
İlk aylar sorunsuz geçti. Kart çizildi, üretildi ve teslim edildi. Yazılım ekibi çalışmaya başladı.
İlk tıkanma pil tarafında oldu. İşletmenin beklediği çalışma süresi hiçbir şekilde tutmuyordu. Yazılım ekibi cihazın çok fazla enerji harcadığını söylüyor, donanım ekibi kartın tasarlandığı gibi çalıştığını söylüyordu.
İkisi de doğruydu. Kart, kendisine söylenen gereksinime göre tasarlanmıştı ve o gereksinimde bir çalışma süresi hedefi yazmıyordu. Kimse bu hedefi kart şartnamesine koymamıştı, çünkü herkes onu yazılım konusu sanmıştı.
İkinci tıkanma daha uzun sürdü. Cihazlar sahada düzensiz aralıklarla takılıyordu. Yazılım ekibi sorunu ölçmek için kart üzerinde birkaç noktaya bakmak istedi; o noktalar erişilebilir değildi.
Sebep bulunamadı. Geçici çözüm olarak cihazlar düzenli aralıklarla yeniden başlatılmaya başlandı ve mesele orada kaldı.
Karar ikinci partide değişti. Bu sefer iki iş tek elden verildi ve baştan beş başlık yazılı olarak konuşuldu: ölçüm sıklığı, güç hedefi, kesinti davranışı, güncelleme yolu, durum bildirimi.
İkinci partide pil hedefi tutturuldu. Kararsız davranış sorunu ise ilk ay içinde bulundu; sebep kartla ilgiliydi ve ölçüm noktası olduğu için görülebildi.
Buradaki ders iki firmanın kötü çalışması değil. İkisi de kendi işini yapmıştı. Yapılmayan şey, ikisinin arasındaki kararların kimseye verilmemiş olmasıydı.
Codigno tarafında
Elektronik ve gömülü sistemler tarafında kart tasarımı ve gömülü yazılım aynı çatı altında yürüyor. Elektronik devre tasarımı ile gömülü yazılım ve firmware ayrı hizmet başlıkları ama ayrı ekipler değil.
Bunun pratik karşılığı şu: cihaz beklenmedik davrandığında donanım mı yazılım mı tartışması yaşanmıyor.
Kendi konum takip donanımımızı tasarlayıp üretiyoruz ve yazılımını da kendimiz yazıyoruz: Codigno Tag Pro. Doğrulama tarafı prototipleme ve test, sonraki aşama prototipten seri üretime yazısında.
Sık sorulan sorular
İki firmayla çalışmak daha mı pahalı?
Doğrudan bedel olarak değil. Fark, sorun çıktığında kaybedilen sürede ve sonradan eklenemeyen tasarım kararlarında ortaya çıkıyor.
Elimizde zaten bir kart var, yazılımı ayrı yaptırabilir miyiz?
Yaptırılabiliyor. Bu durumda ilk adım kartın ne sunduğunun çıkarılması; ölçüm erişimi ve güncelleme yolu varsa iş büyük ölçüde kolaylaşıyor.
Sınır nasıl tanımlanmalı?
Cümleyle değil örnekle. “Cihaz sahada kilitlenirse kim bakar” gibi somut durumların tek bir sorumlusu olmalı.
En sık hangi konuda tıkanılıyor?
Pil ömrü ve kararsız davranış. Birincisi güç hedefinin kart şartnamesine yazılmamasından, ikincisi ölçüm noktalarının bulunmamasından çıkıyor.
Ortak kararlar hangileri?
Ölçüm sıklığı, güç hedefi, kesinti davranışı, güncelleme yolu ve durum bildirimi. Bu beşi iki tarafın birlikte belirlemesi gereken başlıklar.
Sonradan tek ele toplanabilir mi?
Toplanabiliyor ama tasarımdan gelen kısıtlar kalıyor. Ölçüm erişimi ve güncelleme yolu yoksa, bunlar ancak yeni bir kart revizyonuyla ekleniyor.
Cihaz sahada takıldığında kim bakıyor? Projenizin bugünkü bölünmesini, elinizdeki kartı ve beklediğiniz çalışma süresini paylaşın; sınırın nereden geçmesi gerektiğini birlikte çıkaralım.
