Gömülü Yazılım Geliştirme ile Çevik Donanım

Ürün/pazara uygun bulan karmaşık donanım ve yazılım ekosistemleri oluşturmak zor bir iştir. CB Insights'ın bir raporuna göre, donanım girişimlerinin çoğu nihayetinde paraları bittiği için başarısız olurken, bunun altında yatan en büyük sebep aslında ürünlerine olan talep eksikliğidir. Bu, yalnızca, donanım girişimleri için ürün yöneticisi rolünün ne kadar kritik olduğunun öneminin altını çiziyor, çünkü birincil hedefleri başarılı bir ürün sunmak için müşteri ihtiyaçlarını ve sorunlu noktaları bulmak.

Çalıştırdığım son şirket, park endüstrisi için bir web, mobil, gömülü yazılım uygulamaları ve donanım cihazları ekosistemi oluşturdu. Donanım ürün stratejisi, beni çeşitli donanım ürünü geliştirme iş akışlarıyla deneyler yapmaya yönlendiren günlük işimin bir parçasıydı. 10 yıldır donanım ürünleriyle çalışmama ve Elektronik ve Telekomünikasyon alanında lisans derecesine sahip olmama rağmen, bu işte öğrenmem gereken çok şey vardı. Aşağıdaki kılavuzu, yerleşik yazılım alanıyla donanım içinde ürün yönetimini benden daha hızlı hızlandırabileceğinizi umarak oluşturdum.

Donanım Ürün Yönetiminin Zorlukları

SaaS ve mobil uygulamalar, çevik bir çerçeve kullanılarak kolayca geliştirilebilirken, gömülü yazılım ve donanım cihazı geliştirmedeki benzersiz koşullar, çevik ilkelerin uygulanmasını çok daha zor hale getirir. Bu ilk bölümde, karmaşıklık yaratan donanım geliştirmenin özelliklerini ele alacağız. Hepsinin basit çözümleri yoktur, ancak bir sonraki bölümde ele alınacak olan belirli donanım geliştirme stratejilerini kullanarak zorluğu azaltmanın yolları vardır.

Yerel Olarak Uzmanlaşmış Teknik Yeteneği Bulmak Zor

Yeni donanım ürünleri oluşturmak, mevcut olanları yinelemekten çok daha zordur. Üniversitelerde nadiren öğretilen prototip oluşturma konusunda çok fazla yaratıcılık ve deneyim içerir. Bazı üniversitelerin bu becerileri geliştirmek için prototip oluşturma tesisleri veya gerekli araçları bile yoktur ve bu tür deneyimler neredeyse yalnızca Ar-Ge merkezlerine sahip daha büyük donanım şirketlerinde kazanılır. Bu nedenle, ilgili uzmanlığa sahip yerel profesyoneller bulmak çok zor olabilir ve birçok donanım başlangıç ​​kurucusunun yetenek havuzlarını uzaktan işe alarak genişletme ihtiyacı duymasına neden olabilir.

Sürüm Kontrol Sistemleri Donanım Tasarımına Uyarlanmıyor

Çoğu sürüm kontrol sistemi (VCS), yazılım geliştirme ortak çalışması için oluşturuldukları için metin biçimini desteklemeye yöneliktir. Donanım geliştirme içeren projelerde, bilgiler bunun yerine OrCAD gibi özel araçlar yardımıyla oluşturulan tasarım dosyalarına sarılır. Ve bu araçlardan bazıları yalnızca VCS'lerde kullanılmak üzere optimize edilmemiş ikili dosyaları destekler. CADLAB, donanım uyumlu bir VCS oluşturmaya yönelik nispeten yeni bir girişimdir ve umarım yakın gelecekte bunun gibi daha fazla araç olacaktır.

Donanım Üretim Tesisleri Yerinden Edildi

Donanım üretim tesisleri genellikle başka bir bölge, ülke veya kıtada bulunur. Donanım üreticisi ile üretici arasındaki iletişimin özel olarak ele alınması gerekir ve başarılı ürün teslimatının anahtarıdır. Başarılı iletişim, ürünün kalitesini garanti etmek ve dinamik ürün-pazar doğrulama aşamasındaki değişikliklerle başa çıkabilmesini sağlamak için daha stratejik çerçeveleme gerektirir. Bunu başarmak için donanım üreticisinin, üreticiye gönderilen birçok ayrıntılı özelliği oluşturması gerekir. İşbirliği çerçevesi, hızlı bir şekilde güncelliğini yitirebileceklerinden, bilgilerin hızlı bir şekilde teslim edilmesini ve spesifikasyonların yaşam döngüsünün yönetimini sağlamalıdır.

Donanım Değişiklikleri Daha Az Esnektir

Yazılım başlangıçlarında popüler bir işletim modeli, erken aşamalarda hız için kaliteden ödün verir. Facebook bile bir süredir “hızlı hareket et ve bir şeyleri kır” mantrasını savundu. Bir başka tanıdık yaklaşım, “yapana kadar 'sahte yapmak'tır. Bu, geliştiricilerin günlük olarak kod güncellemelerini dağıtmasına olanak tanıyan ucuz altyapı maliyetleri ve kolaylaştırılmış programlama çerçeveleri nedeniyle yazılım başlangıçları için işe yarar.

Geliştirmeye yönelik bu yaklaşım yavaş yavaş donanım alanına sızmış olsa da, donanım değişiklikleri yapmak ve uygulamak çok daha zor olduğu için bu alanda talihsiz bir eğilimdir. Geliştirme maliyetleri, hızlı ve sık sürümlerden elde edilen değeri dengeler, bu nedenle sağlam donanım mimarileri oluşturmak için tasarım aşamasına daha fazla yatırım yapmak aslında çok daha arzu edilen bir stratejidir.

Kitle Fonlamasının Düşüşü

Birçok girişim, başarılı bir donanım kitle fonlaması kampanyası başlatmanın pazar doğrulaması ile eşdeğer olduğu fikrine hapsolmuş durumda. Kitle fonlaması, özellikle fiziksel nesneyle ilgili bilinçsiz mülkiyet arzumuz nedeniyle, bir donanım bileşeni içeren ürünler için en başarılı olma eğilimindedir. Bununla birlikte, kitle fonlaması, ürününüzü geniş ölçekte doğrulamak için değil, erken aşamada ürün geliştirmeyi finanse etmenin demokratik bir yoludur. Talihsiz gerçek şu ki, başarılı kitle fonlaması kampanyaları olan birçok şirket, pazarlarını ölçekte doğrulamadıkları için üretimlerini ölçeklendirmeyi zor veya neredeyse imkansız bulmuştur.

Sertifikalar, Düzenlemeler ve Onaylar

Tüm donanım ürünleri, satılmak için bir tür sertifika gerektirir. Donanım ürünlerini piyasaya sürmenin ilk aşamalarında en çok gözden kaçan adımlardan biridir. Sertifikasyon kısıtlaması, ürün planını ve geliştirme için uygulanan çerçeveyi nasıl etkileyecek? Bir proje kilometre taşı olarak sertifikasyon ve diğer onaylarla birlikte projenin erken aşamalarını planlamak, ancak bundan sonra şartlı olarak başlangıç ​​aşamasına geri dönmek alışılmadık bir durum değildir. Ürün yöneticileri bunun yerine düzenlemeleri, bağımlılıkları ve ürün planı stratejik karar ağ geçitlerini daha şelale benzeri bir yaklaşımla dikkatlice analiz edebilir.

Donanım Ürün Yönetimi için Fırsatlar

Gömülü yazılım alanına sahip donanımda var olan bazı zorlukları ele aldığımıza göre, şimdi donanım geliştirmenin doğal zorluklarını dengelemek için geliştirme sürecini nasıl daha akıcı ve öngörülebilir hale getireceğimize bakalım.

Çevikliği Donanım Geliştirmeye Dahil Edin

Deneyimli ürün yöneticileri, yeni teknolojik gelişmelerin yarattığı bir pazar fırsatından yararlanmaya çalışan gömülü yazılımlarla donanım ürünleri oluşturmanın arkasındaki zorlukların farkındadır. Planlama aşamasından ürün başarısı olasılığından ödün vermeden pazara çıkış süresini hızlandırmayı dengelemeyi öğrenirler. Çoğu zaman, bu bir su sıçraması-düşüş yaklaşımıyla oluşur.

Ürün tasarlama aşaması, ürün ilkelerini, hedeflerini ve üst düzey özellikleri mümkün olduğunca çok ayrıntıyla genişletir. Harika ürün yöneticileri, bu aşamanın çıktılarını iyileştirmek için daha fazla zaman harcar: vizyon, misyon, fırsat değerlendirmesi, donanım ürün hedefleri ve özellikler. Bu, herhangi bir donanım prototipi üzerinde çalışmaya başlamadan önce yeterince açık olması gereken ürünün kuzey yıldızıdır, bu nedenle şelale yaklaşımı önerilir.

Donanım ürünleri için iyi belgelenmiş gereksinimler ve işlevsel özelliklerin yanı sıra donanım ürününü çalıştıran gömülü yazılım için iyi bir teknik mimariye sahip olmak çok önemlidir. Gereksinimlerdeki ve spesifikasyonlardaki değişiklikler, tüm ekip tarafından onaylandıktan sonra teşvik edilmemeli, cezalandırılmalıdır.

Gömülü yazılım geliştirilirken standart bir scrum metodolojisi kullanılabilir. Önceden tanımlanmış donanım mimarisiyle çalışmak için yazılım uygulamasını ayarlamak ve iyileştirmek, bunun tersinden daha az zaman ve para açısından daha ucuzdur.

Son entegrasyon testi ve kullanıcı kabul testi şelale koşullarında yapılmalıdır. Bu aşamada, geliştirme aşaması tamamlanır ve yeni işlevler ve eksik özellikler, bir sonraki planlama dönemi için ek iş talepleri olarak kaydedilir.

Çevik'i Gömülü Yazılım Geliştirmeye Dahil Edin

Gömülü yazılımlarla karmaşık donanım ürünleri oluşturmak, geleneksel yazılım geliştirme metodolojilerinin uygulanma şeklini etkiler. Kişisel bir bilgisayarda çalışan yazılım üretmek için kullanılan birçok sistem, kaynak kıtlığı ve çok daha uzun geliştirme yaşam döngüleri ile ilgili kısıtlamalar olduğundan, gömülü yazılım geliştirmek için uygun değildir.

Brezilya'dan bir grup akademisyen ve profesyonel potansiyel bir çözüm önerdi: Gömülü Kontrol Sistemleri için Platform Tabanlı Yazılım Tasarım Metodolojisi: Çevik Bir Araç Takımı . Bu metodoloji, çevik ilkeleri gömülü yazılım geliştirmeye dahil eder. Aşağıda metodolojinin kısa bir özeti verilmiştir, ancak donanım ürün yöneticilerine, uygulamalarında uygulamadan önce tam açıklamayı okumaları şiddetle tavsiye edilir.

Bu metodolojide yer alan roller şunlardır:

• Platform sahibi – Kalite, planlama ve maliyet hedeflerinin tanımlanmasından sorumlu
• Ürün lideri – Ürünün uygulanmasından, entegrasyonundan ve test edilmesinden sorumlu
• Özellik lideri – Alt sistem projelerini yönetmekten ve teslim edilebilir özelliğin ilerlemesini izlemekten sorumludur
• Geliştirme ekibi – Ürün geliştirme üzerinde çalışmak

Metodoloji, gömülü yazılımın geliştirilmesini üç süreç grubuna ayırır:

1. Sistem platformu süreçleri grubu. Bir sistem, mimarinin ve API platformlarının bir parçası olacak sistem bileşenlerini bir platform kitaplığından seçer ve söz konusu uygulamanın kısıtlamalarını karşılamak için bunları özelleştirir. Özelleştirme süreci, tasarımcı tarafından yapılandırılabilen işlemciler ve platforma entegre edilmiş çalışma zamanı tarafından yeniden yapılandırılabilir mantık programlanarak yinelemeli döngüler halinde gerçekleştirilir.
2. Ürün geliştirme süreçleri grubu. Ürünü oluşturan işlevler, platformun donanım veya yazılım öğelerine bölünür. Metodoloji, uygulama bileşenlerinin enerji tüketimini, yürütme süresini ve bellek boyutunu hesaba katan bölümleme algoritmaları sağlar.
3. Ürün yönetimi süreçleri grubu , ürün kapsamı, zaman, kalite ve maliyet parametrelerini izler ve kontrol eder. Önerilen yaklaşımlar, çevik kalıpların yanı sıra Scrum Agile yöntemi tarafından desteklenen uygulamalardan oluşur.

Bir Donanım Geliştirme Programı Oluşturun

Erken aşamada bir donanım geliştirme programı yapılandırmak, şirketlerin hızlı dönüş veya bir B planı sunmalarını sağladı. İş açısından bakıldığında, finansal marjları azaltabilir, ancak sonunda, sürekli değişen pazarla başa çıkmak için gereken çevikliği sağlar. rekabetin ortaya çıkardığı ürünler ve gelişen teknolojik yetenekler açısından koşullar.

Bir şirketin gömülü yazılımlı donanım ürünü için başarılı bir kitle fonlaması kampanyası yürüttüğünü varsayalım. Büyük bir kurulu şirket benzer bir şey ilan edene kadar ilk ürün partisi için harika çalışıyorlar. Çok yönlülük ve pazara sunma süresi en önemlisidir ve bu duruma pragmatik ve çevik bir yanıt, başarılı bir ürün olasılığını artırır. Şirket, bir donanım geliştirme programına sahip olarak, hızla adapte olabilir ve rakiplerine yanıt olarak ürünün daha zengin bir versiyonunu öne çıkarabilir.

Gömülü Yazılımla Donanımın Başarılı Testi

Test, donanım ürün yönetiminin çok önemli bir bileşenidir, çünkü çevik yazılım testinden farklı olarak, çoğu donanım hatası ancak yeni bir ürün grubu üretilerek giderilebilir. Alev alan Samsung Galaxy Note 7 cihazları, donanım testinin neden tüm ürün yöneticileri için birinci öncelik olması gerektiğine dair harika bir örnek.

İşlevsel testler , gömülü yazılım ürünlerine sahip donanım için teknik doğrulamanın temel amacıdır. Bu prosedürlerin karmaşıklığı, hataların muhtemelen sistemin herhangi bir bölümünden gelmesi gerçeğinden kaynaklanmaktadır.

Simüle edilmiş donanım mükemmel bir şekilde kontrol edilebilir olma avantajını sunduğundan, birim testi genellikle her sprintten sonra simüle edilmiş bir ortamda gerçekleşir. Test komut dosyaları otomatikleştirilebilir, yürütmeyi denetleyebilir ve çökmüş gibi görünen testleri herhangi bir sonuç üretemeyecek şekilde sonlandırabilir.

Entegrasyon testi , çevrimiçi ve çevrimdışı işlemleri ve donanım ürününün gerçek hayattaki operasyonel koşullara sunulmasını hesaba katmalıdır. Örneğin, şirket açık hava etkinlikleri sırasında başa takılan bir beyin izleme sistemi geliştirirse, test koşulları bu özellikleri dikkate almalıdır.

Sistem testi , tüm sistemin hatalar ve hatalar için test edilmesini içerir. Bu test, tüm sistemin (önceden birim ve entegrasyon testi yapılmış) donanım ve yazılım bileşenlerinin arayüzlenmesiyle gerçekleştirilir ve ardından bir bütün olarak test edilir. Bu test, yazılımın kullanıcı tarafından beklenen senaryolar, olası istisnalar ve uç durum koşulları için kontrol edildiği kara kutu test yöntemi altında listelenir. Bahsedilen özel test kategorileri:

• Olayla tetiklenen test: Donanım ürününün ömründeki belirli olaylar veya durum değişiklikleri (örn. başlatma, sıfırlama, kapatma) tarafından başlatılır. Amacı kalıcı hataları tespit etmektir.
• Zaman tetiklemeli test: Sistemin normal çalışmasında önceden yapılandırılmış zamanlarda başlatılır, kalıcı hataları tespit etmek için periyodik olarak yapılır. Önemli test tetikleme olaylarının meydana gelmediği, uzun süreler boyunca çalışan sistemlerde kullanışlıdır. Zamanla tetiklenen test, aralıklı hataları tespit etmek için de kullanışlıdır.

Gömülü Yazılımla Donanımın Ürün Kabulü

Gömülü yazılıma sahip donanım ürünleri için ürün değeri, tipik olarak su sıçraması düşüşü metodolojisindeki ürün kabul adımından sonra doğrulanır. Gömülü yazılım ekosistemine sahip donanım, doğrulama ve kabul için donanıma yazılıma göre öncelik vermelidir. Daha önce belirtildiği gibi, donanım değişikliklerinin gerçekleştirilmesi daha zor ve pahalıdır. Ürün yöneticilerinin, donanımı değiştirememe ve yazılım geliştirme alanında fazladan yinelemeleri tercih etme kısıtlamasını göz önünde bulundurarak kabul sorunlarını çözmek veya değeri ayarlamak için gereken yenilikçi çözümler tasarlaması yaygın bir durumdur.

Mükemmel ürün yöneticileri, iş modelinin sağlam, kabulün sağlam olması ve kullanıcıların ürünü kullanmaktan keyif alması için donanım ihtiyaçlarını tahmin etme ve doğru dahil edilebilir özelliklere öncelik verme konusunda ürün zekasına ve büyük bir vizyon gücüne sahiptir. Gömülü yazılım göz önüne alındığında, donanım geliştirme süreçleri, sertifika prosedürleri, üretim zorlukları ve pazar kabulü tarafından yönlendirilen kurallara ve kısıtlamalara uyması gerektiğinden, donanımın “dekorasyonu” şaşırtıcı olmamalıdır.

Donanım Geliştirme Yönetilen Çeviklik Gerektirir

Çevik, yazılım geliştirme dünyasını fırtına gibi aldı ve şimdi donanım alanına girmeye başladı. Ancak, gömülü yazılım geliştirmeli donanım ürününün koşulları çeşitli zorlukları beraberinde getirir:

• Uzmanlaşmış yetenek eksikliği
• Donanıma uyarlanmamış sürüm kontrol sistemleri
• Yerelleştirilmiş üretim tesisleri
• Yazılımla karşılaştırıldığında yapılması daha zor olan değişiklikler
• Planlama engelleri getiren sertifikasyon ve düzenleme gereksinimleri

Bu zorluklar, yazılım şirketlerinin yaptığı gibi çevik ilkeleri uygulamayı zorlaştırıyor.

Bu zorluklarla mücadele etmek için, su sıçraması düşüşü şeklinde yönetilen bir çeviklik yaklaşımına ihtiyaç vardır. Gömülü yazılım geliştirme, standart scrum prosedürleri izlenerek oluşturulurken, fikir oluşturma, spesifikasyon oluşturma ve test etme gibi diğer adımlar bir şelale kurulumunda uygulanır. Bu, donanım şirketlerinin, yukarıda listelenen çeşitli kısıtlamaları dikkate alması gereken işleyen bir ürün yönetimi yaklaşımını sürdürürken Agile'ın sunduğu ödülleri toplamasına olanak tanır. Bu yönetilen çeviklik yaklaşımı, hızla değişen piyasa koşulları ve sürekli teknolojik gelişmeler bağlamında ileriye doğru başarılı bir yol sağlar.