প্রশাসক এবং সফ্টওয়্যার প্রয়োজনীয়তা

সফ্টওয়্যার ইঞ্জিনিয়ারদের প্রায়শই যে সমস্যাগুলি সমাধান করতে হয় তা অত্যন্ত জটিল। সমস্যার প্রকৃতি বোঝা খুব কঠিন হতে পারে, বিশেষত যদি সিস্টেমটি নতুন হয়।

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

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

যখন ব্যবহারকারীর প্রয়োজনীয়তাগুলিতে অত্যধিক তথ্য অন্তর্ভুক্ত থাকে তখন তারা ব্যবহারকারীদের সমস্যার উদ্ভাবনী সমাধান সরবরাহ করতে এবং প্রয়োজনীয়তা বুঝতে অসুবিধে করার জন্য সিস্টেম বিকাশকারীর স্বাধীনতা বাধা দেয়। ব্যবহারকারীর প্রয়োজনীয়তাগুলি প্রদান করা প্রধান সংস্থানগুলিতে কেবল ফোকাস করা উচিত।

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

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

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

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

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

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

এই নকশার ধাপটি একটি সংজ্ঞায়িত সুযোগ, উন্নয়ন পরিকল্পনা, ঝুঁকি বিশ্লেষণের অস্তিত্ব নিশ্চিত করে যেখানে গ্রাহকরা উপরের সাথে একমত এবং ডেটা গুদাম নির্মাণের জন্য একটি কার্যকর কৌশল রয়েছে have

এই পর্যায়ে কিছু সাধারণ ভুল রয়েছে যা আপনার এড়ানো উচিত:

• মনে করুন এটি একটি traditionalতিহ্যগত উপায়ে প্রয়োজনীয়তাগুলি নির্ধারণের একটি পর্যায়।যদি মনে করেন আপনার নিখুঁত মডেল এবং পরিকল্পনা থাকতে হবে।প্রজেক্টের শুরুতে একটি সম্পূর্ণ ডেটা মডেল তৈরি করার চেষ্টা করুন।

উত্পন্ন শিল্পকর্মগুলি:

• প্রকল্প পরিকল্পনা ভিশন ব্যবহারের ক্ষেত্রে ধারণা ধারণা ডায়াগ্রাম ডিপ্লোয়মেন্ট ডায়াগ্রাম গ্রাহকের অনুমোদন আইন

সংস্থাগুলি সফ্টওয়্যার প্রকল্পগুলির উন্নয়নের জন্য যে কারণগুলি RUP ব্যবহার করে তা হ'ল:

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

প্রয়োজনীয়তার পরিবর্তনগুলি একটি বিবর্তনীয় এবং নমনীয় উচ্চ সহযোগিতা পদ্ধতির দাবি করে The

গ্রন্থ-পঁজী

আয়ান সামারভিলি, " সফটওয়্যার ইঞ্জিনিয়ারিং ", 6th ষ্ঠ সংস্করণ। পিয়ারসন এডুকেশন, 2002

আই আর্চার পুপো, "ইউনিফাইড ডেভলপমেন্ট প্রসেসের পর্যায়সমূহ"।