फर्मवेयर / एम्बेडेड-सिस्टम-सॉफ्टवेयर के विकास के लिए चुस्त कार्यप्रणाली कैसे अपनाएं?

Question

मुझे हमेशा आश्चर्य होता है कि वास्तव में बड़े जटिल एम्बेडेड सिस्टम सॉफ्टवेयर (100+ इंजीनियर) में चुस्त तरीके कैसे लागू होते हैं। फर्मवेयर के विकास में कुछ अनोखी विशेषताएं हैं जो चुस्त करने में मुश्किल करती हैं (यानी हार्डवेयर देव चक्र में देर तक उपलब्ध नहीं है; एक बार उत्पाद जारी होने के बाद, आसानी से फर्मवेयर अपडेट नहीं कर सकते हैं; आदि ...)

इस तरह के विकास में आदर्श मोटे दस्तावेज और भीषण सहकर्मी समीक्षाएं हैं। आप 2-3 हस्ताक्षर के बिना एक चर का नाम बदलने की तरह एक सरल कोड तय नहीं कर सकते। (मैं थोड़ा अतिरंजित करता हूं, लेकिन यह विशिष्ट है। इसके अलावा, बहुत से लोग शॉर्टकट लेते हैं और प्रोजेक्ट मैनेजर भी उन्हें विशेष रूप से कठिन बाजार की समय सीमा के सामने मंजूरी देते हैं।)

मैं फर्मवेयर विकास परियोजनाओं के लिए चुस्त कार्यप्रणाली अपनाने के बारे में कोई सुझाव या दिशानिर्देश सुनना चाहूंगा।

Comments

मैं समझता हूं कि अंतिम हार्डवेयर देर से चक्र में उपलब्ध नहीं है, लेकिन क्या आपके पास प्रोटोटाइप या डिबग हार्डवेयर, एक देव बोर्ड, या कम से कम विक्रेता के सिम्युलेटर के साथ परीक्षण करने के लिए नहीं है? या हम यहाँ खरोंच से शुरू कर रहे हैं?

— केविन वर्मर

मैं अपने एम्बेडेड काम के बारे में एक चुस्त डेवलपर से बात कर रहा था। "हर 6-8 सप्ताह में एक रिलीज!?" उसने कहा। "यह वास्तव में लंबा समय है"। "नहीं, आप मुझे मिस करते हैं," मैंने कहा, "यह 6 से 8 महीने का है "

— AShelly

यह भी देखें stackoverflow.com/questions/4498476/…

— AShelly

मैं उत्सुक हूं कि किस प्रकार के उत्पाद में 100+ एम्बेडेड इंजीनियर हैं?

— पेमदास

@reemrevnivek - आमतौर पर पिछली परियोजनाओं से एक eval बोर्ड है जिसका उपयोग किया जा सकता है। कभी-कभी, वे नए उत्पाद के समान होते हैं। फिर भी, भले ही आपके सभी परीक्षण eval बोर्ड पर गुजर रहे हों, जब आप फर्मवेयर को अंतिम डिवाइस पर चलाते हैं, तो अधिक बार नहीं, परीक्षण टूटेंगे क्योंकि कुछ नई चीजें थीं जिन्हें हार्डवेयर लोगों ने अंतिम मिनट में जोड़ने का फैसला किया था या शायद शुरुआत में हमारे लिए उल्लेख नहीं किया ....

— 21

Answer 1

मुझे लगता है कि दो तकनीकें महत्वपूर्ण हैं:

• हार्डवेयर के लिए एक पूर्ण सिम्युलेटर या परीक्षण-वातावरण विकसित करें, ताकि आप सॉफ़्टवेयर को विकसित कर सकें जैसे कि आपके पास वास्तविक हार्डवेयर है। यहां कंजूसी न करें या शॉर्टकट न लें: एक अच्छा सिम्युलेटर विकसित करना भुगतान करेगा ।

• सिम्युलेटर के खिलाफ बहुत सारे यूनिट परीक्षण लिखें ।

एक बार जब आपके पास ये चीजें चल रही होती हैं, और लोगों को भरोसा होता है कि सिम्युलेटर और यूनिट परीक्षण इस बात का सटीक अंदाजा देंगे कि हार्डवेयर के साथ चीजें कैसे काम करेंगी, तो अन्य फुर्तीली तकनीकों (संक्षिप्त पुनरावृत्तियों, अथक परिशोधन, आदि) को अपनाना आसान होगा। ।

Comments

इसके अलावा, चिप निर्माताओं को सिम्युलेटर कोड का प्रासंगिक हिस्सा प्रदान करें।

— rwong

जब तक आपके पास ये चीजें होती हैं, तब तक एक प्रतियोगी पहले ही भेज चुका होता है

— बिल

यदि आपको 100+ इंजीनियर मिल गए हैं, तो आप निश्चित रूप से अपने प्रतिस्पर्धियों की तुलना में कम समय में एक प्रयोग करने योग्य सिम्युलेटर बना सकते हैं। यह विशेष रूप से सच है यदि आपके प्रतिद्वंद्वियों के पास अपने सॉफ़्टवेयर का परीक्षण करने का कोई तरीका नहीं है जब तक कि वे हार्डवेयर प्राप्त नहीं करते हैं।

— क्रिस्टोफर जॉनसन

हां, मैं मानता हूं कि सिमुलेटर महत्वपूर्ण हैं। तो आप शुरू से ही पूरी प्रणाली को डिजाइन कर रहे हैं कि आप कुशलतापूर्वक परीक्षण योग्य घटकों में सिस्टम को कैसे तोड़ सकते हैं। अब, उन सभी लोगों को फुर्तीले होने के लिए कैसे राजी किया जाए, यह एक और सवाल है ........

— हॉपिया

@ बिल बहुत संभावना है। हालांकि, इसका मतलब है कि उन्होंने एक अनटाइटेड अवर उत्पाद भेज दिया है, और ओपी का उत्पाद उन्हें पानी से बाहर निकाल देगा। ठीक है, कम से कम यह है कि यह कैसे होना चाहिए।

— जूलियो

Answer 2

कई आपूर्तिकर्ताओं को शामिल करने वाली विकास प्रक्रिया पर एजाइल के प्रभाव की तुलना किसी कंपनी के JIT के जाने पर होती है।

JIT डिलीवर करने के लिए, कंपनी के प्रत्येक सप्लायर को JIT डिलीवर करना होता है।

function deliversJIT( company ) { 
    return company.isJIT() && map( deliversJIT, company.suppliers() );
}

इसी तरह, यदि आप चाहते हैं कि एक जटिल उत्पाद को एजाइल पद्धति के अनुसार विकसित किया जाए, तो श्रृंखला में प्रत्येक उपसमूह उस तरह से काम करने में सक्षम होना चाहिए।

'वृद्धिशील' विकास ( 15 साल पहले उर्फ ट्रैसर बुलेट्स ) के संदर्भ में , इसका अर्थ यह होगा कि 'कोर' ड्राइवर के लिए जल्द ही जारी किया जाएगा, और यह कि मूल चालक इंटीग्रेटर के लिए उपलब्ध होगा, और यह कि GUI होगा एक ही समय में एक बटन और एक संपादन बॉक्स के साथ विकसित हो।

कठिन हिस्सा हार्डवेयर डिजाइनरों को आश्वस्त कर रहा है, हमारे टिंकर समाज में शामिल होने के लिए एक ठोस थिंक-अपफ्रंट इंजीनियरिंग अनुशासन से आ रहा है।

दूसरा सबसे कठिन हिस्सा एक ऐसी दुनिया में वृद्धिशील विकास को सक्षम करने का एक तरीका है जहां एक हार्डवेयर प्रिंट को 3 सप्ताह पहले ऑर्डर किया जाना है। मैं एमुलेटर सोच रहा हूँ, यहाँ fpga है। मैं हालांकि एक हार्डवेयर लड़का नहीं हूँ।

यदि आप वृद्धिशील हार्डवेयर विकास को छोड़ने के लिए तैयार हैं, तो आप एक जेआईटी श्रृंखला की सीमाओं पर पसंद कर सकते हैं, एक बफ़रिंग मैकेनिज्म को आगे बढ़ाते हैं जो एजाइल टीमों को आगे बढ़ने की अनुमति देता है।

चलो अंधे नहीं हैं: चंचल को भारी-वजन प्रक्रियाओं से भी निपटना पड़ता है! फुर्तीली टीम को अगले स्प्रिंट में पायथन में अपने जावा कोड बेस को 'रिफ्लेक्टर' करने के लिए न कहें। यह केवल इसलिए है क्योंकि कुछ हिस्से वास्तव में स्थिर हैं कि हम उनके शीर्ष पर अपनी चुस्त चालों को नृत्य कर सकते हैं।

Comments

+1 केवल चुस्त होने के लिए संभव है क्योंकि अंतर्निहित सामान अच्छी तरह से डिज़ाइन किया गया है / किया गया है।

— बिल

Answer 3

चंचल घोषणा: http://agilemanifesto.org/

"व्यक्तियों और प्रक्रियाओं और उपकरणों पर बातचीत"

• और मिलते हैं। कागज कम दबाएं।

"व्यापक प्रलेखन पर काम कर रहे सॉफ्टवेयर"

• प्रोटोटाइप और निर्माण प्रौद्योगिकी spikes जल्दी और अक्सर।

• किसी विनिर्देशन के लिए उधम मचाते रहने के बजाय उपयोगकर्ता की वास्तविक समस्या को हल करें । इसका मतलब है विकासवादी समाधान। यह विचार कि हमें इसे सही बनाना है क्योंकि हम इसे फिर से कभी नहीं बना सकते गलत है। पुनरावृति पर योजना। इसे मार्केटिंग और रोल-आउट रणनीति का हिस्सा बनाएं।

"अनुबंध वार्ता पर ग्राहक सहयोग"

• हाइपर-कॉम्प्लेक्स परिवर्तन-नियंत्रण प्रक्रियाएं ग्राहक को "नहीं" कहने के तरीके हैं।

• नीचे सभी आवश्यकताओं को बंद करना और फिर परिवर्तन नियंत्रण लागू करना "नहीं" कहने का एक और तरीका है।

• यदि आप पहले से ही एक से अधिक रिलीज की योजना बना रहे हैं, तो आप बाद की रिलीज के लिए आवश्यकताओं को अधिक आसानी से टाल सकते हैं। एक बार जब ग्राहक के पास एम्बेडेड सॉफ्टवेयर के साथ डिवाइस होगा, तो अगली रिलीज़ उसकी प्राथमिकताओं में बदल जाएगी।

"एक योजना के बाद बदलने का जवाब"

• जबकि जटिल एकीकरण के लिए एक जटिल योजना की आवश्यकता होती है, समग्र "कार्यक्रम" (या परियोजनाओं का अनुक्रम) कंक्रीट में बहुत जल्दी नहीं डाला जा सकता है।

एक पूरी तरह से चुस्त कार्यप्रणाली (यानी स्क्रैम) एक एम्बेडेड सिस्टम के लिए समझ में नहीं आ सकता है।

हालांकि, एजाइल घोषणापत्र सरल अराजकता की अनुमति के बिना परिवर्तन को संभव बनाने की अनुमति देता है।

Answer 4

एम्बेडेड सिस्टम में घोटाले के साथ मेरा मुद्दा यह है कि कई कार्य करने हैं, विशेष रूप से शुरुआती चरणों में, जो प्रदर्शनकारी नहीं हैं। हमने एक देव बोर्ड के साथ शुरू किया, कोई ओएस, कोई प्रदर्शन, कोई सीरियल कॉम्म्स, आदि। हमारे पास 6 स्प्रिंट के लिए हमारा प्रदर्शन नहीं था।

पहले 4 स्प्रिंट थे: आरटीओएस उठना और काम करना

इन कार्यों में से अधिकांश उपयोगकर्ता कहानियों के लिए अच्छी तरह से अनुकूल नहीं हैं। वास्तव में, पूरे सिस्टम में एकमात्र इंटरफ़ेस सीरियल डिबग मेनू था, जिसे स्प्रिंट 3 में बनाया गया था, इसलिए स्प्रिंट्स के अंत में प्रदर्शित करने के लिए कुछ भी नहीं था। यहां तक ​​कि सीरियल मेनू आंतरिक उपयोग के लिए था और अंत उपयोगकर्ता नहीं था।

बेशक, हमारे द्वारा लिखे गए प्रत्येक वर्ग में संबंधित इकाई परीक्षण होते हैं और हम सभी परीक्षणों के निष्पादन को स्वचालित करने के लिए एक इकाई परीक्षण ढांचे का उपयोग करते हैं।

हमने "उपयोगकर्ता कहानियां" वाक्यांशों को समाप्त किया, जैसे कि, "एक डेवलपर के रूप में ...", जो मैं लक्ष्य प्रक्रिया (www.targetprocess.com) का उपयोग करने में खुश नहीं हूं, लेकिन एक बैकलॉग आइटम की कोई अवधारणा नहीं है जो है एक कार्य या चौका।

मुझे यह सुनना अच्छा लगेगा कि दूसरों ने इन स्थितियों को कैसे संभाला है।