3.9 সিস্টেমস ইঞ্জিনিয়ারিং

পরিচিতি ও প্রেরণা

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

এটি সফটওয়্যার স্থাপত্য থেকে ভিন্ন। সফটওয়্যার স্থাপত্য (অধ্যায় 3.1) ঠিক করে সফটওয়্যার উপাদান কীভাবে কাঠামোবদ্ধ এবং একে অন্যের সঙ্গে কীভাবে কথা বলে। সিস্টেমস ইঞ্জিনিয়ারিং এক স্তর ওপরে বসে। এটি জিজ্ঞেস করে সিস্টেমকে সামগ্রিকভাবে কী করতে হবে, সফটওয়্যার, হার্ডওয়্যার ও মানব অপারেটর কীভাবে কাজ ভাগ করবে, এবং সমাপ্ত জিনিস যে কাজ করে তা আপনি কীভাবে প্রমাণ করবেন। এর পেশাদার ঘর INCOSE, আন্তর্জাতিক সিস্টেমস ইঞ্জিনিয়ারিং পরিষদ, এবং এর নোঙর মান ISO/IEC/IEEE 15288, যা একটি সিস্টেমের জীবনের প্রক্রিয়া সংজ্ঞায়িত করে।

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

এই অধ্যায় সফটওয়্যার প্রয়োজন (অধ্যায় 2.8), স্থাপত্যের মৌলিক বিষয় (অধ্যায় 3.1), সফটওয়্যার মডেল ও পদ্ধতি (অধ্যায় 2.12), আন্তঃকার্যক্ষমতা ও মুক্ত মান (অধ্যায় 3.8), এবং প্রকল্প ব্যবস্থাপনার (অধ্যায় 10.6) সঙ্গে যুক্ত।

মূল নীতিসমূহ

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

সুপারিশ

পূর্ণ সিস্টেম জীবনচক্র পরিচালনা করুন

সিস্টেমকে একটি পূর্ণ জীবনসহ গণ্য করুন এবং প্রতিটি পর্যায়ের পরিকল্পনা করুন। একটি সাধারণ জীবনচক্র চলে এভাবে: ধারণা (প্রয়োজন বুঝুন ও বিকল্প অন্বেষণ করুন), প্রয়োজন (সিস্টেমকে ঠিক কী করতে হবে তা নির্ভুলভাবে বলুন), নকশা (স্থাপত্য ও অংশ ঠিক করুন), ইন্টিগ্রেশন (অংশগুলো একসঙ্গে আনুন), যাচাই ও বৈধকরণ (প্রমাণ করুন এটি কাজ করে এবং সঠিক সিস্টেম), পরিচালনা (চালান ও রক্ষণাবেক্ষণ করুন), এবং অবসর (ডেটা ও নিষ্পত্তিসহ নিরাপদে বন্ধ করুন)। ISO/IEC/IEEE 15288 আপনাকে এর জন্য একটি প্রক্রিয়া কাঠামো দেয়। পর্যায়গুলো কঠোর ওয়াটারফল হতে হবে না; আপনি পুনরাবৃত্তি, প্রোটোটাইপ এবং বর্ধিত অংশ সরবরাহ করতে পারেন। মূল কথা হলো আপনি সচেতনভাবে প্রতিটি পর্যায় সম্বোধন করেন, আগের পরিকল্পনা যে ব্যয়বহুল পরবর্তী পর্যায়গুলো প্রায়ই উপেক্ষা করে সেগুলোসহ।

অংশীদারদের প্রয়োজন ধরুন এবং অনুসরণযোগ্যতাসহ প্রয়োজন বণ্টন করুন

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

ইন্টারফেস সুস্পষ্টভাবে পরিচালনা করুন

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

ইন্টিগ্রেট করুন, তারপর যাচাই ও বৈধকরণ করুন

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

মডেল-ভিত্তিক সিস্টেমস ইঞ্জিনিয়ারিং গ্রহণ করুন

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

উদ্ভূত আচরণে সিস্টেম চিন্তা প্রয়োগ করুন

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

হার্ডওয়্যার ও সফটওয়্যার একসঙ্গে প্রকৌশল করুন

একটি সিস্টেমে কাস্টম হার্ডওয়্যার থাকলে হার্ডওয়্যার ও সফটওয়্যার একসঙ্গে প্রকৌশল করুন, যে চর্চাকে বলা হয় হার্ডওয়্যার/সফটওয়্যার সহ-নকশা। সিদ্ধান্ত একে অন্যকে বাঁধে: হার্ডওয়্যার সময়, মেমরি ও বিদ্যুতের সীমা ঠিক করে যার ভেতরে সফটওয়্যারকে বাঁচতে হয়, এবং সফটওয়্যারের প্রয়োজন হার্ডওয়্যারকে কী দিতে হবে তা আকার দেয়। দীর্ঘ হার্ডওয়্যার লিড টাইমও সময়সূচি চালায়। কোন কার্যকারিতা হার্ডওয়্যারে আর কোনটি সফটওয়্যারে বাস করবে তা আগে ঠিক করুন, এবং সীমাবদ্ধতা দেখা দিলে সেই ভাগ পুনর্বিবেচনা করুন।

ট্রেড-অফ: সুবিধা ও অসুবিধা

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

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

আপনার দলের সঙ্গে আলোচনার প্রশ্ন

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

2. সিস্টেম পরিচালনায় আসার আগে, পরে নয়, খারাপ উদ্ভূত আচরণ কীভাবে খোঁজেন? নিরাপদ সাবসিস্টেম মেলানো বিপজ্জনক অবস্থা তৈরি করতে পারে যা কোনো একক অংশ দেখায় না, এবং আপনি যে সিস্টেম কখনো মডেল করেননি তার থেকে উদ্ভবকে টেস্ট করে বের করতে পারেন না। একটি নিরাপত্তা-জটিল বা মিশন-জটিল কর্মসূচির জন্য বিস্ময়কর আন্তঃক্রিয়াই সেই যা কাউকে আহত করে বা মিশন ব্যর্থ করে, তাই জীবন্ত পরিচালনার আগে তা খুঁজে পেতে হবে। সমগ্র মডেল করার আপনার পদ্ধতি (সিমুলেশন, কাঠামোবদ্ধ বিপদ বিশ্লেষণ, আন্তঃক্রিয়া ধরা একটি SysML মডেল) আনুন এবং জিজ্ঞেস করুন কোন সাবসিস্টেম-জোড়া আচরণ আপনি আসলে অন্বেষণ করেছেন বনাম ধরে নিয়ে বাদ দিয়েছেন। ভালো উদ্ভব প্রায়ই সিস্টেমের উদ্দেশ্য এবং সেদিকে নকশা করা সার্থক; খারাপ উদ্ভব সেই ব্যর্থতা যার বিরুদ্ধে আপনাকে প্রকৌশল করতে হবে। আপনার একমাত্র ইন্টিগ্রেশন কৌশল অংশগুলো জুড়ে দেখা কী হয় হলে, আপনি প্রোডাকশনে উদ্ভব আবিষ্কারের পরিকল্পনা করছেন।

3. দীর্ঘ-লিড হার্ডওয়্যার সিদ্ধান্ত কখন জমিয়ে দিতে হবে, এবং সেই সময়সীমা আপনার সফটওয়্যার সময়সূচি কীভাবে চালায়? একটি সিস্টেমে কাস্টম হার্ডওয়্যার থাকলে দুটি একসঙ্গে প্রকৌশল করতে হয়: চিপ সময়, মেমরি ও বিদ্যুতের সীমা ঠিক করে যার ভেতরে সফটওয়্যার বাস করে, এবং হার্ডওয়্যার লিড টাইম প্রায়ই পুরো সময়সূচিতে প্রাধান্য পায়। যে দল সফটওয়্যারকে বিচ্ছেদযোগ্য ভাবে তারা স্থানীয়ভাবে অপ্টিমাইজ করে এবং তারপর ইন্টিগ্রেশনে হার্ডওয়্যার সীমাবদ্ধতায় ধাক্কা খায়, মাস হারায়। হার্ডওয়্যার লিড টাইম এবং যে তারিখের মধ্যে হার্ডওয়্যার/সফটওয়্যার কার্যকারিতা ভাগ ঠিক করতে হবে তা আনুন, এবং অন্ধভাবে জমিয়ে না দিয়ে সীমাবদ্ধতা দেখা দিলে সেই ভাগ পুনর্বিবেচনা করুন। কোন কার্যকারিতা সিলিকনে আর কোনটি সফটওয়্যারে বাস করবে তা যত আগে ঠিক করবেন, তত কম ব্যয়বহুল উল্টোপাল্টা সামলাবেন। দুটির মধ্যকার ইন্টারফেস একটি ইন্টারফেস কন্ট্রোল ডকুমেন্ট ও প্রতি দিকে একজন মালিক প্রাপ্য, কারণ সেখানে দেরিতে পরিবর্তন তা ছোঁয়া সবকিছুতে ঢেউ তোলে।

4. আপনি কি একটি একক অংশীদার চাহিদা প্রয়োজন, নকশা উপাদান এবং তা প্রমাণকারী টেস্ট পর্যন্ত অনুসরণ করতে পারেন, এবং সেই যোগসূত্র জীবিত রাখে কে? অনুসরণযোগ্যতাই আপনাকে যেকোনো মুহূর্তে দেখাতে দেয় প্রতিটি চাহিদা ঢাকা এবং প্রতিটি অংশ একটি কারণে বিদ্যমান, তবু একটি বড় কর্মসূচিতে ম্যাট্রিক্স যে মুহূর্তে কেউ এর মালিক থাকে না সেই মুহূর্তে পচে। প্রতিদ্বন্দ্বী টান প্রকৃত: ইঞ্জিনিয়াররা অনুসরণযোগ্যতাকে আমলাতান্ত্রিক বাড়তি বোঝা মনে করেন, এবং হাতে রক্ষিত ম্যাট্রিক্স নকশা বদলানোর চেয়ে দ্রুত পুরোনো হয়। একটি বর্তমান কর্মসূচি থেকে একটি প্রকৃত সুতো আনুন এবং ঘরে তা শুরু থেকে শেষ হাঁটার চেষ্টা করুন, একটি নামকরা অংশীদার চাহিদা থেকে বণ্টিত প্রয়োজন, তা পূরণকারী সাবসিস্টেম ও নকশা উপাদান, যাচাই টেস্ট পর্যন্ত, এবং লক্ষ্য করুন শৃঙ্খল কোথায় ভাঙে। ঠিক করুন ম্যাট্রিক্সের মালিক কে এবং এটি একটি মডেলে বাস করা উচিত কি না যেখানে অনুসরণযোগ্যতা হাতে-তাড়ার বদলে একটি কোয়েরি। এন্টারপ্রাইজ ও সরকারি কর্মসূচির জন্য ম্যাট্রিক্স নিয়ন্ত্রক ও অধিগ্রহণ কর্তৃপক্ষ যে নিরীক্ষা নিদর্শন দাবি করেন তাও, তাই একটি ভাঙা শৃঙ্খল কেবল প্রকৌশল ধীর করে না; এটি সনদ বা পেমেন্ট থামাতে পারে।

5. একটি মডেল-ভিত্তিক পদ্ধতি কি আপনার টুলিং ও সংস্কৃতি খরচের যোগ্য, নাকি তা ব্যয়বহুল শেলফওয়্যার হবে? নথি-ভিত্তিক সিস্টেমস ইঞ্জিনিয়ারিং পরিচিত এবং টুলিংয়ে সস্তা, কিন্তু তার নথি সামঞ্জস্য থেকে সরে যায় এবং অনুসরণযোগ্যতা হাতে-করা ও ত্রুটিপ্রবণ; MBSE স্তূপকে একটি সংযুক্ত মডেল দিয়ে প্রতিস্থাপন করে, টুলিং, প্রশিক্ষণ ও প্রকৃত সংস্কৃতি পরিবর্তনের দামে। দুই প্রান্তই ব্যয়বহুল: বড় বহু-শাখার কর্মসূচিতে MBSE এড়ালে আপনি ইন্টিগ্রেশন বিস্ময়ে দাম দেন, মডেল হালনাগাদ রাখার শৃঙ্খলা ছাড়া তা গ্রহণ করলে তা পচে মডেল না থাকার চেয়ে খারাপ শেলফওয়্যারে পরিণত হয়। আপনার টুলিং পরিপক্বতার সৎ পাঠ, দলের কে আসলে একটি SysML মডেল লিখতে ও রক্ষণাবেক্ষণ করতে পারেন, এবং কোন একটি উচ্চ-ঝুঁকি সাবসিস্টেম সেই পদ্ধতির পাইলট করতে পারে যেখানে ভাগ করা মডেল দ্রুততম ফল দেয় তা আনুন। পুরো প্রতিষ্ঠানে একসঙ্গে বাধ্যতামূলক না করে ধীরে ধীরে সিদ্ধান্ত নিন। অনেক সরবরাহকারীর বড় এন্টারপ্রাইজ বা সরকারি কর্মসূচির জন্য ভাবুন ভাগ করা মডেল কি ঠিকাদারদের জুড়ে প্রয়োজন, ইন্টারফেস ও টেস্ট সামঞ্জস্যপূর্ণ রাখার একমাত্র বাস্তবসম্মত উপায় কি না, যারা নইলে পুরোনো নথি বিনিময় করে।

6. আপনার জীবনচক্র পরিকল্পনা কি পরিচালনা ও অবসরে গুরুত্ব সহকারে অর্থায়ন করে, নাকি নিঃশব্দে লঞ্চে থেমে যায়? যে পর্যায় একটি দীর্ঘজীবী সিস্টেমের মোট খরচে প্রাধান্য পায়, দশকের পর দশক এটি চালানো এবং নিরাপদে বন্ধ করা, তা আগের পরিকল্পনা নিয়মিত উপেক্ষা করে, কারণ চাপ সবসময় পাঠানোর। প্রতিদ্বন্দ্বী বিবেচনা হলো অর্থ ও মনোযোগ সবচেয়ে দুর্লভ ঠিক যখন এই পরবর্তী পর্যায় সবচেয়ে দূরের মনে হয়, তাই পরিচালনা, রক্ষণাবেক্ষণ, ডেটা স্থানান্তর ও নিষ্পত্তি স্থগিত হয় যতক্ষণ না তা ব্যয়বহুল, ঝুঁকিপূর্ণ হুড়োহুড়ি হয়। বর্তমান জীবনচক্র পরিকল্পনা আনুন এবং যাচাই করুন তা পরিচালনা ও অবসরের জন্য মালিক, বাজেট ও প্রস্থান মানদণ্ডের নাম দেয়, নাকি লঞ্চকে শেষ রেখা গণ্য করে। জিজ্ঞেস করুন জীবনের শেষে ডেটা ও হার্ডওয়্যারের কী হয়, এবং মধ্যবর্তী বছরের রক্ষণাবেক্ষণের জন্য কে অর্থ দেয়। যে এন্টারপ্রাইজ ও সরকারি সিস্টেমকে বিশ বা ত্রিশ বছর চলতে হবে এবং তারপর জনসাধারণের যাচাইয়ের অধীনে অবসর নিতে হবে, অপরিকল্পিত বন্ধ করা নিয়ন্ত্রক, পরিবেশগত বা রেকর্ড-ধারণ বাধ্যবাধকতা লঙ্ঘন করতে পারে, তাই অবসর প্রথম ধারণা পর্যালোচনা থেকেই পরিকল্পনা ও বাজেটে থাকা দরকার।

খাতভেদে দৃষ্টিভঙ্গি

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

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

এন্টারপ্রাইজ। পরিসরে সমস্যা অনেক দল ও সরবরাহকারী জুড়ে সামঞ্জস্য: ISO/IEC/IEEE 15288-এর সঙ্গে সারিবদ্ধ একটি ভাগ করা জীবনচক্র প্রক্রিয়া, প্রতিটি সরবরাহকারী সীমানার জন্য একটি ইন্টারফেস কন্ট্রোল ডকুমেন্ট ও একজন নামকরা মালিক, এবং শুরু থেকে শেষ অনুসরণযোগ্যতা যাতে একটি উপাদান পরিবর্তন কর্মসূচি-জোড়া হুড়োহুড়ি ট্রিগার না করে। যেখানে ভাগ করা মডেল ঠিকাদারদের জুড়ে প্রয়োজন, ইন্টারফেস ও টেস্ট সারিবদ্ধ রাখে সেখানে MBSE-তে বিনিয়োগ করুন। প্রক্রিয়া শাসন করুন যাতে যাচাই ও বৈধকরণ আলাদা থাকে এবং প্রতিটি প্রয়োজন একটি দায়ী অংশে বণ্টিত হয়।

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

উদাহরণ

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

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

সরকার। একটি জাতীয় বিমান-নেভিগেশন কর্তৃপক্ষ তার বিমান-ট্রাফিক ব্যবস্থাপনা সিস্টেম আধুনিক করে, রাডার, নিয়ন্ত্রক ওয়ার্কস্টেশন, যোগাযোগ ও সফটওয়্যার জুড়ে একটি নিরাপত্তা-জটিল সিস্টেমের সিস্টেম, যা সার্বক্ষণিক পরিচালিত। কর্মসূচি পূর্ণ জীবনচক্র জুড়ে ISO/IEC/IEEE 15288 অনুসরণ করে। যাচাই প্রমাণ করে প্রতিটি সাবসিস্টেম তার স্পেসিফিকেশন পূরণ করে, এবং প্রকৃত নিয়ন্ত্রকদের সঙ্গে সিমুলেশনের মাধ্যমে বৈধকরণ প্রমাণ করে ইন্টিগ্রেটেড সিস্টেম কোনো জীবন্ত ট্রাফিক নির্ভর করার আগে নিরাপদ পরিচালনা সমর্থন করে। কঠোর V&V কর্তৃপক্ষকে ধাপে ধাপে কাটওভার করতে দেয়, প্রতিটি ধাপে ফলব্যাকসহ, কারণ এখানে একটি অপরীক্ষিত উদ্ভূত ব্যর্থতা একটি জননিরাপত্তা ঘটনা।

ব্যবসায়িক যুক্তি: প্রেরণা, ROI ও TCO

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

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

অ্যান্টি-প্যাটার্ন ও ফাঁদ

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

পরিপক্বতা মডেল

স্তর ১: সূচনা। সিস্টেমস ইঞ্জিনিয়ারিং অ্যাড হক ও প্রতিক্রিয়াশীল। প্রয়োজন ছড়ানো নথিতে বাস করে, ইন্টারফেস ইন্টিগ্রেশনে আবিষ্কৃত হয়, এবং যাচাই হলো যে টেস্টিং ঘটে যায়। বড় কর্মসূচি নিয়মিত ছাড়ায় এবং দলকে দেরিতে অবাক করে।

স্তর ২: বিকাশ। প্রধান কর্মসূচিতে মৌলিক চর্চা আছে। প্রয়োজন ধরা ও ভিত্তিরেখা করা হয়, মূল ইন্টারফেসের কন্ট্রোল ডকুমেন্ট আছে, এবং একটি যাচাই পরিকল্পনা আছে। দলগুলোর মধ্যে চর্চা অসঙ্গত এবং ভাগ করা পদ্ধতির বদলে ব্যক্তির ওপর নির্ভর করে।

স্তর ৩: মানসম্মতকরণ। সিস্টেমস ইঞ্জিনিয়ারিং ISO/IEC/IEEE 15288-এর সঙ্গে সারিবদ্ধ একটি নথিবদ্ধ, প্রতিষ্ঠান-ব্যাপী শৃঙ্খলা যা দল জুড়ে প্রয়োগ করা। পূর্ণ জীবনচক্রের পরিকল্পনা করা, অনুসরণযোগ্যতা শুরু থেকে শেষ রক্ষিত, ইন্টারফেস আনুষ্ঠানিকভাবে নিয়ন্ত্রিত, এবং যাচাই ও বৈধকরণ আলাদা ও পরিকল্পিত। জটিল কর্মসূচিতে MBSE ব্যবহৃত হয়।

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

স্তর ৫: সমন্বয়। সিস্টেমস ইঞ্জিনিয়ারিং নিরন্তর উন্নত এবং প্রতিষ্ঠান জুড়ে একীভূত। একটি জীবন্ত MBSE মডেল একক সত্যের উৎস, অনুসরণযোগ্যতা স্বয়ংক্রিয়, সিমুলেশন গড়ার আগে উদ্ভূত আচরণ পূর্বাভাস দেয়, এবং অতীত কর্মসূচির মেট্রিক পরেরটিতে জোগান দেয়। হার্ডওয়্যার ও সফটওয়্যার স্বাভাবিকভাবে একসঙ্গে প্রকৌশল করা হয়, এবং কর্মসূচি, সরবরাহকারী ও ঝুঁকি সরলে প্রক্রিয়া খাপ খায়।

আলোচনার ভাবনা

• আপনার প্রতিষ্ঠানে সিস্টেমস ইঞ্জিনিয়ারিং ও সফটওয়্যার স্থাপত্যের মধ্যে রেখা কোথায়, এবং দুটির মধ্যবর্তী জায়গার মালিক কে?
• আপনার সবচেয়ে বড় কর্মসূচিতে কি আপনি একটি একক অংশীদার চাহিদা তা যাচাইকারী টেস্ট পর্যন্ত অনুসরণ করতে পারেন? না পারলে কী লাগবে?
• আপনার সাম্প্রতিক কোন ব্যর্থতা একটি ইন্টারফেসে ঘটেছে, এবং তার মালিক কে ছিল?
• আপনার সংস্কৃতি ও টুলিং বিবেচনায় MBSE কি আপনার জন্য ফল দেবে, নাকি ব্যয়বহুল শেলফওয়্যার হবে?
• আপনার জীবনচক্র পরিকল্পনা কি পরিচালনা ও অবসর গুরুত্ব সহকারে সম্বোধন করে, নাকি নিঃশব্দে লঞ্চে থেমে যায়?

প্রধান শিক্ষা

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

তথ্যসূত্র ও আরও পড়ার জন্য

• INCOSE, INCOSE Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities
• ISO/IEC/IEEE 15288, Systems and Software Engineering: System Life Cycle Processes
• ISO/IEC/IEEE 29148, Systems and Software Engineering: Requirements Engineering
• Sanford Friedenthal, Alan Moore ও Rick Steiner, A Practical Guide to SysML: The Systems Modelling Language
• NASA, NASA Systems Engineering Handbook (NASA/SP-2016-6105)
• Andrew P. Sage ও William B. Rouse, Handbook of Systems Engineering and Management
• Dennis M. Buede ও William D. Miller, The Engineering Design of Systems: Models and Methods
• Donella H. Meadows, Thinking in Systems: A Primer
• Eberhardt Rechtin ও Mark W. Maier, The Art of Systems Architecting
• U.S. Department of Defence, Defence Acquisition Guidebook (সিস্টেমস ইঞ্জিনিয়ারিং নির্দেশনা)