أجهزة رشيقة مع تطوير برامج مضمنة

يعد بناء أنظمة معقدة للأجهزة والبرامج التي تجد المنتج / السوق مناسبة مهمة صعبة. في حين أن معظم الشركات الناشئة في مجال الأجهزة تفشل في نهاية المطاف بسبب نفاد الأموال ، وفقًا لتقرير صادر عن CB Insights ، فإن السبب الأساسي الأكبر هو في الواقع نقص الطلب على منتجاتها. هذا يؤكد فقط على أهمية مدى أهمية دور مدير المنتج في بدء تشغيل الأجهزة ، حيث أن هدفهم الأساسي هو معرفة احتياجات العميل ونقاط الضعف من أجل تقديم منتج ناجح.

أنشأت آخر شركة قمت بتشغيلها نظامًا بيئيًا للويب والجوّال وتطبيقات البرامج المضمّنة والأجهزة اللازمة لصناعة مواقف السيارات. كانت إستراتيجية منتجات الأجهزة جزءًا من عملي اليومي ، مما دفعني إلى إجراء تجارب مع مختلف عمليات سير عمل تطوير منتجات الأجهزة. على الرغم من العمل مع منتجات الأجهزة لمدة 10 سنوات وحصلت على درجة البكالوريوس في الإلكترونيات والاتصالات ، لا يزال لدي الكثير لأتعلمه في الوظيفة. لقد أنشأت الدليل أدناه على أمل أن تتمكن من الحصول على سرعة في إدارة المنتج داخل الأجهزة مع مساحة البرامج المضمنة بشكل أسرع مما فعلت.

تحديات إدارة منتجات الأجهزة

بينما يمكن بسهولة تطوير SaaS وتطبيقات الأجهزة المحمولة باستخدام إطار عمل رشيق ، فإن الظروف الفريدة في تطوير البرامج والأجهزة المدمجة تجعل من الصعب جدًا تطبيق مبادئ Agile. في هذا القسم الأول ، سنغطي خصائص تطوير الأجهزة التي تخلق التعقيد. ليس كل منهم لديهم حلول مباشرة ، ولكن هناك طرق لتقليل الصعوبة من خلال استخدام استراتيجيات معينة لتطوير الأجهزة ، والتي سيتم تناولها في القسم التالي.

يصعب العثور على المواهب الفنية المتخصصة محليًا

يعد إنشاء منتجات أجهزة جديدة أصعب بكثير من التكرار على المنتجات الحالية. إنه ينطوي على الكثير من الإبداع والخبرة في النماذج الأولية ، والتي نادرًا ما يتم تدريسها في الجامعات. لا تمتلك بعض الجامعات حتى منشآت النماذج الأولية أو الأدوات اللازمة لتطوير هذه المهارات ، وهذه الخبرة تكاد تكون حصرية في شركات الأجهزة الكبيرة التي لديها مراكز للبحث والتطوير. لذلك ، قد يكون العثور على محترفين محليين يتمتعون بالخبرة المناسبة أمرًا صعبًا للغاية ، مما يؤدي إلى حاجة الكثير من مؤسسي بدء تشغيل الأجهزة إلى توسيع مجموعة مواهبهم من خلال التوظيف عن بُعد.

لا تتكيف أنظمة التحكم في الإصدار مع تصميم الأجهزة

معظم أنظمة التحكم في الإصدار (VCS) موجهة لدعم التنسيق النصي ، حيث تم إنشاؤها للعمل التعاوني لتطوير البرامج. في المشاريع التي تتضمن تطوير الأجهزة ، يتم تغليف المعلومات بدلاً من ذلك في ملفات تصميم تم إنشاؤها بمساعدة أدوات خاصة مثل OrCAD. وبعض هذه الأدوات تدعم فقط الملفات الثنائية التي لم يتم تحسينها لاستخدامها في VCSs. CADLAB هي محاولة جديدة نسبيًا لإنشاء VCS متوافق مع الأجهزة ونأمل أن يكون هناك المزيد من الأدوات مثل هذه في المستقبل القريب.

يتم تحديد مواقع مرافق إنتاج الأجهزة

غالبًا ما توجد مرافق إنتاج الأجهزة في منطقة أو بلد أو قارة أخرى. يحتاج الاتصال بين منتج الأجهزة والشركة المصنعة إلى اعتبار خاص وهو مفتاح التسليم الناجح للمنتج. يتطلب الاتصال الناجح تأطيرًا استراتيجيًا أكثر لضمان جودة المنتج ولضمان قدرته على التعامل مع التغييرات في مرحلة التحقق من صحة المنتج الديناميكي. لتحقيق ذلك ، يحتاج منتج الأجهزة إلى إنشاء العديد من المواصفات التفصيلية المرسلة إلى الشركة المصنعة. يجب أن يضمن إطار عمل التعاون التسليم السريع للمعلومات وإدارة دورة حياة المواصفات ، حيث يمكن بسهولة أن تصبح قديمة بسرعة.

تغييرات الأجهزة أقل مرونة

نموذج التشغيل المشهور في الشركات الناشئة البرمجية يضحي بالجودة من أجل السرعة في المراحل المبكرة. حتى Facebook دافع عن شعار "تحرك بسرعة وحطم الأشياء" لبعض الوقت. نهج آخر مألوف هو "زيفه" حتى تقوم به. " يعمل هذا مع بدء تشغيل البرامج بسبب تكاليف البنية التحتية الرخيصة وأطر البرمجة المبسطة التي تسمح للمطورين بنشر تحديثات التعليمات البرمجية يوميًا.

في حين أن هذا النهج في التطوير قد تسلل ببطء إلى مساحة الأجهزة ، إلا أنه اتجاه مؤسف في هذا المجال ، حيث يصعب إجراء ونشر تغييرات الأجهزة. عوضت تكاليف التطوير القيمة المكتسبة من خلال الإصدارات السريعة والمتكررة ، لذلك من المرغوب فيه أكثر بكثير أن تستثمر أكثر في مرحلة التصميم لإنشاء بنى أجهزة سليمة.

مأزق التمويل الجماعي

العديد من الشركات الناشئة محاصرة في فكرة أن إطلاق حملة تمويل جماعي ناجحة للأجهزة يعادل التحقق من صحة السوق. يميل التمويل الجماعي إلى أن يكون أكثر نجاحًا بالنسبة للمنتجات التي تتضمن مكونًا للأجهزة ، لا سيما بسبب رغبتنا غير الواعية في الملكية المتعلقة بالكائن المادي. ومع ذلك ، لا يُقصد بالتمويل الجماعي التحقق من صحة منتجك على نطاق واسع ، ولكنه طريقة ديمقراطية لتمويل تطوير المنتج في المراحل المبكرة. الحقيقة المؤسفة هي أن العديد من الشركات التي لديها حملات تمويل جماعي ناجحة وجدت في وقت لاحق أنه من الصعب أو شبه المستحيل توسيع نطاق إنتاجها لأنها لم تتحقق من صحة أسواقها على نطاق واسع.

الشهادات واللوائح والموافقات

تتطلب جميع منتجات الأجهزة نوعًا من الشهادات ليتم بيعها. إنها واحدة من أكثر الخطوات التي يتم التغاضي عنها في المراحل المبكرة جدًا لطرح منتجات الأجهزة في السوق. كيف سيؤثر قيد الشهادة على خطة المنتج والإطار المطبق للتطوير؟ ليس من غير المألوف التخطيط للمراحل المبكرة من المشروع بشهادة وموافقات أخرى كمحطة رئيسية للمشروع ، وعندها فقط يمكنك التراجع بشكل مشروط إلى مرحلة الانطلاق. يمكن لمديري المنتجات بدلاً من ذلك تحليل اللوائح والتبعيات وبوابات القرار الإستراتيجي لخطة المنتج بعناية في نهج يشبه الشلال.

فرص إدارة منتجات الأجهزة

الآن بعد أن قمنا بتغطية بعض التحديات الموجودة في الأجهزة مع مجال البرمجيات المضمن ، فلنلقِ نظرة الآن على كيفية جعل عملية التطوير أكثر بساطة وقابلية للتنبؤ من أجل تعويض الصعوبات الكامنة في تطوير الأجهزة.

دمج Agile في تطوير الأجهزة

يدرك مديرو المنتجات المتمرسون التحديات الكامنة وراء إنشاء منتجات الأجهزة باستخدام البرامج المضمنة التي تحاول استغلال فرصة السوق التي أوجدتها التطورات التكنولوجية الجديدة. يتعلمون الموازنة بين تسريع وقت الوصول إلى السوق دون المساس باحتمالية نجاح المنتج من مرحلة التخطيط. في معظم الأحيان ، يتشكل هذا من خلال نهج Water-scrum-Fall.

توسع مرحلة التفكير في المنتج مبادئ المنتج والأهداف والميزات عالية المستوى بأكبر قدر ممكن من التفاصيل. يقضي مديرو المنتجات الرائعون مزيدًا من الوقت في تحسين مخرجات هذه المرحلة: الرؤية ، والرسالة ، وتقييم الفرصة ، وأهداف منتجات الأجهزة ، والميزات. هذا هو النجم الشمالي للمنتج الذي يحتاج إلى أن يكون واضحًا بدرجة كافية قبل البدء في العمل على أي نوع من النماذج الأولية للأجهزة ، ومن ثم يوصى باتباع نهج الشلال.

من الأهمية بمكان أن يكون لديك متطلبات موثقة جيدًا ومواصفات وظيفية لمنتجات الأجهزة ، بالإضافة إلى بنية تقنية جيدة للبرنامج المضمن الذي يقود منتج الأجهزة. يجب معاقبة التغييرات في المتطلبات والمواصفات ، وليس تشجيعها بمجرد توقيعها من قبل الفريق بأكمله.

يمكن استخدام منهجية سكروم القياسية عند تطوير البرامج المضمنة. يعد ضبط وصقل تنفيذ البرامج من أجل العمل مع بنية الأجهزة المحددة مسبقًا أقل تكلفة من العكس بالعكس من حيث الوقت والمال.

يجب إجراء اختبار التكامل النهائي واختبار قبول المستخدم في ظروف الشلال. في هذه المرحلة ، تكتمل مرحلة التطوير ويتم تسجيل الوظائف الجديدة والميزات المفقودة كطلبات عمل إضافية لفترة التخطيط التالية.

دمج Agile في تطوير البرامج المضمنة

يؤثر بناء منتجات الأجهزة المعقدة باستخدام البرامج المضمنة على كيفية تطبيق منهجيات تطوير البرامج التقليدية. العديد من الأنظمة المستخدمة لإنتاج البرامج التي يتم تشغيلها على جهاز كمبيوتر شخصي غير مناسبة لتطوير البرامج المضمنة ، نظرًا لوجود قيود فيما يتعلق بندرة الموارد ودورات حياة التطوير الأطول بكثير.

قدمت مجموعة من الأكاديميين والمهنيين من البرازيل حلاً محتملاً: منهجية تصميم البرامج القائمة على النظام الأساسي لأنظمة التحكم المضمنة: مجموعة أدوات رشيقة . تدمج هذه المنهجية مبادئ أجايل في تطوير البرامج المضمنة. يوجد أدناه ملخص قصير للمنهجية ، ولكن يُنصح بشدة مديري منتجات الأجهزة بقراءة الوصف الكامل قبل تطبيقه في ممارساتهم.

الأدوار التي تنطوي عليها هذه المنهجية هي:

• مالك المنصة - مسؤول عن تحديد أهداف الجودة والتخطيط والتكلفة
• قائد المنتج - مسؤول عن التنفيذ والتكامل واختبار المنتج
• قائد الميزة - مسؤول عن إدارة مشاريع النظام الفرعي وتتبع تقدم الميزة القابلة للتسليم
• فريق التطوير - العمل على تطوير المنتج

تقسم المنهجية تطوير البرامج المضمنة إلى ثلاث مجموعات عملية:

1. مجموعة عمليات منصة النظام. يختار النظام مكونات النظام التي ستكون جزءًا من البنية الأساسية والأنظمة الأساسية لواجهة برمجة التطبيقات من مكتبة النظام الأساسي ويقوم بتخصيصها لتلبية قيود التطبيق المعني. يتم تنفيذ عملية التخصيص في دورات تكرارية عن طريق برمجة المعالجات القابلة للتكوين من قبل المصمم والمنطق القابل لإعادة التكوين لوقت التشغيل المدمج في النظام الأساسي.
2. مجموعة عمليات تطوير المنتج. يتم تقسيم الوظائف التي يتكون منها المنتج إلى عناصر أجهزة أو برامج في النظام الأساسي. توفر المنهجية خوارزميات التقسيم لمراعاة استهلاك الطاقة ووقت التنفيذ وحجم الذاكرة لمكونات التطبيق.
3. تراقب مجموعة عمليات إدارة المنتج وتتحكم في نطاق المنتج والوقت والجودة ومعلمات التكلفة. تتكون الأساليب المقترحة بشكل أساسي من الممارسات التي يتم الترويج لها بواسطة طريقة Scrum Agile بالإضافة إلى الأنماط الرشيقة.

قم بإنشاء برنامج تطوير الأجهزة

مكنت هيكلة برنامج تطوير الأجهزة في مرحلة مبكرة الشركات من توفير التمحور السريع أو الخطة ب. الشروط من حيث المنتجات الصادرة عن المنافسة وتطوير القدرات التكنولوجية.

لنفترض أن إحدى الشركات تدير حملة تمويل جماعي ناجحة لمنتج أجهزتها مع برنامج مدمج. إنهم يعملون بشكل رائع تجاه الدفعة الأولى من المنتجات حتى تعلن شركة كبيرة راسخة عن شيء مشابه. تعد تعددية الاستخدامات ووقت التسويق أمرًا مهمًا ، كما أن الاستجابة العملية والفعالة لهذا الموقف تزيد من احتمالية نجاح منتج ما. من خلال وجود برنامج لتطوير الأجهزة ، يمكن للشركة أن تتكيف بسرعة وتضع في دائرة الضوء نسخة أكثر ثراءً من المنتج كاستجابة لمنافسيها.

اختبار ناجح للأجهزة باستخدام البرامج المضمنة

يعد الاختبار مكونًا مهمًا لإدارة منتجات الأجهزة لأنه ، على عكس اختبار البرامج الرشيقة ، لا يمكن إصلاح معظم أخطاء الأجهزة إلا من خلال إنتاج مجموعة جديدة من المنتجات. تعتبر أجهزة Samsung Galaxy Note 7 التي كانت تشتعل فيها النيران مثالًا رائعًا على أهمية اختبار الأجهزة كأولوية قصوى لجميع مديري المنتجات.

الاختبارات الوظيفية هي الهدف الرئيسي للتحقق الفني للأجهزة مع منتجات البرامج المضمنة. يأتي تعقيد هذه الإجراءات من حقيقة أن الأخطاء من المحتمل أن تأتي من أي جزء من النظام.

عادةً ما يحدث اختبار الوحدة في بيئة محاكاة بعد كل سباق ، حيث توفر الأجهزة المحاكاة ميزة كونها قابلة للتحكم تمامًا. يمكن أتمتة نصوص الاختبار ، ويمكن الإشراف على التنفيذ ، وقتل الاختبارات التي يبدو أنها تعطلت بسبب فشلها في تحقيق أي نتائج.

يجب أن يأخذ اختبار التكامل في الاعتبار العمليات عبر الإنترنت وغير المتصلة بالإنترنت وتقديم منتج الأجهزة إلى ظروف التشغيل الواقعية. على سبيل المثال ، إذا طورت الشركة نظامًا لمراقبة الدماغ مثبتًا على الرأس أثناء الأنشطة الخارجية ، فيجب أن تراعي ظروف الاختبار هذه الخصائص.

يتضمن اختبار النظام اختبار النظام بأكمله بحثًا عن الأخطاء والأخطاء. يتم إجراء هذا الاختبار عن طريق الربط بين مكونات الأجهزة والبرامج للنظام بأكمله (التي تم اختبارها مسبقًا من قبل الوحدة والتكامل) ثم اختبارها ككل. تم إدراج هذا الاختبار ضمن طريقة اختبار الصندوق الأسود ، حيث يتم فحص البرنامج بحثًا عن السيناريوهات التي يتوقعها المستخدم والاستثناءات المحتملة وظروف حالة الحافة. فئات الاختبار الخاصة التي يمكن ذكرها:

• الاختبار الذي يتم تشغيله بواسطة الأحداث: يتم البدء فيه بواسطة أحداث معينة أو تغييرات الحالة في عمر منتج الجهاز (على سبيل المثال ، بدء التشغيل ، إعادة التعيين ، إيقاف التشغيل). هدفه هو الكشف عن العيوب الدائمة.
• اختبار وقت التشغيل: يبدأ في أوقات محددة مسبقًا في التشغيل العادي للنظام ، ويتم إجراؤه بشكل دوري لاكتشاف الأعطال الدائمة. إنه مفيد في الأنظمة التي تعمل لفترات طويلة ، حيث لا تحدث أحداث اختبار مهمة. يعد الاختبار الذي يتم تشغيله بمرور الوقت مفيدًا أيضًا في اكتشاف الأخطاء المتقطعة.

قبول المنتج للأجهزة مع البرامج المضمنة

عادةً ما يتم التحقق من صحة قيمة المنتج لمنتجات الأجهزة ذات البرامج المضمنة بعد خطوة قبول المنتج في منهجية Water-scrum-Fall. يجب أن تعطي الأجهزة ذات النظام البيئي للبرامج المضمنة الأولوية للأجهزة على البرامج للتحقق من الصحة والقبول. كما ذكرنا سابقًا ، تعد تغييرات الأجهزة أكثر صعوبة وتكلفة في الأداء. من الشائع لمديري المنتجات أن يتخيلوا حلولًا مبتكرة ، مطلوبة لحل مشاكل القبول أو ضبط القيمة من خلال النظر في قيود عدم القدرة على تغيير الأجهزة وتفضيل التكرارات الإضافية في مجال تطوير البرمجيات.

يتمتع مديرو المنتجات المتميزون بفطنة المنتج والقدرة العظيمة للرؤية في التنبؤ باحتياجات الأجهزة وتحديد أولويات الميزات القابلة للتضمين الصحيحة بحيث يكون نموذج العمل سليمًا ، والقبول قويًا ، ويستمتع المستخدمون باستخدام المنتج. بالنظر إلى البرامج المضمنة ، لا ينبغي أن تكون "زخرفة" الأجهزة مفاجئة ، لأنها تحتاج إلى اتباع القواعد والقيود ، مدفوعة بعمليات تطوير الأجهزة ، وإجراءات الاعتماد ، وتحديات الإنتاج ، وقبول السوق.

يتطلب تطوير الأجهزة خفة الحركة المُدارة

استحوذت Agile على عالم تطوير البرمجيات عن طريق العاصفة وبدأت الآن تتسلل إلى مساحة الأجهزة. ومع ذلك ، فإن شروط منتج الأجهزة مع تطوير البرامج المضمنة تنطوي على تحديات مختلفة:

• عدم وجود المواهب المتخصصة
• أنظمة التحكم في الإصدار التي لم يتم تكييفها مع الأجهزة
• مرافق الإنتاج غير المحلية
• التغييرات التي يصعب إجراؤها مقارنة بالبرنامج
• متطلبات الاعتماد والتنظيم التي تفرض عقبات التخطيط

تجعل هذه التحديات من الصعب تطبيق مبادئ أجايل بنفس الطريقة التي تقوم بها شركات البرمجيات.

من أجل مواجهة هذه التحديات ، هناك حاجة إلى نهج رشاقة منظم في شكل سقوط الماء. يتم إنشاء تطوير البرامج المضمنة باتباع إجراءات سكروم القياسية ، بينما يتم تنفيذ خطوات أخرى مثل التفكير وإنشاء المواصفات والاختبار في إعداد شلال. يتيح ذلك لشركات الأجهزة جني المكافآت التي تقدمها Agile مع الحفاظ على نهج إدارة منتج فعال يجب أن يأخذ في الاعتبار القيود المختلفة المذكورة أعلاه. يوفر نهج الرشاقة المُدار هذا طريقة ناجحة للمضي قدمًا في سياق ظروف السوق سريعة التغير والتحسينات التكنولوجية المستمرة.