ফার্মওয়্যার / এমবেডড-সিস্টেমস-সফ্টওয়্যার বিকাশের জন্য চতুর পদ্ধতিটি কীভাবে গ্রহণ করা যায়?


17

আমি সর্বদা বিস্মিত হয়েছি কীভাবে চতুর পদ্ধতিগুলি প্রয়োগ করতে হয় তা বড় জটিল এমবেডেড সিস্টেম সফ্টওয়্যার (100+ প্রকৌশলী) এ রয়েছে। ফার্মওয়্যার বিকাশের কিছু অনন্য বৈশিষ্ট্য রয়েছে যা চতুর করতে অসুবিধা সৃষ্টি করে (অর্থাত্ দেব চক্রের শেষ অবধি হার্ডওয়ার পাওয়া যায় না; পণ্যটি প্রকাশিত হয়ে গেলে সহজেই ফার্মওয়্যার আপডেট করতে পারে না ইত্যাদি etc ...)

এই জাতীয় বিকাশের আদর্শটি হ'ল ঘন ডকুমেন্টেশন এবং গুরুতর সমালোচনা সমালোচনা। আপনি 2-3 টি স্বাক্ষর ছাড়াই ভেরিয়েবলের নামকরণের মতো একটি সাধারণ কোড ফিক্স পেতে পারেন না। (আমি কিছুটা অতিরঞ্জিত করি তবে এটি সাধারণ Additionally অতিরিক্তভাবে, প্রচুর লোক শর্টকাট নেয় এবং প্রজেক্ট ম্যানেজারগুলি এমনকি তাদের বিশেষত কঠোর বাজারের সময়সীমার মুখেও অনুমোদন দেয়))

ফার্মওয়্যার ডেভলপমেন্ট প্রকল্পগুলির জন্য চতুর পদ্ধতিটি কীভাবে গ্রহণ করা যায় সে সম্পর্কে আমি কোনও টিপস বা গাইডলাইন শুনতে চাই।


আমি বুঝতে পারি যে চূড়ান্তভাবে হার্ডওয়্যারটি ডি চক্রের শেষ অবধি পাওয়া যায় না, তবে আপনার কি পরীক্ষার জন্য প্রোটোটাইপ বা ডিবাগ হার্ডওয়্যার, একটি ডেভ বোর্ড, বা কমপক্ষে কোনও বিক্রেতার সিমুলেটর নেই? নাকি আমরা এখানে স্ক্র্যাচ থেকে শুরু করছি?
কেভিন ভার্মির

3
আমি আমার এম্বেড করা কাজ সম্পর্কে একজন চটপটে বিকাশকারী সাথে কথা বলছিলাম। "প্রতি 6-8 সপ্তাহে একটি রিলিজ!?!?!" সে বলেছিল. "এটি আসলেই দীর্ঘ সময়"। "না, আপনি আমাকে ভুল বোঝেন না," আমি বলেছিলাম, "এটি 6 থেকে 8 মাস "
অ্যাশেলি


2
আমি এক ধরণের কৌতূহল বোধ করি কোন ধরণের পণ্যটিতে 100+ এম্বেড ইঞ্জিনিয়ার রয়েছে?
পেমদাস

@reemrevnivek - সাধারণত পূর্ববর্তী প্রকল্পগুলি থেকে একটি ইওল বোর্ড ব্যবহার করা যেতে পারে। কখনও কখনও, তারা নতুন পণ্য যথেষ্ট অনুরূপ। তারপরেও, যদিও আপনি সমস্ত চূড়ান্ত ডিভাইসে ফার্মওয়্যারটি চালানোর সময় আপনার সমস্ত পরীক্ষাগুলি ইওল বোর্ডে অতিক্রান্ত হয় তবে প্রায়শই না, পরীক্ষাগুলি ভেঙে যায় কারণ হার্ডওয়ারের ছেলেরা শেষ মুহুর্তে বা সম্ভবত যুক্ত করার সিদ্ধান্ত নিয়েছিল এমন কিছু নতুন জিনিস ছিল শুরুতে আমাদের উল্লেখ করিনি ....
হপিয়া

উত্তর:


10

আমি মনে করি দুটি কৌশল কী:

  • হার্ডওয়্যারটির জন্য একটি সম্পূর্ণ সিমুলেটর বা পরীক্ষার পরিবেশ বিকাশ করুন, যাতে আপনি সফ্টওয়্যারটি বিকাশ করতে পারেন যেন আপনার কাছে সত্যিকারের হার্ডওয়্যার রয়েছে। কার্পণ্য অথবা এখানে শর্টকাট গ্রহণ করবেন না: একটি ভাল কাল্পনিক উন্নয়নশীল হবে মিটান।

  • সিমুলেটারের বিরুদ্ধে প্রচুর ইউনিট পরীক্ষা লিখুন ।

একবার আপনার এই জিনিসগুলি চলে যাওয়ার পরে এবং লোকেরা আত্মবিশ্বাসী যে সিমুলেটর এবং ইউনিট পরীক্ষাগুলি হার্ডওয়্যারের সাথে কীভাবে জিনিসগুলি কাজ করবে সে সম্পর্কে একটি সঠিক ধারণা দেবে, অন্যান্য চতুর কৌশলগুলি গ্রহণ করা সহজ হবে (সংক্ষিপ্ত পুনরাবৃত্তি, নিরলস পুনঃসংশ্লিষ্ট ইত্যাদি)) ।


এছাড়াও, চিপ নির্মাতারা সিমুলেটর কোডের প্রাসঙ্গিক অংশ সরবরাহ করুন।
রওয়ং

আপনার কাছে এই জিনিসগুলি উপস্থিত হওয়ার সময় একজন প্রতিযোগী ইতিমধ্যে পাঠিয়ে দিয়েছেন
বিল

যদি আপনার 100+ প্রকৌশলী পাওয়া যায় তবে আপনি অবশ্যই আপনার প্রতিযোগীদের শিপিংয়ের চেয়ে কম সময়ে একটি ব্যবহারযোগ্য সিমুলেটর তৈরি করতে পারেন। এটি বিশেষত সত্য যদি আপনার প্রতিযোগীদের কাছে হার্ডওয়্যার না পাওয়া পর্যন্ত তাদের সফ্টওয়্যার পরীক্ষা করার কোনও উপায় না থাকে।
ক্রিস্টোফার জনসন 21

হ্যাঁ, আমি সম্মতি দিচ্ছি সিমুলেটরগুলি কী। সুতরাং আপনি সিস্টেমটিকে পরীক্ষারযোগ্য উপাদানগুলির মধ্যে কতটা দক্ষতার সাথে ভেঙে ফেলতে পারবেন তার উপর ভিত্তি করে গোটা সিস্টেমটি শুরু থেকেই ডিজাইন করা হচ্ছে। এখন, কীভাবে এই সমস্ত লোককে চটপটে যেতে রাজি করা যায় তা অন্য প্রশ্ন ........
হোপিয়া

@ বিল এটি খুব সম্ভবত তবে, সম্ভবত এর অর্থ তারা একটি অনির্ধারিত নিকৃষ্ট পণ্য প্রেরণ করেছে, এবং ওপি'র পণ্যগুলি এগুলি তাদের জল থেকে বের করে দেবে। ভাল, কমপক্ষে এটি হওয়া উচিত।
জুলিও

2

একাধিক সরবরাহকারী জড়িত একটি উন্নয়ন প্রক্রিয়াতে Agile এর প্রভাব কোনও সংস্থা JIT এ গেলে কী ঘটে তার সাথে তুলনা করা যেতে পারে।

জেআইটি সরবরাহ করতে, সংস্থার প্রতিটি সরবরাহকারীকে জেআইটি সরবরাহ করতে হবে।

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

তেমনি, আপনি যদি Agile পদ্ধতি অনুসারে একটি জটিল পণ্য বিকাশ করতে চান তবে চেইনের প্রতিটি উপগোষ্ঠী সেভাবে কাজ করতে সক্ষম হবে।

'ইনক্রিমেন্টাল' বিকাশের ক্ষেত্রে ( ১৫ বছর আগে ওরফে ট্রেসার বুলেট ) এর অর্থ এই বোঝা যায় যে 'কোর' চালক লোকটির কাছে খুব শীঘ্রই মুক্তি পেয়েছে, এবং বেসিক ড্রাইভারটি ইন্টিগ্রেটারের জন্য উপলব্ধ হবে এবং জিইউআই হবে বিকাশিত হতে পারে, একই সময়ে একটি একক বোতাম এবং একটি সম্পাদনা বাক্স দিয়ে বেট করুন।

শক্ত অংশটি হ'ল হার্ডওয়্যার ডিজাইনারদেরকে বোঝাতে, একটি শক্ত থিং-আপফ্রন্ট ইঞ্জিনিয়ারিং শৃঙ্খলা থেকে আসা, আমাদের টিঙ্কার সমাজে যোগ দিতে।

দ্বিতীয় শক্তিশালী অংশটি এমন একটি বিশ্বের ক্রমবর্ধমান বিকাশের সক্ষম করার একটি উপায় সন্ধান করছে যেখানে একটি হার্ডওয়্যার প্রিন্ট 3 সপ্তাহ আগে অগ্রিম অর্ডার করতে হয়। আমি অনুকরণকারী ভাবছি, এফপিগা এখানে। আমি যদিও হার্ডওয়ার লোক নই।

আপনি যদি ইনক্রিমেন্টাল হার্ডওয়্যার ডেভলপমেন্ট বাদ দিতে ইচ্ছুক হন, আপনি যেমন একটি জেআইটি চেইনের সীমানার মতো, বাফারিং মেকানিজমটির আশা করতে পারেন যা Agile দলগুলিকে অগ্রসর হতে দেয় to

আসুন অন্ধ হয়ে যাবেন না: চটপটে ভারী ওজন প্রক্রিয়াগুলিও মোকাবেলা করতে হবে! অ্যাগিল টিমকে এখন পরবর্তী স্প্রিন্টে পাইথনের কাছে তাদের জাভা কোড বেসটি 'রিফ্যাক্টর' করতে বলবেন না। এটি কেবলমাত্র কারণগুলির কিছু অংশ সত্যই স্থিতিশীল যে আমরা তাদের উপরে আমাদের চপল পদক্ষেপগুলি নাচতে পারি।


চতুর জন্য শুধুমাত্র +1 সম্ভব কারণ অন্তর্নিহিত স্টাফগুলি পুরোপুরি ডিজাইন / সম্পন্ন হয়েছে।
বিল

1

চতুর ম্যানিফেস্টো: http://agilemanifesto.org/

"প্রক্রিয়া এবং সরঞ্জামগুলির উপর ব্যক্তি এবং ইন্টারঅ্যাকশন"

  • আরও দেখা। পেপার কম ঠেলা।

"বিস্তৃত ডকুমেন্টেশন ওভার সফ্টওয়্যার"

  • প্রোটোটাইপ এবং বিল্ড প্রযুক্তি স্পাইকগুলি প্রথম এবং প্রায়শই তৈরি করা হয়।

  • কোনও স্পেসিফিকেশনের আনুগত্যপূর্ণ আনুগত্যটি চালিয়ে যাওয়ার চেয়ে ব্যবহারকারীর আসল সমস্যাটি সমাধান করুন । এর অর্থ বিবর্তনীয় সমাধান। আমাদের এটিকে সঠিকভাবে গড়ে তুলতে হবে এই ধারণাটি কারণ আমরা এটি আর কখনও তৈরি করতে পারি না wrong পুনরাবৃত্তি উপর পরিকল্পনা। এটিকে বিপণনের অংশ এবং রোল-আউট কৌশলের তৈরি করুন।

"চুক্তি সমঝোতার বিষয়ে গ্রাহকের সহযোগিতা"

  • হাইপার-জটিল পরিবর্তন-নিয়ন্ত্রণ প্রক্রিয়াগুলি গ্রাহককে "না" বলার কেবল উপায়।

  • লক ডাউন সমস্ত প্রয়োজনীয়তা সামনে এবং তারপরে পরিবর্তন নিয়ন্ত্রণ চাপানো "না" বলার আর একটি উপায়।

  • যদি আপনি ইতিমধ্যে একাধিক রিলিজের পরিকল্পনা করেন তবে আপনি পরবর্তী রিলিজের চেয়ে আরও সহজে প্রয়োজনীয়তা মুলতবি করতে পারেন। এম্বেডড সফ্টওয়্যার সহ গ্রাহকের ডিভাইসটি একবার হয়ে গেলে, পরবর্তী প্রকাশটি তার অগ্রাধিকারগুলিতে পরিবর্তিত হবে।

"একটি পরিকল্পনা অনুসরণ করে পরিবর্তনের প্রতিক্রিয়া"

  • জটিল ইন্টিগ্রেশনের জন্য জটিল পরিকল্পনা প্রয়োজন, সামগ্রিক "প্রোগ্রাম" (বা প্রকল্পের ক্রম) খুব শীঘ্রই কংক্রিটে কাস্ট করা যাবে না।

একটি সম্পূর্ণ চতুর পদ্ধতি (যেমন স্ক্রাম) এম্বেড থাকা সিস্টেমটির জন্য অর্থবোধ করতে পারে না।

তত্পরতা ইশতেহারে, সরল বিশৃঙ্খলা না দিয়ে পরিবর্তন সম্ভব হওয়ার উপায় সরবরাহ করে।


0

এম্বেড থাকা সিস্টেমে স্ক্র্যামের সাথে আমার সমস্যাটি হ'ল, অনেকগুলি কাজ করার আছে, বিশেষত প্রাথমিক পর্যায়ে, যা প্রদর্শনযোগ্য নয়। আমরা একটি ডেভ বোর্ড দিয়ে শুরু করেছি, কোনও ওএস, কোনও প্রদর্শন, কোনও সিরিয়াল কমস ইত্যাদি 6 টি স্প্রিন্টের জন্য আমাদের প্রদর্শন নেই।

প্রথম 4 টি স্প্রিন্টগুলি ছিল: আরটিওএস প্রস্তুত করা এবং চালানো কাজ তৈরি করা নেটওয়ার্ক এবং সিরিয়াল ড্রাইভারগুলি লিখন বোতাম, কমস ইত্যাদির জন্য বাধা রুটিন রচনা প্রাথমিক ডাটাবেস ক্লাস এবং পদ্ধতিগুলি লিখে একটি সিরিয়াল ডিবাগ মেনু রচনা

এই কাজের বেশিরভাগ ব্যবহারকারীর গল্পের জন্য উপযুক্ত নয়। প্রকৃতপক্ষে, পুরো সিস্টেমের একমাত্র ইন্টারফেস ছিল সিরিয়াল ডিবাগ মেনু, স্প্রিন্ট 3-এ নির্মিত তাই স্প্রিন্টের শেষে প্রদর্শন করার মতো কিছুই ছিল না। এমনকি সিরিয়াল মেনুটি কোনও অন্তর্গত ব্যবহারকারীর জন্য নয় অভ্যন্তরীণ ব্যবহারের জন্যই ছিল।

অবশ্যই, আমরা প্রতিটি ক্লাসে লিখিত ইউনিট পরীক্ষাগুলি যুক্ত করেছি এবং আমরা সমস্ত পরীক্ষার প্রয়োগটি স্বয়ংক্রিয় করতে একটি ইউনিট পরীক্ষার কাঠামো ব্যবহার করি।

আমরা "ব্যবহারকারীর গল্প" বাক্যাংশগুলি লিখেছিলাম, যেমন "বিকাশকারী হিসাবে ...", যা আমি সন্তুষ্ট নই তবে টার্গেট প্রক্রিয়া (www.targetprocess.com) ব্যবহার করার ক্ষেত্রে, ব্যাকলগ আইটেমটির কোনও ধারণা নেই যা একটি কাজ বা কাজ

অন্যরা কীভাবে এই পরিস্থিতিগুলি পরিচালনা করেছে তা শুনতে আমি পছন্দ করি।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.