2.12 সফটওয়্যার মডেল ও পদ্ধতি

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

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

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

বড় দলে প্রকৃত ঝুঁকি সমন্বয় ও যোগাযোগ। শত শত ইঞ্জিনিয়ার, আর্কিটেক্ট, বিশ্লেষক ও নিরীক্ষক যখন একটি সিস্টেমে কাজ করেন, তখন ভাগ করা মডেল হলো সেই সাধারণ জমি, যেখানে তাঁরা নকশা, প্রয়োজনীয়তা ও ঝুঁকি নিয়ে আলাপ করেন। তাই মডেলিংকে করণীয় একটি কাজসহ হাতিয়ার ভাবুন। যখন একটি মডেল যে ভুল ঠেকায় তার চেয়ে সস্তা, তখন তা প্রতিদান দেয়। যখন আপনি তা নিজের জন্য আঁকেন, বাসি হয়ে যাওয়ার অনেক পরেও রাখেন, বা যে সিদ্ধান্তের সেবা করার কথা তার চেয়ে বেশি বিস্তৃত করেন, তখন তা অপচয়। মডেলিং সফটওয়্যার প্রয়োজনীয়তা (অধ্যায় 2.8), সফটওয়্যার নকশার নীতি (অধ্যায় 2.2), স্থাপত্য ও তার C4 ও arc42-এর মতো নোটেশন (অধ্যায় 3.1) এবং এজাইল কাজের পদ্ধতির (অধ্যায় 10.7) সঙ্গে আঁটসাঁটভাবে যুক্ত।

মূল নীতিসমূহ

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

সুপারিশ

বিমূর্তন, উদ্দেশ্য ও সামঞ্জস্যসহ মডেল করুন

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

প্রশ্নের সঙ্গে মিলিয়ে কাঠামোগত বা আচরণগত মডেল বেছে নিন

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

মডেল বিশ্লেষণ করুন, কেবল আঁকবেন না

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

ডিফল্ট হিসেবে হিউরিস্টিক পদ্ধতি প্রয়োগ করুন

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

উচ্চ-পরিণতির কেন্দ্রের জন্য আনুষ্ঠানিক পদ্ধতি সংরক্ষণ করুন

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

অনিশ্চয়তা দূর করতে প্রোটোটাইপিং ব্যবহার করুন

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

ফ্যাশনে নয়, ঝুঁকির সঙ্গে পদ্ধতি মেলান

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

উদাহরণ

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

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

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

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

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

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

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

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

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

• স্তর ১ (সূচনা): মডেলিং তাৎক্ষণিক বা অনুপস্থিত এবং নিছক প্রতিক্রিয়াশীল; কোনো পদ্ধতির নাম নেই; মডেল, আদৌ আঁকা হলে, অসঙ্গত, অবিশ্লেষিত, এবং সভা শেষ হতেই পরিত্যক্ত।
• স্তর ২ (বিকাশ): কিছু দল সাধারণ ডায়াগ্রাম আঁকে এবং একটি নামকরা পদ্ধতি অনুসরণ করে, কিন্তু চর্চা প্রতিষ্ঠান জুড়ে অসম: মডেল প্রায়ই আনুষ্ঠানিকতার জন্য তৈরি, কোড থেকে সরে যায়, এবং ত্রুটির জন্য কদাচিৎ বিশ্লেষিত হয়।
• স্তর ৩ (মানসম্মতকরণ): একটি ভাগ করা নোটেশন, নথিবদ্ধ পদ্ধতি-নির্বাচন নির্দেশিকা এবং সামঞ্জস্যের নিয়ম সংজ্ঞায়িত ও প্রতিষ্ঠানজুড়ে বলবৎ; মডেল উদ্দেশ্য অনুযায়ী বাছা, সিস্টেমের সঙ্গে তালে রাখা, ত্রুটির জন্য পর্যালোচিত, এবং পদ্ধতি প্রতিটি সমস্যার ঝুঁকির সঙ্গে মেলানো।
• স্তর ৪ (ব্যবস্থাপনা): মডেলিং ভিত্তিরেখার বিপরীতে মাপা ও নিয়ন্ত্রিত; দলগুলো অনুসরণ করে বাস্তবায়নের আগে বিশ্লেষণ কতগুলো ত্রুটি ধরে, মডেল কোড থেকে কতটা সরে, প্রতিটি মডেল প্রকৃত সিদ্ধান্তের জন্য সত্যিই ব্যবহৃত হয়েছে কি না, এবং একটি সংজ্ঞায়িত ভিত্তিরেখার বনাম বাঁচানো পুনঃকাজ ও চক্র সময়; পদ্ধতির পছন্দ মাপা অনিশ্চয়তা ও পরিণতির সঙ্গে ক্যালিব্রেট করা, এবং সংকটপূর্ণ কেন্দ্র সম্মত আওতার লক্ষ্য অনুযায়ী আনুষ্ঠানিকভাবে যাচাইকৃত।
• স্তর ৫ (সমন্বয়): মডেলিং ও পদ্ধতি নির্বাচন নিরন্তর উন্নত এবং প্রতিষ্ঠান জুড়ে সরবরাহ ও ঝুঁকি পরিকল্পনার সঙ্গে একীভূত; অনিশ্চয়তা ও পরিণতি সরলে বিনিয়োগ খাপ খাইয়ে নেয়, মডেল নিয়মিত হালনাগাদ রাখা, অবসান বা প্রমাণের ভিত্তিতে গভীর করা হয়, এবং আনুষ্ঠানিক, হিউরিস্টিক ও প্রোটোটাইপিং পদ্ধতি এমনভাবে গঠিত যাতে প্রতিটি ঠিক সেখানে বসে যেখানে সে প্রতিদান দেয়।

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

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

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

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

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

• IEEE Computer Society, SWEBOK Guide (Software Engineering Body of Knowledge), Version 4.0, সফটওয়্যার ইঞ্জিনিয়ারিং মডেল ও পদ্ধতি জ্ঞান-ক্ষেত্র
• Martin Fowler, UML Distilled: A Brief Guide to the Standard Object Modelling Language
• Grady Booch, James Rumbaugh, Ivar Jacobson, The Unified Modelling Language User Guide
• Frederick P. Brooks, The Mythical Man-Month এবং No Silver Bullet: Essence and Accident in Software Engineering
• Daniel Jackson, Software Abstractions: Logic, Language, and Analysis (Alloy মডেলিং ভাষা)
• Leslie Lamport, Specifying Systems (TLA+)
• Simon Brown, Software Architecture for Developers (C4 মডেল)
• David Harel, Statecharts: A Visual Formalism for Complex Systems