Introduction
Software Process হলো একগুচ্ছ পরস্পর সম্পর্কিত কার্যক্রম (activities) যা একটা একটি Software production এর দিকে নিয়ে যায়।
Software Process টা System এর ভিত্তি করে বিভিন্ন ধরনের হতে পারে। এর জন্য নিদির্ষ্ট কোন পদ্ধতি নেই। তবে process যেমনই হোক না কেন ৪টা জিনিস অবশ্যই তার ভিতরে রাখতে হবে।
১। Software Specifications
২। Software Development
৩। Software Validation
৪। Software Evolution
( নিচে এগুলো নিয়ে বিস্তারিত আলোচনা করা হবে। )
Software Process একটি জটিল বিষয় এবং অন্য একটি সৃজনশীল ( Creative) কাজগুলোর মত করে, মানুষের সিদ্ধান্ত এবং তাদের চিন্তার ধারার উপর নির্ভর করে। যেহেতু এখানে কোনো Universal কোন Process নায় এই জন্য, কম্পানিগুলো তাদের মত করে একটা Process তৈরি করে নেয় , যাতে তারা তাদের কম্পানিতে কর্মরত Engineer দের দক্ষতা ব্যবহার করে সর্বোচ্চ সুবিধা গ্রহন করতে পারে। তবে এক্ষেত্রে এই প্রসেস Engineer এবং System এর উপর নির্ভর করে সময়ের সাথে সাথে পরিবর্তন হতে পারে।
Roles reflect the responsibilities of the people involved in the process. For example: Project Manger, programmer , database designer etc.
Software Process Models
Software Process model হলো software process এর সহজ উপস্থাপনা। একে অনেক সময় SDLC (Software Development Life Cycle) Models ও বলা হয়ে। এই সকল মডেল গুলো High লেভেল এর হয়ে থাকে। এখানে শুধুমাত্র activity গুলো তুলে ধরা হয়। এই activity এর উপর নির্ভর বিভিন্ন কর্মপদ্ধতি চিন্তা করা হয়।
কিছু সাধারন মডেলঃ
১। The Waterfall Model
২। Incremental Development
৩। Integration and Configuration
এইগুলো সাধারন কয়েকটা মডেল। যেহেতু Universal কোন মডেল নেই সেহেতু কোন প্রতিষ্ঠান বা কম্পানি চাইলে তাদের মত এই সব মডেল ডিজাইন করে ব্যবহার করতে পারে। তবে এখানে তাদের মূল উদ্দেশ্য হবে সময়ের মধ্যে দ্রুত Software প্রস্তুত করে Delivery করা। তার চাইলে ২ বা ততোধিক মডেল একসাথে মডেল তৈরি করতে পারে। এতা সম্পূর্ণ নির্ভর করছে তাদের System এর ধরন এবং Developer দের দক্ষতার উপর।
The Waterfall Model
The Waterfall model মডেল হলো কয়েকটি ধাপ নিয়ে গঠিত হয়। এখানে মূলত একটা ধাপের কাজ শেষ হলে পরবর্তী ধাপের কাজ শুরু হয় । তবে প্রতিটি ধাপের কাজ গুলো Document এর মাধ্যমে সংরক্ষন করা হয়। এটা একট plan-driven মডেল। এখানে Software Development শুরু করার আগেই সব কিছু প্লান করা হয়।
The Waterfall model এর কিছু ধাপ যেগুলো মৌলিক Software Development এর কার্যক্রমঃ
১। Requirements Analysis and Definition: এখানে সিস্টেম এর সক্ষমতা , সীমাবদ্ধতা ইত্যাদি বিষয় নিয়ে আলাপ আলোচনা হয়।
২। System and Software Design: এই ধাপে সিস্টেম এর জন্য হার্ডওয়্যার ও সফটওয়্যার এর জন্য একটা Architecture তৈরি করা হয়।
৩। Implementation and Unit Testing: এই ধাপে এসে মুলত প্রোগ্রামিং করা হয় এবং প্রতিটি ছোট কম্পোনেন্টকে টেস্ট করা হয়।
৪। Integration and System testing: এই ধাপে সকল ছোট ছোট Unit কে একত্র করে , সম্পর্ণ সিস্টেমটাকে টেস্ট করা হয়। এই টেস্টিং সফল হলে সফটওয়্যার ডেলিভারি করা জন্য প্রস্তুত।
৫। Operation and Maintenance: এই ধাপ তো হল সব থেকে লম্বা ধাপ। সিস্টেম ডেলিভারি করা হয়ে গেছে এবং প্রাক্টিক্যালি ব্যবহার করা হচ্ছে। এখন অনেক Bugs , error থাকতে যেগুলো টেস্টিং এর সময় ধরা পড়ে নি। এই ধাপে এসে সেগুলো ঠিক করা হয়। এছাড়াও সিস্টেম সিকিউরিটি , পারফরমেন্স উন্নত করা চেষ্টা করা হয়।
এই বিষয় গুলো পরবর্তীতে আলোচনা হবে।
Problems of Waterfall Model
Waterfall model হার্ডওয়্যার ডেভোলপ করা জন্য ঠিক আছে। কারন এই পন্য একটা প্রস্তুত হয়ে গেল তা আর পরিবর্তন করা যায় না। এর জন্য সবকিছু ভালো মত ধাপে ধাপে কার্য সম্পাদন করা হয়। যেকোন একটা ধাপে যদি ভুল হয় , সেটা সম্পূর্ণ প্রডাক্টকে নষ্ট করে দিতে পারে।
তবে Software এর ক্ষেত্রে পরবর্তীতে পরিবর্তন করা সম্ভব। Software প্রতিনিয়তই পরিবর্তন করার প্রয়োজন হতে পারে। The Waterfall model-এ কোন ধাপে যদি সমস্যা হয় তাহলে সেটা আবার পূনরায় প্রথম ধাপ থেকে শুরু করা হয়। Software develop করার ক্ষেত্রে বিভিন্ন ধাপে প্রবলেম হবে। সেক্ষেত্রে প্রথম শুরু করা অনেক সময় লেগে যাবে। তার বড় বিষয় হচ্ছে এখানে একটা ঝুকি থেকে যায়। ঝুকি টা হচ্ছে, যদি Software ডেভেলোপ শেষ হওয়ার পরে সেটা কারও পছন্দ না হয়। User যদি গ্রহন না করে। তখন এই সময় টুকু নষ্ট হয়ে যাবে। তাছাড়া এই মডেলে কাজ করলে একটা ফিচার রিলিজ করতেও অনেক সময় লেগে যায়।
Applications of Waterfall model
১। Embedded Systems: Embedded Systems একবার ইমপ্লিমেন্ট করা হয়ে গেলে তা আর পরিবর্তন করার সুযোগ থাকে না। এজন্য প্রতিটা ধাপ খুব ভালো ভাবে রিসার্চ করে তারপর পার করা হয়। এর জন এই ধরনের সিস্টেম তৈরি করতে সময় ও লেগে যায়।
২। Critical System: critical system গুলোতে প্রতেক টি ডাটা প্রয়োজন এজন্য প্রতিটি ধাপ আস্তে আস্তে ভালো ভাবে পার করা প্রয়োজন, যাতে ভবিষ্যতে কোন অনাকাঙ্ক্ষিত ঘটনা না ঘটে।
Ending
বর্তমানে Waterfall model একবারে যৌক্তিক না , কারন সিস্টেম এর Requirements প্রতি নিয়ত পরিবর্তন হয়। এখন যদি Waterfall model ফলো করে সিস্টেম রেডি করা হয় তাহলে অনেক সময় লেগে যাবে। দিন যার ভ্যালু অনেক কমে যেতেও পারে। অতিতে এমন অনেক কেস আছে। দেখা গেছে, একজনের কাছে একটা খুব ভালো আইডিয়া আছে। কিন্তু সেই আইডিয়া সম্পর্ণ রুপ দিতে গেলে অনেক সময় লেগে যাবে। তার আইডিয়া ছিল সম্পূর্ণ রেডি করে তারপর ময়দানে নামবে। কিন্তু তার সেইম আইডিয়া অনেক পরে এসে অল্প অল্প করে ডেভেলোপ করে তারা আজ ধরা ছোয়ার বাইরে চলে গেছে।
So The Waterfall model is not suitable for current software development.
Incremental Development
Incremental Development -এ প্রথমে একটা প্রাথমিক প্রোডাক্ট বা software তৈরি করা হয় এবং পরবর্তীতের user এবং অন্যান্যদের মতামতের উপর ভিত্তি করে আস্তে আস্তে ডেভেলোপ হয়। এখানে ভার্সন ম্যানেজমেন্ট করে নতুন নতুন ফিচার যুক্ত করা হয়। নতুন ফিচার এর জন্য নতুন একটা ভার্সন রিলিজ দেওয়া হয়ে থাকে।
বর্তমানে এই ধরনের মডেল খুবই জন্যপ্রিয়। এখানে সকল ফিচার আস্তে আস্তে ধাপে ধাপে ডেভোলোপ করা করা হয়। প্রতিনিয়ত সব কিছু পরিবর্তন হচ্ছে। সাথে মানুষের চাহিদা , প্রয়োজন , দৈনন্দিন জীবন ব্যবস্থা সব কিছুই পরিবর্তন হচ্ছে। এখন একটি software কে যদি সার্ভাইভ করতে হয় তাহলে এই সকল বিষয় গুলো বিবেচনা করেই আগাতে হবে। এখানে যেহেতু পর্যায়ক্রমে সব কিছু ডেভেলোপ হয়, সেহেতু নতুন নতুন ফিচার নিয়ে ডেভোলোপ করা খুবই সহজ হয়। আবার পুরাতন ফিচার যেগুলোর আর দরকার নেই সেগুলোও বাদ দেওয়া যায়। নতুনত্বের সাথে তাল মিলিয়ে চলা যায়।
Incremental Development এর ক্ষেত্রে ভার্সন ম্যানেজ করা হয়। প্রথমে একটা মিনিমাল software রিলিজ দেওয়া হয়। এই ভার্সন গুলো user ব্যবহার করতে পারে। এর পরে নতুন নতুন ফিচার প্লান করা হয়। সেগুলো যুক্ত করা হয়ে গেলে সব কিছু টেস্ট করার পর নতুন একটা ভার্সন রিলিজ করা হয়। নতুন ফিচার, বাগ ফিক্সিং কোড পরিবর্তন করলেই সেটা নতুন ভার্সনে নিয়ে যাওয়া হয়। তবে প্রতিটি নতুন ভার্সন user এর কাছে expose না করলেও চলে। একবার অনেক গুলো ভার্সন রিলিজ দেওয়া যেতে । এটা নির্ভর করছে কম্পানি বা প্রতিষ্ঠানের উপর। এই ভার্সন ম্যানেজমেন্ট এর জন্য প্রসেস টা Waterfall Model এর তুলনায় অনেক সহজ করে দেই। তাছাড়া এই ভার্সনের মাধ্যমে বেটা টেস্টিং করা যায়।
Advantages
Incremental Development এ Waterfall model এর তুলনায় ৩ টা প্রধান সুবিধা রয়েছে।
১। খরচ কমে যায়ঃ Waterfall Model এ প্রতিটি ধাপে বিস্তারিত ভাবে সব কিছু ডকুমেন্ট করা হয়। এখন যদি কোন requirements এর পরিবর্তন হয় তাহলে তার খরচ Incremental Development model অনেক কম।
২। কাস্টমার ফিডব্যাকঃ Waterfall model-এ সম্পূর্ণ software তৈরি না হলে কাস্টমার থেকে ফিডব্যাক নেওয়া সম্ভব হয় না। আর ডকুমেন্টশন কাস্টমার পড়তে খুব বেশি স্বাছন্দ বোধ করে না। এই মডেল যেহেতু ধাপে ধাপে develop করা হয়, সেহেতু customer খুব সহজে তার ফিডব্যাক দিতে পারে।
৩। Early Delivery and Deployment : এই প্রসেস এ কাস্টমার দ্রুত একটা প্রোডাক্ট পেয়ে যায়। যদিও এটা সম্পূর্ন ফাংশনালিটি যুক্ত থাকে না। কিন্তু তা ব্যবহার এর উপযুক্ত হয়ে যায়। waterfall model এর তুলনায় এখানে সময় অনেক কম লাগে
Problems
Incremental Development এর সুবিধা থাকলেও ম্যানেজমেন্ট এর দিক থেকে চিন্তা করলে দুইটি অসুবিধা আছে।
১। এর মডেলে প্রসেস দেখা যায় না। এই জন্য ম্যানেজার কে প্রতিনিয়ত ডিলিভারি গুলো দেখতে হয় এবং এই অনুযায়ী প্রগ্রেস তৈরি করতে হয়। এ ক্ষেত্রে যদি সফটওয়্যার যদি খুবই দ্রুত প্রয়োজন হয় এবং প্রতিটি ভার্সনে ডকুমেন্টেশন করা লাগে তাহলে খরচ অনেক বেড়ে যায়।
২। সিস্টেম স্ট্রাকচার নষ্ট বা খারাপ হওয়ার সম্ভাবনা থাকে যখন নতুন ফিচার যুক্ত করা হয়। এখানে যেহেতু অনেক জন একসাথে কাজ করে সেক্ষেত্রে নতুন কিছু যুক্ত করতে গেলে সেখানে একটু সমস্যার সৃষ্টি হতে পারে। তাছাড়া সবার দক্ষতা সমান না। এই জন্য অনেক সময় সিস্টেম এর স্ট্রাকচার নিচের দিকে নেমে যায়। অনেক সময় নষ্ট ও হয়ে যায়।
এই সমস্যা গুলো সবথেকে বেশি দেখা দেয় বড় , জটিল এবং লম্বা সময় এর সিস্টেমে যেখানে এই সব বড় সিস্টেমের ছোট ছোট অংশ বিভিন্ন টিম কাজ করে । এই ধরনের সিস্টেম গুলোতে এই সমস্যাগুলো সব থেকে বেশি দেখা দেয়। মূলত এই ধরনের সিস্টেম এ কাজ করার জন্য আগেই থেকেই আর্কিটেকচার, ডকুমেন্টশন এবং আনুসাংঙ্গিক সব কিছুই আগে থেকে ঠিক ঠাক করে রাখতে হয়।
Integration and Configuration
Software Engineer এর দের মধ্যে একটা প্রিন্সিপাল খুব পরিচিত DRY, Don’t Repeat Yourself এই প্রিন্সিপাল মুল নীতি একই রকম কম্পোনেন্ট কে বার বার নতুন করে না বানিয়ে , সেটাকে বার বার ব্যবহার করা। বর্তমানে এই জিনিস টা খুবই জনপ্রিয়তা। সবাই এই সিম্পল প্রিন্সিপাল ফলো করার চেষ্টা করে। এই ভাবে একই জিনিস বার বার ব্যবহার করার হলো Re-use oriented পদ্ধতি।
Re-use oriented পদ্ধতি টা মুলত একটা পুনরায় ব্যবহার করা যাবে এমন সফটওয়্যার কম্পোনেন্ট (একাধিক হতে পারে) এবং একটা ফ্রেমওয়ার্ক যার দ্বারা এসব কম্পোনেন্ট কে একসাথে ব্যবহার করা যাবে তার উপর নির্ভর করে ।
একটা উদাহরনের মাধ্যমে বিষয়টা সহজ করা যাক।
আমাদের কাছে একটা Department Manage করার জন্য একটা সফটওয়্যার আছে। এখন এই সফটওয়্যার টা আমরা পুনরায় ব্যবহার করতে পারি (COTS)। এই সফটওয়্যার-এ নিচের এই ফিচার গুলো আছে,
- Interactive Dashboard
- Course Management
- Students , Teacher and Staff Management
- Online Exam
- Online Quiz and Assignment
- Calendar with Scheduling Facility
- Report Generation
- Setting and Preference Management
এখন সিভিল ডিপার্ট্মেন্ট থেকে বলা হলো ঠিক এইধরনের একটা সফটওয়্যার তৈরি করার জন্য। সেই সফটওয়্যার নিচের ফিচার গুলো থাকতে হবে,
- Interactive Dashboard
- Course Management
- Students , Teacher and Staff Management
- Calendar with Scheduling Facility
- Attendance
- Instrument Management
- Report Generation
- Setting and Preference Management
এখানে লক্ষ্য করলে দেখা যাবে, আগের প্রস্তুতকৃত সফটওয়্যার সাথে কয়েকটা জিনিস বাদে বাকি গুলো বিল্ড করা রয়েছে। এখন আমরা সিভিল ডিপার্ট্মেন্ট এর কাছে জিজ্ঞাসা করতে পারি যে আমাদের এই রকম একটা সফটওয়্যার আছে, তার ভিতরে এই এই ফিচার নেই । এখন কি আপনারা এটা ব্যবহার করবেন, তার যদি রাজি হয়, তাহলে আমরা কিছু কনফিগারেশন করে সফটওয়্যার ডেলিভারি করে দেব ব্যাস। আমারদের কাছ শেষ। তারা যদি রাজি না হয় তাহলে ওইগুলো ব্যবহার করে এবং নতুন কম্পোনেন্ট গুলো নতুন করে বিল্ড করে দুই ধরনের কম্পোনেন্টগুলো একসাথে করে সফটওয়্যার টি প্রস্তুত করতে পারি ।
Software Components
তিন ধরনের সফটওয়্যার কম্পোনেন্ট রয়েছে।
- Stand-alone applications: এই ধরনের অ্যাপ্লিকেশান গুলো সাধারনভাবে ব্যবহার করার জন্য ব্যবহৃত হয়। এখানে একসাথে প্রয়োজনীয় অপ্রয়োজনীয় অনেকগুলো ফিচার থাকে।
- Collection of Objects: এই ধরনের সফটওয়্যার কম্পোনেন্টস গুলো বেশিরভাগ ক্ষেত্রেই প্যাকেজ হয়, যেটা আগে থেকে বিদ্যমান বিভিন্ন সফটওয়্যার এর সাথে কাজ করে থাকে।
- Web services: এই বিভিন্ন ধরনের সার্ভিস যে ওয়েব এর মাধ্যমে অ্যাক্সেস করা যায়। যেমন Weather Api
Process Stages
নিচের এই স্টেপ গুলো উপরে ইতোমধ্যেই অনুসরণ করা হয়ে গেছে।
- Requirements Specifications: এই ধাপে একটা Requirements এর তালিকা আসে । সাধারনভাবে কি কি লাগবে তার একটা বিবরন দেওয়া থাকে।
- Software Discovery and Evaluation: এই ধাপে এসে খোজা হয় যে Requirements এর সাথে মেলে এমন কোন সফটওয়্যার আছে কিনা এবং এই সফটওয়্যার এর কি ফিচার আছে সেগুলোকে মূল্যায়ন করা হয়।
- Requirements refinement: আগের ধাপে যদি কোন সফটওয়্যার খুজে পাওয়া যায় তাহলে সেটা ব্যবহার করতে হবে এবং এই ধাপে সেটা স্বাভাবিক ভাবেই Requirements এর পরিবির্তন করতে হবে।
- Application System Configuration: এখন যদি Requirements অনুযায়ী একই ধরনের কোন সফটওয়্যার থাকে থাকলে এই ধাপে এসে কনফিগারেশন করা এবং সফটওয়্যার ডেলিভারি দেওয়া
- Components Adaption and Integrations: যে সফটওয়্যার কম্পোনেন্টগুলো পাওয়া গেছে সেগুলো ব্যবহার এর জন্য প্রস্তুত করা এবং নতুন কম্পোনেন্টস গুলো তৈরি করা। সর্বশেষে এই দুইধরনের কম্পোনেন্টস গুলো একসাথে করা হয় এই ধাপে।
উপরে এই ধাপগুলোই কিন্তু অনুসরণ করা হয়েছিল।
Advantages
- Development time কমে যায়
- দ্রুত সফটওয়্যার ডেলিভারি করা যায়
- সফটওয়্যার গুনগত মান ঠিক থাকে এবং বৃদ্ধি পায়।
- ভবিষ্যতে ব্যবহার করা যায় এবং নতুন ফিচার সহজে যুক্ত করা যায়।
Disadvantages
- এই ধরনের সিস্টেম কনফিগার করা একটু জটিল
- Maintenance করা কষ্টদায়ক
- নিরাপত্তা ঝুকি থাকে
- অনেক কিছু পরিবর্তন করা যায় না
Ending
পরবর্তীতে integration and configuration model নিয়ে বিস্তারিত আলোচনা হবে।
Process Activities
সফটওয়্যার প্রসেস হল পর্যায়ক্রমে থাকা টেকনিক্যাল এবং ম্যানেজমেন্ট সহ জিজাইন, টেস্টিং ইত্যাদি বিষয়ের সুসংগঠিত কার্যাকলাপ। শুরু থেকে শুরু করে শেষ পর্যন্ত সব কিছুই উল্লেখ থাকে। বর্তমানে এসব কাজ গুলো সহজ করার জন্য অনেক টুল বিদ্যমান রয়েছে। এসব টুল ব্যবহার করা যায়।
তবে এসব activities এর মধ্যে ৪ টি মৌলিক activities বিদ্যমান।
- Software Specifications
- Software Design and Implementation
- Software Validation
- Software Evolution
Software Specifications
Software Specifications অথবা requirements engineering হল একটা প্রসেস, যা সফটওয়্যার এর প্রয়জনীয়তা সংগ্রহ , বিশ্লেষন, ডকুমেন্টেশন এবং বিভিন্ন প্রতিবন্ধকতা খুজে বের করা। এটা সফটওয়্যার ইঞ্জিনিয়ারিং এর প্রথম ধাপ। এটা দেখে মনে হবে খুবই সহজ জিনিস। কিন্তু এই ধাপের উপরে বাকি সব কিছু নির্ভর করে। এখানে একটু ত্রুটি হলে পরবর্তীতে সিস্টেম ডিজাইন করতে অনেক সমস্যার সম্মুখীন হতে হবে। এসে সমস্যা এড়াতেই প্রথম মার্কেট রিসার্স করা হয়, আদেও এই সফটওয়্যার কাজে দিবে কিনা। আদেও শ্রম এবং টাকা খরচ করে এই সফটওয়্যার কতটা যৌক্তিক তাও বোঝার চেষ্টা করা হয়।
Requirement Engineering-এ তিনটি প্রধান activities রয়েছে।
- Requirement Elicitation and analysis: এই ধাপে মুলত সিস্টেম সম্পর্কে বিভিন্ন তথ্য সংগ্রহ করা হয়। এক্ষেত্রে বিদ্যমান কোন সিস্টেম ,ব্যবহার কারীর ফিডব্যাক ইত্যাদি বিষয়-এ তথ্য সংগ্রহ করে তা বিশ্লেষন করা হয়।
- Requirement Specification: আগের ধাপের সংগ্রহ করা তথ্যের উপর ভিত্তি করে , এই ধাপে এসে কি কি জিনিস প্রয়োজন সেগুলোর ডকুমেন্ট করা হয়। এখানে User requirements এবং System requirements এই দুই ধরনের requirements এর ডকুমেন্ট থাকতে পারে।
- Requirements Validation: এই ধাপে এসে যে requirements এর ডকুমেন্ট তৈরি করা হয়েছে তা বাস্তবিক কিনা, আদেও এই Consistency এর থাকবে কিনা, সম্পূর্ণ করা যাবে কিনা ইত্যাদি চেক করা করা হয়। এই ধাপে অনেক ভুল দেখা দিতে পারে। দেওয়াটায় স্বাভাবিক। এই ভুল গুলো সংশোধন করে পুনরায় এই ধাপের কাজ করা।
Software Design and Implementation
Software Design হলো সফটওয়্যার এর আর্কিটেকচার, ডাটা মডেল এবং অন্যনা কম্পোনেন্ট এর সাথে সিস্টেম কিভাবে ইন্টারফেস করবে তার বিস্তারিত বর্ণনা।
প্রথমেই একটা সফটওয়্যার একবারে রেডি করা সম্ভব নয়, আস্তে আস্তে ধাপে বিভিন্ন ফিচার যুক্ত করা হয়। কিন্তু প্রথম স্টেপেই নির্ধারন করা হয় কোন টেকনোলজি, কোন আর্কিটেকচার ব্যবহার করে করা হবে। এই জন্য প্রথমে সফটওয়্যার এর জন্য একটা আর্কিটেকচার, ডাটা মডেল এবং প্রয়োজনীয় অনন্যা বিষয়গুলো নিয়ে বিস্তারতি ডকুমেন্ট তৈরি করা হয়। তবে এই ডকুমেন্ট যখন ই নতুন কোন ফিচার বা তথ্য যুক্ত করা হয় তখন এটা পরিবর্তন বা আপডেট করে ফেলা হয়।
একটা সিস্টেম বিভিন্ন সিস্টেম সফটওয়্যার এর সাথে ইন্টারফেস করে থাকে। এগুলোর বেশিরভাগই হলো অপারেটিং সিস্টেম, ডাটাবেসজ, মিডেলওয়্যার এবং বিভিন্ন থার্ড পার্টি সিস্টেম। সফটওয়্যার ডিজাইনের জন্য এই কম্পোনেন্ট বা সিস্টেম সফটওয়্যার গুলো গুরুত্বপূর্ণ ভুমিকা পালন করে থেকে। আর এই কম্পোনেন্ট গুলো ডিজাইনের শুরু ঠিক না করলে পরবর্তীতে অনেক সমস্যার সম্মুখীন হতে হয়।
সিস্টেম এর প্রয়োজনীয়তার উপর নির্ভর করে এই সফটওয়্যার ডিজাইন এর প্রসেস ভিন্ন ভিন্ন হতে পারে। উদাহরন হিসবে একটা রিয়েলটাইম কমিউনিকেশন সফটওয়্যার এর জন্য ডাটাবেজের কোন প্রয়োজন নেই। এখানে ডাটাবেজ-এ কোন তথ্যই সেইভ করার প্রয়োজন হয় না।
- Architectural design: এখানে সিস্টেম আর্কিটেকচার নির্ধারন করা হয়। কম্পোনেন্ট গুলো কিভাবে থাকবে এবং তাদের মধ্যে ইন্টাফেস কিভাবে হবে এই ধরনের কাজ গুলো নির্ধারন করা হয়।
- Database design: সিস্টেম আছে মানেই ডাটা অস্তিত্ব আছে। এখন ডাটা গুলো কিভাবে সংরক্ষন করা হবে , তা এই portion-এ এসে নির্ধারন করা হয়।
- Interface design: এখানে মুলত সিস্টেম কম্পোনেন্টগুলো ইন্টারফেস নির্ধারন করা হয়ে থাকে।
- Component selection and design: এই ধাপে এসে, প্রয়োজনীয় বিভিন্ন কম্পোনেন্ট খোজার চেষ্টা করা হয়। যদি কম্পোনেন্ট বিদ্যমান থাকে তাহলে তা ব্যবহারের জন্য নির্ধারন করা হয়। আর যদি না থাকে তাহলে ডিজাইনের কাজ কাজ করা হয়। এখানে কম্পোনেন্ট এর জন্য তথ্য দিয়ে প্রোগ্রামার এর জন্য রেখে দেওয়া হয়। এক্ষেত্রে UML (Unified Modeling Language) এর ব্যবহার হয়ে থাকে।
সবগুলো activities এর সম্বনয়ে একটা ডিজাইন আউটপুট জেনারেট হয়। এটাকে ব্যবহার করে সফটওয়্যার এর কাজ সামনের দিকে অগ্রসর হয়।
Software Validation
Software Validation অথবা সাধারন ভাবে verification and validation এর উদ্দেশ্য হল software specification মেনে চলা এবং customer expectation ফুলফিল করা। এক্ষেত্রে software specification এর উল্লেখিত ফিচারগুলো চাহিদা মোতাবেক কাজ করছে কিনা তা নিশ্চিত করা হয় । এজন্য বিভিন্ন ধরনের টেস্ট করা হয়ে থাকে। এসব টেস্ট গুলো প্রথমে থেকে শেষ পর্যন্ত সকল ধাপে করা যেতে পারে।
প্রাথমিক ভাবে সব টেস্ট গুলো সিমুলেটেড ডাটা দিয়ে করা হয়ে থাকে। পরবর্তীতে বেটা টেস্টিং এর জন্য দেওয়া হয়। তবে এসব টেস্ট গুলো বড় সিস্টেমের সিংগেল ইউনিট হিসেবে একবারে টেস্ট না করে, কম্পোনেন্ট আকারে টেস্ট করা শ্রেয়।
- Component testing: এই ধাপে প্রতিটি কম্পোনেন্টকে আলাদা আলাদা ভাবে টেস্ট করা হয়। এসব কম্পোনেন্ট গুলো ছোট ফাংশন ক্লাস ইত্যাদি হতে পারে। তবে এসব ছোট অনেকগুলো কম্পোনেন্ট একসাথে একটা কম্পোনেন্ট হতে পারে।
- System testing: এই ধাপে পুরা সিস্টেম কে এক সাথে টেস্ট করা হয়। এখানে সব কিছু হাইলেভেল এ থাকে। সিস্টেমে requirement অনুযায়ী ইনপুটের বিপরীতে সঠিক আউটপুট আসছে কিনা তা টেস্ট করা হয়। এখানে internal coding বা এর implementation নিয়ে কোন কিছু করা হয় না। ইনপুটের বিপরীতে সঠিক আউটপুট নিশ্চিত করে।
- Customer testing: Customer testing অনেক সময় বেটা টেস্টিংও বলা হয়ে থাকে। এই টেস্টিং কিছু সম্ভাব্য ব্যবহার কারীকে সফটওয়্যার এর আক্সেস দেওয়া হয় এবং তারা ব্যবহার করে তাদের ফিডব্যাক দিয়ে থাকে। বেশিরভাগ ক্ষেত্রেই সিমুলেটেড ডাটা দিয়ে টেস্ট করা কম্পোনেন্ট বা সিস্টেম, বাস্তবিক ভাবে ব্যবহারের ক্ষেত্রে অনেক ইসু দেখা যেতে পারে । এজন্য রিয়েল ডাটা দ্বারা টেস্টিং করা প্রয়োজন।
এসব স্টেজে বিভিন্ন ধরনের বাগ দেখা দিতে পারে। এসব বাগ গুলো ডিবাগ করা দরকার। এর জন্য আলাদা স্টেজ এর প্রয়োজন হতে পারে।
কম্পোনেন্ট টেস্টিং এর ক্ষেত্রে বেশিরভাগ সময় প্রোগ্রামার নিজেই টেস্ট কেস গুলো লিখে। কারন সেই কম্পোনেন্ট সম্পর্কে সব থেকে বেশি জ্ঞান রাখে। Test Driven Development এর ক্ষেত্রে প্রথমে টেস্ট কেস গুলো লেখা হয় এবং পরবর্তীতে টা ইমপ্লিমেন্ট করা হয়।
Testing in Plan Driven Architecture
PDA -এ কিছু নির্দিষ্ট প্লানের উপর নির্ভর করে সাম্নের দিকে আগ্রসর হয়। এখানে টেস্টিং এর জন্য একটা টিম থাকে যেখানে তার শুধু টেস্ট নিয়ে কাজ করে। উপরে চিত্রে দেখলেই বোঝা যাবে, এখানে প্রতিটি ধাপে টেস্টিং করা হয়ে থাকে।
Software Evolution
কোন একটা হার্ডওয়্যার প্রোডাক্ট একবারে তৈরি করা হয়ে গেলে সেখানে নতুন কোন পরিবর্তন করতে গেলে অতিরিক্ত মাত্রায় খরচ করতে হয়। কিন্তু সফটওয়্যার এর ক্ষেত্রে সেটা হয় না। সফটওয়্যার এর কোন কিছু পরিবর্তন করতে চাইলে অথবা নতুন ফিচার যুক্ত করতে চাইলে খুব বেশি খরচ করতে হয় না। হার্ডওয়্যার এর তুলনায় অনেক কম। এই জন্য একটা সফটওয়্যার সময়ের সাথে সাথে এর গ্রোথ বৃদ্ধি পায়। প্রাথমিক পর্যায় যা ছিল তার তুলনায় অনেক বেশি ফিচার সমৃদ্ধ হয়ে যায়। এভাবেই সফটওয়্যার evolve হতে থাকে।
Software Evolution কে maintenance এর সাথে তুলনা করা যেতে পারে। maintenance-এ মুলত ডিবাগিং করা হয়ে থাকে। বাগ ফিক্সিং এবং নতুন ফিচারের এর জন্যই সফটওয়্যার evolve হতে থাকে।
Coping with change
একটা বড় সফটওয়্যার প্রোজেক্ট-এ পরিবর্তন অনিবার্য। বিভিন কারনে সফটওয়্যার এর requirements পরিবর্তন হতে পারে। নতুন নতুন টেকনলজি তৈরি হচ্ছে এক্ষেত্রে নতুন পদ্ধতিতে সফটওয়্যার তৈরির করা হচ্ছে। নতুন পরিবর্তন সফটওয়্যার এর খরচ বৃদ্ধি করে কারন যে কাজ করা হয়ে গেছে সে কাজ আবার করতে হবে।
দুইটা পদ্ধতিতে এই খরচ কমানো সম্ভব।
- Change anticipation: এই পদ্ধতিতে সফটওয়্যার এর ভবিষ্যতের কথা চিন্তা ভাবনা করা হয়। একটা সফটওয়্যার-এ এমন অনেক ফিচার থাকতে পারে, যে গুলো নিকট ভবিষ্যতে অযৌক্তিক হয়ে যেতে পারে। এই ধরনের সমস্যা এড়াতে, প্রথমে একটা প্রোটোটাইপ তৈরি করা যেতে পারে, যেখানে কিছু প্রধান প্রধান ফিচার থাকবে। এবার কাষ্টমার এটা টেস্টিং করার পর তার requirements পরিবর্তন করতে পারেন। এক্ষেত্রে প্রডাকশন খরচ কমে যাবে।
- Change tolerance: সফটওয়্যার কে এমন ডিজাইন করতে হবে যেন খুব সহজেই এখানে পরিবর্তন করা যায়। এক্ষেত্রে Incremental Development পদ্ধতি অনুসরন করা হয়। নতুন পরিবর্তন বা আপডেট একটা increment হিসেবে অ্যাড করে দিলেই সফটওয়্যার প্রস্তুত।
এই পরিবর্তন কে মোকাবেলা অনেক ভাবেই করা যেতে পারে তবে এখানে ২ টা পদ্ধতি নিয়ে আলোচনা করা হবে।
- System Prototyping: এখানে সম্পূর্ন সিস্টেম তৈরি করার পূর্বে মুল ফিচারগুলো নিয়ে অল্প সময়ের মধ্যে একটা সিস্টেম তৈরি করা এবং কাস্টমার ফিডব্যাক প্রদান করে। এখানে requirements পরিবর্তন হতে পারে।
- Incremental delivery: এই পদ্ধতিতে সিস্টেম কে এমন ভাবে ডিজাইন করা হয় যাতে, খুব সহজেই পরিবর্তন বা পরিবর্ধন করা যায়। সফটওয়্যার তৈরি হওয়ার পর কোন পরিবর্তন আসলে সেখানে একটা নতুন একটা increment করলেই হয়ে যাবে।
Prototyping
Prototype হলো একটা সফটওয়্যার এর প্রাথমিক ভার্সন , যা ব্যবহার করা হয় সফটওয়্যারকে উপস্থাপন করতে, বিভিন্ন ডিজাইন try করতে এবং কোন সমস্যা থাকলে সেগুলো খুজে বের করে তার সম্ভাব্য সলুশন বের করার কাজে।
Prototype development এর জন্য development চলমান হতে হবে এই জন্য প্রতিনিয়ত development এর কাজ করতে হবে। নতুন নতুন ফিচার যুক্ত করতে হবে (অবশ্যই requirements অনুযায়ী প্রধান ফিচার গুলো)। এই Prototype একজন সম্ভাব্য ইউজারকে তার কাজে সাহয্য করবে। এখন তিনি যখন ব্যবহার করবেন তখন তার মাধায় নতুন নতুন requirement এর সৃষ্টি হতে পারে, যেগুলো অ্যাড করা প্রয়োজন। ব্যবহার করা ক্ষেত্রে অনেক এরর দেখা দিতে পারে যেটা requirement এ থেকে বাদ পড়ে গেছিলো।
একটা Prototype , প্রস্তাবিত ডিজাইন এর ফিসিবিলিটি টেস্টিং এর জন্য ব্যবহার করা যেতে পারে। উদারহর হিসবে, একটা সিস্টেম একসাথে একই সময়ে কত গুলো ইউজার এর request এর হ্যান্ডেল করতে সক্ষম তা চেক করা যেতে পারে।
Prototype Development
Prototype ডিজাইন করা শুরুতে এর উদ্দেশ্য ঠিক করতে হবে। এই উদ্দেশ্য হতে পারে , সফটওয়্যার এর ইন্টারফেস ডিজাইন, বিভিন্ন ভ্যালিডেশন চেক অথবফিসিবিলিটি টেস্টিং ইত্যাদি হতে পারে। একটা Prototype সকল উদ্দেশ্য পূরন করতে সক্ষম নয়। এই জন্য অনেক সময় ইউজার ভুল বুঝে থাকে। আসলে
Prototype এর উদ্দেশ্যই হলো মুল ফিচার গুলো নিয়ে একটা সিস্টেম বানানো। এখানে non-functional (response time, memory utilization etc) বিষয়গুলো ইচ্ছাকৃত ভাবে ইগনোর করা হয়ে থাকে। এখানে অনেক সময় এরর গুলো সঠিক হ্যান্ডেল নাও করা হতে পারে। এই সব কারনে সিস্টেম এর নির্ভরযোগ্যতা এবং মান কমে যেতে পারে।
সবশেষে Prototype তৈরি করা হয়ে গেলে , ইউজার এর ট্রেনিং এবং Prototype এর উদ্দেশ্যগুলো পূরন করার জন্য এই Prototype কে evaluate করা হয়। এক্ষেত্রে এসব ইউজারদের একটু সময় লেগে যায়। নতুন সিস্টেম ব্যবহার করতে সময় লাগাটায় স্বাভাবিক। তবে একবার সিস্টেম ব্যবহার এ comfortable হয়ে গেলে তখন তারা নতুন নতুন requirement আবিষ্কার করতে পারে।
তবে এখানে সমস্যা আছে, এই সব ইউজার ফাইনাল সিস্টেম কে যেভাবে ব্যবহার করতে চাই, সেভাবে এই Prototype কে সেইভাবে ব্যবহার নাও করতে পারে। এর কারন হতে পারে, slow response, slow processing, lots of errors ইত্যাদি।
Incremental Delivery
Incremental Delivery হলো এমন একটা পদ্ধতি যেখানে requirements গুলোকে অনেক গুলো ভাগে ভাগ করা হয়ে থাকে। এর ভিতরে কিছু ডেভোলোপ করা ভাগগুলো কাস্টমারের কাছে ডেলিভারি করা হয়েছে এবং তার মেশিনে ডেপলয় করা হয়েছে। এই ভাগ কিভাবে করা হবে, কোনটা আগে কোনটা পরে সেটা কাস্টমার ঠিক করে দেন। সবোর্চ প্রাইরিটির কাজগুলো আগে করা হয়।
যখন এসব কাজ গুলো হয়ে যায় , তখন প্রথম increment, ডেভোলোপ করা হয়ে গেছে তখন এই সিস্টেম ব্যবহার করা জন্য প্রস্তু হয়ে গেছে। তবে ডেভোলোপ করার সময় অনেক নতুন নতুন requirement এর দেখা দিতে পারে। এসব requirement গুলো প্রাইরিটি দিয়ে ডেভোলোপ করা হয়ে থাকে।
এবার সিস্টেম কে কাস্টমারে কম্পিউটারে রান করা জন্য প্রস্তুত। এখন কাস্টমার ব্যবহার করে দেখবে তার চাহিদা মোতাবেক কাজ হচ্ছে কিনা অথবা নতুন কোন ফিচার যুক্ত করা লাগবে কিনা। এখানে কাস্টমার সম্পূর্ণ সিস্টেমকে মূল্যায়ন করবেন এবং তিনি ফিডব্যাক দিবেন।
Advantages
Incremental Delivery এর কিছু সুবিধা আছে। যেমনঃ
- প্রথম Increment হওয়ার পরপর কাস্টমার সফটওয়্যার ব্যবহার করতে পারে এবং তার মতামত দিতে পারে। এটা Prototype এর সম্পূর্ণ বিপরীত। এই Increment গুলো মূলত সিস্টেমের অংশ। একবার শুরু থেকে শুরু করার প্রয়োজন হয় না।
- কাস্টমার কে সিস্টেম সম্পূর্ণ রেডি হওয়া পর্যন্ত অপেক্ষা করার প্রয়োজন হয় না। প্রথম Increment-এ প্রধান প্রধান ফিচার গুলো থাকে। এজন্য তৎক্ষণাৎ এই সিস্টেম ব্যবহার করা যায়।
- যেহেতে সবোর্চ প্রাইরিটি সার্ভিস গুলো আগে আগেই ডেলিভারি করা হয়। এইজন্য এইসমস্ত সার্ভিস গুলো সব থেকে বেশি টেস্ট করা হয়ে থাকে। এক্ষেত্রে এরর বা বাগ এর পরিমান তুলনা মূলক ভাবে অনেক কমে যায়। অনেক ক্ষেত্রে থাকেই না।
Disadvantages
Incremental Delivery এর কিছু অসুবিধা রয়েছে। যেমনঃ
- এই ধরনের পদ্ধতি নতুন সিস্টেম এর জন্য সব থেকে উপযুক্ত। যখন কোন বিদ্যামান সিস্টেমকে নতুন সিস্টেম দ্বারা replace করা জন্য এই পদ্ধতি ব্যবহৃত হয় তখন সমস্যার সৃষ্টি হয়। বিদ্যামান সিস্টেম অনেক ইউজার থাকে যার অনেকগুলো ফিচার ব্যবহার করে অভ্যস্ত। এখন হটাত করে যদি এসব ফিচার না থাকে অথবা ইউজার আক্সেস করতে না পারে তখন এসব ইউজার উক্ত সিস্টেম ব্যবহার করা বন্ধ করে দিতে পারে।
- বেশির সিস্টেমেই কিছু বেসিক কিছু ফিচার থাকে যেগুলো প্রায় সব জায়গায় ব্যবহার করা হয়ে থাকে। এখন এই পদ্ধতিতে অনেক ডিটেলস এ থাকে না। সেক্ষেত্রে এই বেসিক ফিচার গুলো খুজে বের করা কষ্টকর হতে পারে। আবার অনেক ক্ষেত্রে একই কোড বার বার লেখার প্রয়োজন হতে পারে।
- এখানে যেহেতু প্রতিনিয়তই ডেলিভারি করা হয়ে থাকে এবং এসব ডেলিভারির ফিডব্যাক গ্রহন করে সেখানে কাজ করা হয়। সেহেতু এখানে নো নির্দিষ্ট requirement থাকে না। এসব ক্ষেত্রে কাস্টমার এবং কম্পানির এর মধ্যে চুক্তি সংক্রান্ত বিভিন্ন সমস্যার সৃষ্টি হয়।
Ending
Incremental Delivery পদ্ধতি , বড় এবং জটিল সিস্টেমের জন্য সেরা পদ্ধতি নয়। মুলত এসব বড় সিস্টেম অনেক টিম একসাথে কাজ করে থাকে, এক্ষেত্রে অনিইচ্ছাকৃত ভাবে অনেক সমস্যার সৃষ্টি হতে পারে।
চুক্তি করার ক্ষেত্রে, প্রথমে একটা prototype ডিজাইন করে সেটার উপর বেজ করে একটা requirement specification এর ঠিক করে তার উপর বেজ করা চুক্তি সম্পন্ন করা যেতে পারে। নতুন কোন requirement আসলে সেটা পরবর্তী ফেজের জন্য রেখে দেওয়া যেতে পারে এবং পরবর্তী ফেজ একই ভাবে হ্যান্ডেল করা যেতে পারে
Process Improvement
Process Improvement এর মানে বিদ্যমান প্রসেস কে বোঝা এবং এসব প্রসেস পরিবর্তন করা যাতে প্রডাক্ট এর মান, খরচ এবং সময় কমে যায়।
দুই ধরনের পদ্ধতি ব্যবহার করা যেতে পারে।
- The process maturity: এই পদ্ধতিতে প্রসেস এবং প্রজেক্ট ম্যানেজমেন্ট এর উপর ফোকাস করা হয় এবং নতুন নতুন ইঞ্জিনিয়ারিং নিয়ম প্রয়োগ করা হয়। এই পদ্ধতির প্রধান উদ্দেশ্য হচ্ছে, প্রোডাক্ট এর মান বাড়ানো।
- The agile: এই পদ্ধতি মুলো ফোকাস করে প্রতিনিয়ত ডেভোলেপমেন্ট এর কাজ করে যাওয়া এবং প্রসেস এর অভারহেড কমিয়ে আনা। পরবর্তীতে এ নিয়ে বিস্তারিত আলোচনা হবে।