আপনি বড় এমবেডড প্রকল্পগুলি কীভাবে গঠন করবেন? [বন্ধ]


21

পটভূমি :

জুনিয়র আর অ্যান্ড ডি ইলেকট্রনিক্স ইঞ্জিনিয়ার ( সংস্থার একমাত্র EE ) - হার্ডওয়্যার এবং কোডিং কোনও সমস্যা নয়। আমার বৃহত্তম সমস্যাটি প্রকল্পটির একটি সঠিক ওভারভিউ পাচ্ছে এবং কোথায় শুরু হবে।

এখন পর্যন্ত আমি কেবলমাত্র ছোটখাটো সফ্টওয়্যার প্রকল্প তৈরি করেছি (কোডের উপ-লাইন)

বৃহত্তর এমবেডেড সফ্টওয়্যার সিস্টেমগুলি গঠনের জন্য আপনি কীভাবে সেরা কাঠামো / কী সরঞ্জামগুলি ব্যবহার করেন?

আমি বর্তমানে যা করছি :

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

আমি কী উত্তর খুঁজছি :

যেকোনো কিছু. আমি যেটাকে বুদ্ধিমান মনে করব তা বাছাই করব। এটি কোনও বই, একটি নিবন্ধ, ব্যক্তিগত অভিজ্ঞতা, প্রস্তাবনা ইত্যাদি হতে পারে

সিনিয়ররা কীভাবে এটি মোকাবেলা করে তা জানতে আমি খুব আগ্রহী।


সম্পাদন করা

প্রথমে, আপনার বছরের অভিজ্ঞতা ভাগ করে নেওয়ার জন্য আপনাকে ধন্যবাদ! সমস্ত উত্তর অনেক প্রশংসা করা হয়। এ থেকে আমার গ্রহণ;

  • একটি স্পষ্ট এবং সুনির্দিষ্ট স্পেসিফিকেশন ডকুমেন্ট তৈরি করুন।
  • একটি সফ্টওয়্যার নকশা নথি তৈরি করুন। (আমি এখন কিছু যুক্ত করব) ডিজাইন ডক টেম্পলেট
  • মডিউলগুলি কতটা অপ্রয়োজনীয় মনে হতে পারে তা ভাবেন। (আমার আরও কিছু বিষয়ে ফোকাস করার দরকার আছে)
  • শিরোনাম / উত্স ফাইলগুলি গঠনের জন্য একটি কোডিং মান অনুসরণ করুন। (এটি কখনই করেনি) বার গ্রুপ সি স্ট্যান্ডার্ড
  • প্রথমে নিম্ন স্তরের বাস্তবায়ন তৈরি করার দিকে মনোনিবেশ করুন। (যোগাযোগ ইত্যাদি)
  • যেখানেই সম্ভব / বোধগম্য ডিজাইনের ধরণগুলি প্রয়োগ করুন। নকশা নিদর্শন
  • পুনর্বিবেচনা নিয়ন্ত্রণের জন্য কিছু সেট আপ করুন (গিথুব ইত্যাদি - এটি কখনই ব্যবহার করেননি)
  • সিআই ও সিডি বুনিয়াদি গবেষণা অবিচ্ছিন্ন ইন্টিগ্রেশন / অবিচ্ছিন্ন স্থাপনা (নতুন কিছু আমি হোঁচট খেয়েছি )

4
এই প্রশ্নটি এখানে অন্তর্গত নয় ... হতে পারে সফটওয়্যারেনজিনিয়ারিং.স্ট্যাকেক্সেঞ্জ
ডটকম

11
সম্ভবত এই প্রশ্নটি এখানে অন্তর্গত। আমি কয়েক দশক আগে একাধিক-চিপ ডিজাইন দলকে সম্মতি জানাই এবং আমরা প্রতিটি চিপকে বিভিন্ন ফাংশনগুলিতে দ্রবীভূত করে এবং তারপরে (নতুনদের একটি দল, অনুপ্রাণিত, তবে নবাগতদের একটি দল) বোঝার জন্য প্রয়োজনীয় সপ্তাহগুলি অনুমান করে / 60+ ফাংশনের প্রতিটি ডিজাইন / পরীক্ষা / পর্যালোচনা। এমনকি আমরা মূল পরিচালন-আরোপিত তফসিলটি পূরণ করি নি, পরিচালনা ধৈর্যশীল কারণ তারা সহজেই progress০+ ফাংশনগুলির মধ্য দিয়ে অগ্রগতি ট্র্যাক করতে পারে যা আমরা জানতাম যে আমাদের ডিজাইন করার দরকার হয়েছিল এবং তারপরে সংহত করার দরকার।
এনালগ সিস্টেমেসফ

13
@ সোয়ানন্দ আমি একমত নই অন ​​টপিক এফএকিউতে "[প্রশ্ন সম্পর্কে ...] বেয়ার-মেটাল বা আরটিওএস অ্যাপ্লিকেশনগুলির জন্য ফার্মওয়্যার লেখার জন্য" বলা হয়েছে - আমি অবশ্যই এটির পরিকল্পনার পর্যায় অন্তর্ভুক্ত করব। প্রশ্নটিতে বিশেষত "বৃহত্তর এমবেডেড সিস্টেমগুলি" বলা হয়েছে।
আরাহো

2
ফার্মওয়্যার প্রোগ্রামিংটি এখানে বিষয়বস্তুতে থাকা অবস্থায়, কোনও প্রশ্ন খুব বেশি বিস্তৃত এবং মতামত ভিত্তিক কিনা তা দেখার একটি ভাল উপায় হ'ল স্বল্প সময়ের মধ্যে উত্তরগুলির সংখ্যা। এটি অবশ্যই খুব বিস্তৃত। সহায়তা বিভাগটি "যদি কোনও বই লিখতে পারে .." এর মতো কিছু বলে, এবং এ সম্পর্কে বই লেখা হয়েছে!
পাইপ

2
ওপি একটি ভাল সারাংশ তৈরি করেছে। আমি কেবল তাদের জোর দিয়ে বলতে চাই যে গিটহব্বই গিট সংগ্রহস্থল চালানোর একমাত্র উপায় নয়। আপনি একটি স্থানীয় গিট সার্ভার চলমান বা ছাড়া স্থানীয়ভাবে এটি করতে পারেন। গিট সোর্স কন্ট্রোল সিস্টেম (এসসিএস) / ভার্সন কন্ট্রোল সিস্টেমের (ভিসিএস) একমাত্র রূপ নয় তবে এটি এখন একটি খুব জনপ্রিয় popular যখন আমি প্রচুর সি এবং সি ++ প্রশিক্ষণ নিয়ে ইই হিসাবে শুরু করি তখন আমার কাছে এ জাতীয় জিনিসের শূন্য এক্সপোজার ছিল।
টিএফটি

উত্তর:


23

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

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

সিস্টেমের সীমানা এবং রক্ষণাবেক্ষণ এম্বেড থাকা সিস্টেমে আপনার প্রায়শই কিছু সিস্টেম ইন্টারফেস থাকে, কিছু বাইরে (অপারেটর) তবে অভ্যন্তরে থাকে। এগুলি ভালভাবে সংজ্ঞায়িত করুন এবং নির্ভরতা যতটা সম্ভব কম রাখার চেষ্টা করুন এটি ক্রমাগত ইঞ্জিনিয়ারিং এবং রক্ষণাবেক্ষণকে সহজ করবে। কমেন্ট / ডকুমেন্ট কোড যেখানে প্রয়োজন সেখানে আপনি কখনই জানেন না যে এর সাথে অন্য কার কাজ করবে, (গুলি) কোনও ফাংশন কী করে তা জানার আগে কোডের কয়েক ডজন স্তর খনন করতে না পেরে তিনি খুশি হবেন।

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

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

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


3
বিশেষত প্রয়োজনীয়তা! এমন কোনও পণ্য বা ফাংশন তৈরির মতো কিছুই যা ভুল কাজ করে।
কনসার্নড

13

হাম্পাওম্পা লিখেছেন দারুণ উত্তর ! আমি কেবল তার কয়েকটি বিষয় পরিপূরক করতে চাই, তবে যেহেতু এটি মন্তব্য করা খুব দীর্ঘ, তাই আমি একটি পৃথক উত্তর লিখব।

আমি একবার ওপি-র পজিশনে ছিলাম - একমাত্র ইই নয়, একমাত্র ইই, যিনি একটি ছোট কোম্পানিতে কোনও এমসিইউ উন্নয়ন করেছিলেন।

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

আমি একটি বিশদ ডেটা ফ্লো ডায়াগ্রাম 1 বজায় রাখতে অনেক সময় ব্যয় করেছি , যা বিভিন্ন মডিউলগুলি কীভাবে তথ্য ভাগ করে নিয়েছিল তা স্পষ্টভাবে দেখায়। কিছু বৈশিষ্ট্যের রিয়েল-টাইম পারফরম্যান্সের ক্ষেত্রে খুব আলাদা প্রয়োজনীয়তা থাকবে; আপনি কীভাবে তথ্য ভাগ করে নেওয়ার বিষয়টি জানেন তা নিশ্চিত করুন। চিত্রটির চারদিকে সীমানা ছিল যা বিভিন্ন বিঘ্নিত-চালিত ডোমেনগুলি থেকে অ-বিঘ্নিত কোডকে পৃথক করে।


1 একটি ফ্লোচার্ট থেকে খুব আলাদা, যা নিয়ন্ত্রণ প্রবাহে দৃষ্টি নিবদ্ধ করে ।


12

যে কোনও বড় প্রকল্পের জন্য, আমি এটি পরিকল্পনা করছি যেন এতে একাধিক বিকাশকারী জড়িত থাকে যেন আমি একাই এমনকি আমি নিজেও পুরো জিনিসটি করার ইচ্ছা করি।

কারণগুলি সহজ:

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

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

3 বিভাজন। বিভাজনের দুটি প্রাথমিক ধরণ রয়েছে; হার্ডওয়্যার কার্যকারিতা এবং হার্ডওয়্যার / সফ্টওয়্যার। প্রথম ধরণটি কী আলাদা (তবে যোগাযোগের) কার্যকরী ব্লক উপস্থিত থাকতে হবে তা নির্ধারণ করা হয়। দ্বিতীয়টি হ'ল (কখনও কখনও) হার্ডওয়্যার এবং সফ্টওয়্যারটির ট্রেড অফ but কিন্তু মনে রাখবেন যে আরও কিছু জিনিসকে সফ্টওয়্যার এ সরানো অগত্যা কোনও হার্ডওয়্যার সমস্যার সমাধান করবে না। সফ্টওয়্যারটিতে আরও সরানো আসলে কিছু পরিস্থিতিতে হার্ডওয়ার জটিলতা বাড়িয়ে তুলতে পারে (আরও প্রসেসিং হর্স পাওয়ার, আরও জটিল ইন্টারফেস এবং আরও অনেক কিছু)।

4 ইন্টারফেস। বিভাজন প্রক্রিয়া অভ্যন্তরীণ ইন্টারফেস সংজ্ঞায়িত করতে সহায়তা করবে; বাহ্যিক ইন্টারফেসগুলি সাধারণত সামগ্রিক প্রয়োজনীয়তার অংশ (যদিও সর্বদা তা নয়)। আছে অনেক একটি সিস্টেমের বিভিন্ন অংশের জন্য উপায়ে সহযোগিতা একটি জটিল যোগাযোগ প্রোটোকল বা শুধু ভাল / খারাপ সংকেত হতে পারে।

5 যাচাইকরণ। এটি নিম্ন স্তরের পরীক্ষার (হার্ডওয়্যার এবং ড্রাইভারদের জন্য) এবং সিস্টেম স্তরের মিশ্রণ। প্রকল্পটি সুস্পষ্ট সংজ্ঞায়িত ব্লকগুলিতে শক্তিশালী যাচাইয়ের অনুমতি দেয় (যা বিশ্লেষণ বা প্রকৃত পরীক্ষার দ্বারা হতে পারে এবং সাধারণত দুটির সংমিশ্রণ হয়; ডিজাইনের আপডেটগুলি সামঞ্জস্য যুক্তি ব্যবহার করতে পারে)।

6 স্ট্যান্ডার্ড। আমি কোডিং এবং অঙ্কন মান ব্যবহার করি যেন এটি কোনও বৃহত্তর দল। আমি বার গ্রুপের কোডিং মানগুলি ব্যবহার করি কারণ সেগুলি খুব বেশি উত্সাহী নয় তবে কোডে থাকা বহু শ্রেণীর বাগটি আটকাতে পারে। পিসিবি আউটপুট ডকুমেন্টেশনের জন্য আমি আইপিসি-ডি -326 (যা আইপিসি-ডি -325 কল করে) অনুসরণ করি কারণ এটি পিসিবি ফ্যাব্রিকেটর এবং সমাবেশকারীদের সাথে আমার উদ্দেশ্য যোগাযোগ করার একটি প্রমাণিত পদ্ধতি। এটি অদ্ভুত বলে মনে হতে পারে তবে বেশ কয়েকটি মান অনুসরণ করার শৃঙ্খলা থাকার অর্থ মানটি সুসংগত।

7 সংস্করণ নিয়ন্ত্রণ। আমি প্রকল্পের সমস্ত অংশের (সিস্টেম, হার্ডওয়্যার, সফ্টওয়্যার। যান্ত্রিক, পরীক্ষার প্রয়োজনীয়তা - সবকিছু) জন্য সংশোধন নিয়ন্ত্রণ ব্যবহার করি । আমি যে সিএডি সরঞ্জামগুলি ব্যবহার করি সেগুলি সমস্ত সফ্টওয়্যার এবং এফপিজিএ বিল্ড সরঞ্জামগুলির মতো সংস্করণকে সমর্থন করে।

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

এই সমস্ত জিনিসগুলি করা কিছুটা আপ-ফ্রন্ট সময় যোগ করে তবে শেষ পর্যন্ত জটিল এম্বেডড সিস্টেমগুলির জন্য একটি দ্রুত রুট।


5

অন্যান্য উত্তরগুলি অনেক দুর্দান্ত টিপস দেয়। এখানে দুটি রয়েছে যা আমি আমার এমবেডড ডেভেলপমেন্ট কেরিয়ারে সবচেয়ে গুরুত্বপূর্ণ খুঁজে পেয়েছি:

  1. যতটা সম্ভব কোডকে আলাদা আলাদা, ভাল সংজ্ঞায়িত মডিউলগুলি তৈরি করুন।
  2. মডিউলগুলি পিসিতে স্বয়ংক্রিয়ভাবে পরীক্ষারযোগ্য করুন।

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


4

বিদ্যমান উত্তর যুক্ত করতে ...

আমি সবসময় নীচ থেকে শুরু। আপনার হার্ডওয়্যার ডিজাইন থেকে, আপনি জানেন যে আপনার আই / ও কি। ড্রাইভার মডিউলগুলি তৈরি করে শুরু করুন যা I / O কে আবশ্যক করে তোলে, যাতে আপনার উচ্চ স্তরের কোডটি নিম্ন স্তরের স্টাফ সম্পর্কে খুব বেশি জানতে না হয়।

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


4

আমি চারটি প্রশ্নে চিন্তা করি। প্রথম দুটি হ'ল একটি সিস্টেম প্রকল্প শুরুর সাথে সম্পর্কিত, দু'জনের শেষের দিকে।

  1. তারা কি আসলে সিস্টেম চায়? সিস্টেমটি গ্রাহকদের সমস্যাটি কি একসাথে এবং ব্যয় মাপে সমাধান করবে? একটি সাধারণ সমস্যা হ'ল সিস্টেমগুলি বিল্ডিং যা গ্রাহক ব্যবহার করবেন না।

  2. আমরা কি আসলেই সেই ব্যবস্থাটি তৈরি করতে পারি? এটি প্রয়োজনীয় কার্য সম্পাদন, নির্ভুলতা, বিদ্যুত ব্যবহার, ... সরবরাহ করা সম্ভব হবে কি?


প্রাথমিক দুটি প্রোটোটাইপ তৈরি করা এই প্রথম দুটি প্রশ্নের উত্তর দেওয়ার একটি ভাল উপায়। প্রাথমিক পর্যায়ে ঝুঁকি প্রশমন অত্যন্ত গুরুত্বপূর্ণ।


পরবর্তী দুটি প্রশ্ন প্রকল্পের পরবর্তী পর্যায়ে আরও লক্ষ্যবস্তু:

  1. আমরা আসলে শেষ? ডিজাইন, কোডড, পরীক্ষিত, বিতরণ করা সবকিছু

  2. তারা আসলে কি সিস্টেমটি ব্যবহার করে?

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