সফ্টওয়্যার জীবন বৃত্ত এবং জলপ্রপাত মডেল মূলতত্ব
v জীবনচক্র মডেল:
একটি
সফ্টওয়্যার জীবনচক্র মডেল (নামেও পরিচিত প্রক্রিয়া মডেল) হল এমন একটি
সফটওয়্যার জীবনচক্র এর বর্ণনামূলক এবং নকশাসংক্রান্ত প্রতিনিধিত্ব. একটি জীবনচক্র মডেল সব থেকে এর জীবনচক্র পর্যায়ক্রমে মাধ্যমে একটি সফটওয়্যার গমন করা প্রয়োজন কার্যকলাপ প্রতিনিধিত্ব করে. এটি ক্রম যা এই ক্রিয়াকলাপকে হয় গ্রহণ করার captures. অন্য কথায়, একটি জীবনচক্র মডেল বিভিন্ন অবসর থেকে এর শুরু থেকে একটি সফটওয়্যার উপর সঞ্চালিত কার্যকলাপ মানচিত্র. বিভিন্ন জীবনচক্র মডেল প্রাথমিক উন্নয়ন কর্মকান্ড বিভিন্ন উপায়ে পর্যায়ক্রমে মানচিত্রে পারে. সুতরাং,
কোন বিষয় যা জীবনচক্র মডেল অনুসরণ করা হয়, প্রাথমিক কাজকর্মের সব
জীবনচক্র মডেল যদিও কর্মকান্ড বিভিন্ন আদেশ বিভিন্ন জীবনচক্র মডেল বাহিত
হতে পারে আউট অন্তর্ভুক্ত করা হয়. কোনো জীবনচক্র সময়ে, এছাড়াও একাধিক কার্যকলাপ আউট বহন করা হতে পারে. উদাহরণস্বরূপ, নক্সা পর্যায়ের কাঠামোগত বিশ্লেষণ করুন কাঠামোগত নকশা কার্যকলাপ দ্বারা অনুসরণ দ্বারা গঠিত হতে পারে.
v একটি সফ্টওয়্যার জীবনচক্র মডেল জন্য প্রয়োজন:
উন্নয়ন দলের একটি উপযুক্ত বিশেষ প্রকল্পের জন্য জীবনচক্র মডেল সনাক্ত করুন এবং তারপর থেকে লেগে থাকা আবশ্যক. একটি নির্দিষ্ট জীবন চক্র মডেল ব্যবহার না করেই একটি সফটওয়্যার উন্নয়নের একটি নিয়মানুগ এবং বিনম্র পদ্ধতিতে হবে না. যখন
একটি সফটওয়্যার পণ্যের একটি দলের দ্বারা করা হচ্ছে উন্নত হতে সময় এবং কি
কি বিষয়ে দলের সদস্যদের মধ্যে পরিস্কারভাবে বুঝতে সেখানে আবশ্যক. অন্যথা এটি বিশৃঙ্খলার এবং প্রকল্প ব্যর্থতা হতে হবে. এই সমস্যার একটি উদাহরণ ব্যবহার করা যেতে পারে কারাগারে. একটি সফটওয়্যার উন্নয়ন সমস্যা কয়েকটি অংশে বিভক্ত করা হয় এবং মনে অংশ দলের সদস্যদের প্রদান করা হয়. থেকে তারপর, ঠাউর দলের সদস্যদের স্বাধীনতা যাই হোক না কেন তারা চান ক্ষেত্রে ধার্য তাদের অংশ উন্নত করার জন্য অনুমতি দেওয়া হয়. এটা
সম্ভব যে একজন সদস্য তার অংশ জন্য কোড লেখা শুরু হতে পারে, অন্য প্রথম
পরীক্ষা নথি প্রস্তুত, সিদ্ধান্ত এবং কিছু অন্যান্য প্রকৌশলী নিয়োগ তাকে
অংশ নক্সা পর্যায়ের সঙ্গে শুরু পারে. এই প্রকল্পের ব্যর্থতার জন্য নির্ভুল ইসলাম এক হতে হবে.
একটি সফ্টওয়্যার জীবনচক্র মডেল প্রত্যেক ফেজ জন্য এন্ট্রি করে প্রস্থান নির্ণায়ক সংজ্ঞায়িত করে. একটি ফেজ শুধুমাত্র যদি এর ফেজ-এন্ট্রি মানদণ্ড পূরণ করা হয়েছে আরম্ভ করতে পারেন. তাই সফ্টওয়্যার জীবনচক্র মডেল ছাড়া ফেজ জন্য এন্ট্রি করে প্রস্থান নির্ণায়ক স্বীকৃত করা সম্ভব নয়. সফ্টওয়্যার
জীবনচক্র মডেল ছাড়া তা কঠিন জন্য সফ্টওয়্যার প্রজেক্ট ম্যানেজার
প্রকল্পের অগ্রগতি উপর নজর রাখা (শাস্ত্রীয় জলপ্রপাত মডেল যেমন, জলপ্রপাত
মডেল, প্রোটোটাইপিং মডেল, অভিব্যক্তিমূলক মডেল, সর্পিল মডেল ইত্যাদি
পুনরাবৃত্ত).
v বিভিন্ন সফ্টওয়্যার জীবনচক্র মডেল:
অনেক জীবনচক্র মডেল এখন পর্যন্ত প্রস্তাবিত হয়েছে. প্রতিটিতে কিছু সুবিধার পাশাপাশি কিছু অসুবিধেও আছে. কয়েকটি গুরুত্বপূর্ণ এবং সাধারণভাবে ব্যবহৃত জীবনচক্র মডেল নিম্নরূপ:
শাস্ত্রীয় ওয়াটারফল মডেল
জলপ্রপাত মডেলের পৌন:
প্রোটোটাইপিং মডেল
বিবর্তনমূলক মডেল
স্পাইরাল মডেল
v শাস্ত্রীয় জলপ্রপাত মডেলের বিভিন্ন পর্যায়ক্রমে:
শাস্ত্রীয় জলপ্রপাত মডেল intuitively অধিকাংশ সুস্পষ্ট পথ থেকে সফ্টওয়্যার বিকাশ. যদিও
শাস্ত্রীয় জলপ্রপাত মডেলটি মার্জিত এবং intuitively সুস্পষ্ট, এটা একটা
ধারনা যে এটি আসল সফটওয়্যার উন্নয়ন প্রকল্পে ব্যবহার করা যাবে না বাস্তব
মডেল নয়. সুতরাং, এই আদর্শ বলে বিবেচনা করা একটি তাত্ত্বিক হতে যাবে সফ্টওয়্যার উন্নয়নশীল এর পথ. কিন্তু সব অন্যান্য জীবনচক্র মডেল মূলত শাস্ত্রীয় জলপ্রপাত মডেল থেকে উদ্ভূত. আদেশ তাই, অন্যান্য জীবনচক্র মডেল এটা শাস্ত্রীয় জলপ্রপাত মডেল শিখতে প্রয়োজনীয় তারিফ করা সক্ষম হবে.
শাস্ত্রীয় জলপ্রপাত মডেল নিম্নলিখিত পর্যায়ক্রমে মধ্যে জীবন চক্র ভাগ fig.2.1 এ প্রদর্শন করা হয়েছে:
সম্ভাব্যতা সমীক্ষা
আবশ্যকতা বিশ্লেষণ এবং স্পেসিফিকেসন
নকশা
কোডিং এবং ইউনিট টেস্টিং
ইন্টিগ্রেশন এবং সিস্টেম টেস্টিং
রক্ষণ
ডুমুর 2.1: বাংলাদেশী ওয়াটারফল মডেল
O
জীবনচক্র প্রতিটি পর্যায়ে ক্রিয়াকলাপ
1.
ক্রিয়াকলাপ সম্ভাব্যতা সমীক্ষা সময় প্রারব্ধ: -
সম্ভাব্যতা সমীক্ষা এর প্রধান উদ্দেশ্য হল কিনা তা আর্থিকভাবে এবং টেকনিক্যালি থেকে পণ্য বিকাশ সম্ভবপর হবে নির্ধারণ করা যায়.
নেতাদের একটি কি ক্লায়েন্ট প্রান্তের পরিদর্শন করা প্রয়োজন সম্পর্কে মোটামুটি অবগত প্রথম প্রজেক্ট ম্যানেজার বা দল চেষ্টা. তারা বিভিন্ন সিস্টেম এবং আউটপুট ডাটা সিস্টেম দ্বারা উত্পাদিত হবে ইনপুট ডেটা অধ্যয়ন. তারা অধ্যয়ন কি প্রক্রিয়াকরণ ধরনের এইসব তথ্যের করা প্রয়োজন এবং তারা সিস্টেম ব্যবহারের উপর বিভিন্ন সীমাবদ্ধতা তাকান.
পরে তারা একটি সমস্যা সামগ্রিক অবগত তারা বিভিন্ন সমস্যার সমাধান যে সম্ভব তদন্ত. এর
পরে তারা কি ধরনের সম্পদ প্রয়োজন পদ সমাধানের প্রতিটি পরীক্ষা, কি
উন্নয়ন খরচ হতে পারে এবং কি প্রত্যেক সমাধানের জন্য উন্নয়ন সময় হতে হবে.
এই বিশ্লেষণের উপর ভিত্তি করে তারা সবচেয়ে ভালো সমাধান বাছাই এবং কিনা সমাধান সম্ভবপর আর্থিকভাবে এবং টেকনিক্যালি নির্ধারণ করা. তারা কিনা গ্রাহকদের বাজেট উৎপাদন ব্যয় মেটাতে হবে এবং কিনা তারা উন্নয়নের ক্ষেত্রে যথেষ্ট প্রযুক্তিগত দক্ষতা আছে.
নিম্নলিখিত একটি সম্ভাব্যতা সমীক্ষা একটি প্রতিষ্ঠানের দ্বারা প্রারব্ধ এর একটি উদাহরণ. এটা
আপনার কাজকর্ম এবং সমস্যাগুলি সাধারণত সফ্টওয়্যার প্রকল্পের সম্ভাব্যতা
সমীক্ষা পর্যায়ে জড়িত একটি দ্বিধা বোধ করা দেয়ার উদ্দেশ্যে করা হচ্ছে.
ü কেস স্টাডি
একটি মাইনিং কোম্পানী নামক আকাশগঙ্গা মাইনিং কোম্পানি লিমিটেড (GMC) ভারতে বিভিন্ন স্থানে অবস্থিত খনি রয়েছে. প্রায় পঞ্চাশ বিভিন্ন খনি আট রাজ্য জুড়ে ছড়িয়ে সাইট আছে. কোম্পানির প্রতিটি খনি সাইটে একটি খনি সংখ্যক নিয়োগ. মাইনিং
হচ্ছে একটি ঝুঁকিপূর্ণ পেশা, কোম্পানি থেকে একটি বিশেষ তহবিল, যেটি মান
ভবিষ্য তহবিল যে ইতিমধ্যে miners ভোগ ছাড়াও উপস্থিত হবে পরিচালনা ইচ্ছুক. জমিদারি বিশেষ ভবিষ্য তহবিল (SPF) হবে প্রধান লক্ষ্য দ্রুত কিছু ক্ষতিপূরণ বিতরণ আগে মান মিতব্যয়ী পরিমাণ দেওয়া হয়. এই
পরিকল্পনা অনুযায়ী, প্রতিটি খনি সাইটের প্রতিটি খনিজীবী থেকে SPF
কিস্তিতে প্রতি মাস কেটে নেওয়া হবে CSPFC (সেন্ট্রাল বিশেষ প্রভিডেন্ট
ফান্ড কমিশনার) সঙ্গে একই জমা. CSPFC সব SPF miners থেকে সংগৃহীত কিস্তিতে সংক্রান্ত বিবরণ বজায় রাখা হবে. GMC
সমস্ত কর্মচারীদের SPF রেকর্ড রক্ষণাবেক্ষণ স্বয়ংক্রিয় জন্য সফ্টওয়্যার
উন্নয়নশীল এর টাস্ক দায়িত্বগ্রহণ করা একটি তথাকথিত সফ্টওয়ের বিক্রেতার
সাহসিক সফটওয়্যার ইনক নিযুক্ত. GMC উপলব্ধি করেন যে হিসাবরক্ষণ কাজ জনশক্তি সংরক্ষণ ছাড়াও, সফ্টওয়্যার দাবী মামলা দ্রুত নিষ্পত্তির সাহায্য করবে. GMC যে পরিমাণ এই সফ্টওয়্যার জন্য সামর্থ্য যাবে উন্নত এবং ইনস্টল হল Rs. 1 মিলিয়ন.
সাহসিক সফটওয়্যার ইনক থেকে সম্ভাব্যতা সমীক্ষা চালায় তাদের প্রকল্প ব্যবস্থাপক deputed. প্রকল্প ব্যবস্থাপক GMC উপরের পরিচালকদের বিষয়ে প্রকল্পের একটি পরিদর্শন পেতে আলোচনা. তিনি জড়িত বেশ কিছু বিভিন্ন খনি সাইট এ ক্ষেত্র PF অফিসারদের সঙ্গে প্রকল্পের সঠিক বিবরণ নির্ধারণ বিষয় আলোচনা. প্রকল্প ব্যবস্থাপক থেকে সমস্যার সমাধান দুটি বিস্তৃত পন্থা চিহ্নিত. একটি কেন্দ্রিয় ডাটাবেসের যা ব্যবহার একটি বিভিন্ন খনি সাইট থেকে উপগ্রহ সংযোগ মাধ্যমে হতে পারে এবং আপডেট করা আছে. অন্যান্য পদ্ধতি প্রতিটি খনি সাইটে স্থানীয় উপাত্ত এবং কেন্দ্রিয় ডাটাবেস আপডেট পর্যায়ক্রমে একটি ডায়াল আপ সংযোগ মাধ্যমে ছিল. এই
পর্যায়ক্রমিক আপডেট প্রতিদিন অথবা প্রতি ঘণ্টায় ভিত্তি সফ্টওয়্যার
বিভিন্ন কার্যাবলী invoking মধ্যে বিলম্ব গ্রহণযোগ্য GMC উপর এটা নির্ভর
করা যেতে পারে করা. প্রকল্প
ব্যবস্থাপক পাওয়া যে দ্বিতীয় পন্থা ছিল অত্যন্ত সাশ্রয়ী মূল্যের এবং
আরও ত্রুটি সহিষ্ণু হিসাবে এখনও স্থানীয় খনি সাইট কাজ এমনকি যখন
সাময়িকভাবে কেন্দ্রিয় ডাটাবেসের সাথে যোগাযোগ লিংক ব্যর্থ হতে পারে. প্রকল্প
ব্যবস্থাপক দ্রুত ডাটাবেস functionalities প্রয়োজন, ইউজার ইন্টারফেস
বিষয়, এবং মাইন সাইট সঙ্গে সফ্টওয়্যার পরিচালনা যোগাযোগ বিশ্লেষণ. তিনি একটি খরচ বিশ্লেষণ থেকে বিকশিত করার আগত. তিনি
দেখেন যে সমাধান খনি সাইট এবং মেয়াদী একটি কেন্দ্রিয় ডাটাবেসের আপডেট
স্থানীয় উপাত্ত রক্ষণাবেক্ষণ জড়িত ছিল আর্থিকভাবে এবং টেকনিক্যালি
সম্ভবপর. প্রকল্প ব্যবস্থাপক GMC পরিচালনার সঙ্গে তার সমাধান এবং আলোচনা পাওয়া যে সমাধান ছিল গ্রহণযোগ্য তাদের পাশাপাশি.
2. ক্রিয়াকলাপ প্রয়োজনীয়তা বিশ্লেষণ এবং স্পেসিফিকেশন সময় প্রারব্ধ: -
প্রয়োজনীয়তা বিশ্লেষণ এবং স্পেসিফিকেশন ফেজ লক্ষ্য গ্রাহকের সঠিক প্রয়োজন ও বুঝতে সঠিকভাবে তাদের নথিতে হল. এই পর্বটিকে দুটি স্বতন্ত্র কাজকর্ম, যেমন গঠিত
প্রয়োজনীয় বস্তু সংগ্রহ এবং বিশ্লেষণ, এবং
প্রয়োজনসমূহের সবিস্তার বিবরণী
প্রয়োজনীয় বস্তু সংগ্রহ কার্যকলাপের লক্ষ্য গ্রাহকের হবে উন্নত থেকে পণ্য সংক্রান্ত থেকে সমস্ত প্রাসঙ্গিক তথ্য সংগ্রহ করা হল. এই পরিষ্কারভাবে ক্রেতাসাধারণের প্রয়োজনীয়তা যাতে অপূর্ণতা এবং অসঙ্গতি সরিয়ে ফেলা হয় বুঝতে করা হয়.
প্রয়োজনীয়তা
বিশ্লেষণ কার্যকলাপ সমস্ত প্রাসঙ্গিক থেকে পণ্য ব্যবহারকারীদের থেকে
সাক্ষাত্কার এবং আলোচনার মাধ্যমে গ্রাহকের উঠা পণ্য সংক্রান্ত তথ্য সংগ্রহ
দ্বারা শুরু করা হয়. উদাহরণস্বরূপ,
একটি ব্যবসা অ্যাকাউন্টিং সফটওয়্যার প্রতিষ্ঠানের দ্বারা প্রয়োজন
প্রয়োজনীয়তা বিশ্লেষণ সঞ্চালন, বিশ্লেষক সমস্ত প্রতিষ্ঠানের জন্য তাদের
প্রয়োজনীয়তা অনুধাবন করা অ্যাকান্ট্যান্টস ইন্টারভিউ করা হতে পারে. যেমন
ব্যবহারকারীদের একটি গ্রুপ থেকে সংগৃহীত ডেটা সাধারণত কয়েকটি অসঙ্গতি এবং
ambiguities ধারণ করে, যেহেতু সাধারণত প্রত্যেক ব্যবহারকারীর শুধুমাত্র
একটি সিস্টেমের আংশিক এবং অসম্পূর্ণ দৃশ্য রয়েছে. তাই এটা সব ambiguities প্রয়োজনীয়তা এবং অসঙ্গতি চিহ্নিত গ্রাহকের সঙ্গে আরো আলোচনা মাধ্যমে তাদের সমাধান প্রয়োজন. পরে
সব ambiguities, অসঙ্গতি, এবং অপূর্ণতা এবং সমস্যার সমাধান করা হয়েছে সব
প্রয়োজনীয়তা সঠিকভাবে বোঝা যায়, প্রয়োজনের স্পেসিফিকেশন কার্যকলাপ
আরম্ভ করতে পারেন. এই
ধরনের কার্যকলাপের সময়, ব্যবহারকারী প্রয়োজনীয়তা ধারাক্রমে একটি
সফ্টওয়্যার সংক্রান্ত আবশ্যক মান স্পেসিফিকেসন (SRS) নথি মধ্যে সংগঠিত
হয়.
ক্রেতাসাধারণের প্রয়োজনীয়তা বস্তু সংগ্রহ এবং বিশ্লেষণ কার্যকলাপ সময় সংক্রান্ত আবশ্যক মান গণ্য একটি SRS নথি সংগঠিত করা হয়. এই ডকুমেন্টের গুরুত্বপূর্ণ উপাদান হল ক্রিয়ামূলক প্রয়োজনীয়তা, অ ক্রিয়ামূলক প্রয়োজন, এবং বাস্তবায়ন গোল.
3. ক্রিয়াকলাপ নকশা সময় প্রারব্ধ: -
নক্সা
পর্যায়ের মূল উদ্দেশ্য হল একটি কাঠামো যা কিছু প্রোগ্রামিং ভাষা
বাস্তবায়ন জন্য উপযুক্ত মধ্যে SRS নথিতে উল্লেখ করা প্রয়োজন রূপান্তরিত
হল. নকশা সময়ে পরিভাষা ইন, সফটওয়্যার আর্কিটেকচার SRS নথি থেকে উদ্ভূত হয়. দুই বিভিন্ন স্বতন্ত্র্র বৈশিষ্ট্যে পন্থা উপলব্ধ রয়েছে: ঐতিহ্যগত নকশা পদ্ধতি এবং অবজেক্ট ওরিয়েন্টেড-নকশা পদ্ধতি.
পরম্পরাগত নকশা অভিগমন:
পরম্পরাগত
নকশা দুই বিভিন্ন কার্যক্রম রয়েছে; প্রথম একটি প্রয়োজনীয়তা নির্দিষ্ট
কাঠামোগত বিশ্লেষণ আউট বাহিত যেখানে সমস্যার বিস্তারিত গঠন পরীক্ষা করা
হয়. এই একটি কাঠামোগত নকশা কার্যকলাপ দ্বারা অনুসরণ করা হয়. স্ট্রাকচার্ড নকশা সময়, কাঠামোগত বিশ্লেষণ ফলাফল সফ্টওয়্যার নকশা মধ্যে রুপান্তরিত হয়.
অবজেক্ট ওরিয়েন্টেড-নকশা অভিগমন
এই
টেকনিক, প্রথম বিভিন্ন বস্তু সমস্যা ডোমেইন এবং সমাধান ডোমেইনে যে ঘটতে
সনাক্ত করা হয়, এবং বিভিন্ন সম্পর্ক এই বস্তুর মধ্যে যে অস্তিত্ব সনাক্ত
করা হয়. বস্তুর গঠন করা হয় আরো বিস্তারিত নকশা প্রাপ্ত পরিশ্রুত.
4. ক্রিয়াকলাপ কোডিং এবং ইউনিট টেস্টিং সময় প্রারব্ধ: -
কোডিং
এবং একক সফটওয়্যার উন্নয়ন পরীক্ষামূলক ফেজ (কখনও কখনও বলা হয়
বাস্তবায়ন ফেজ) উদ্দেশ্য হল সোর্স কোডটি সফ্টওয়্যার নকশা অনুবাদ করা হল. নকশা প্রতিটি উপাদানের একটি প্রোগ্রাম মডিউল রূপে রূপায়িত হয়. এই পর্বটির শেষ উপজাতক হল প্রোগ্রাম মডিউল স্বতন্ত্রভাবে হয়েছে পরীক্ষিত একটি সেট.
এই সময়ে, প্রতিটি মডিউল হল ইউনিট থেকে সব প্রতিটি মডিউল এর সঠিক কাজের নির্ধারণ পরীক্ষিত. এর
মধ্যে অন্তর্ভূক্ত আছে বিচ্ছিন্নতার প্রতিটি মডিউল পরীক্ষা হিসাবে এটি
সর্বাপেক্ষা কার্যকরী পদ্ধতি এই পর্যায়ে চিহ্নিত ত্রুটি ডিবাগ.
5. ক্রিয়াকলাপ ইন্টিগ্রেশন এবং সিস্টেম পরীক্ষণের সময় প্রারব্ধ: -
বিভিন্ন মডিউল একীকরণ একবার তারা এবং কোডেড হয়েছে ইউনিট পরীক্ষা নেওয়া হয়. ইন্টিগ্রেশন এবং সিস্টেম টেস্টিং সময়ে, মডিউল একটি পরিকল্পিত এমনভাবে একত্রিত করা হয়. বিভিন্ন তৈরীর একটি সফটওয়্যার আপ মডিউল প্রায় হয় ইন্টিগ্রেটেড এক শট না. ইন্টিগ্রেশন সাধারণত হয় বাহিত ধাপের একটি সংখ্যা বেশি ক্রমানুসারে আউট.
সময় প্রতিটি ইন্টিগ্রেশন ধাপে, আংশিকভাবে ইন্টিগ্রেটেড সিস্টেম এবং পরীক্ষিত পূর্বে পরিকল্পনা মডিউল একটি সেট এটি যোগ করা হয়. অবশেষে, যখন সকল মডিউল সাফল্যের সাথে সম্পন্ন হয়েছে ইন্টিগ্রেটেড এবং পরীক্ষিত, সিস্টেম টেস্টিং আউট বাহিত হয়. সিস্টেম টেস্টিং মূল উদ্দেশ্য হল যে উন্নত সিস্টেমের SRS নথিতে পরিপূর্ণ প্রয়োজনীয়তা কে কনর্ফাম করে নিশ্চিত হল.
সিস্টেম টেস্টিং সাধারণত তিনটি পরীক্ষার কার্যক্রম বিভিন্ন প্রকারের অন্তর্ভুক্ত রয়েছে:
α - টেস্টিং: এটা সিস্টেম টেস্টিং উন্নয়ন দল দ্বারা সঞ্চালিত.
β - টেস্টিং: এটা সিস্টেম টেস্টিং একটি গ্রাহকদের বন্ধুত্বপূর্ণ সেট দ্বারা সঞ্চালিত.
গ্রহণযোগ্যতার পরীক্ষা: এটা সিস্টেম টেস্টিং পণ্য বিতরণ কিনা বা গ্রহণ নিষ্কৃত পণ্য প্রত্যাখ্যান নির্ধারণের পরে গ্রাহকের নিজেকে দ্বারা সঞ্চালিত.
সিস্টেম টেস্টিং সাধারণত হয় একটি পরিকল্পিত পদ্ধতিতে পরিচালিত সিস্টেম পরীক্ষা পরিকল্পনা নথি অনুযায়ী. সিস্টেম পরীক্ষা পরিকল্পনা সব পরীক্ষা সম্পর্কিত কাজকর্মের যে সঞ্চালন করা আবশ্যক চিহ্নিত করা, পরীক্ষার সময়সূচী নির্ধারণ
এবং বন্টন সম্পদ. এছাড়াও প্রতিটি পরীক্ষা কেস জন্য সব পরীক্ষা ক্ষেত্রে এবং প্রত্যাশিত ফলাফলে প্রদর্শিত হবে.
6. ক্রিয়াকলাপ রক্ষণাবেক্ষণ সময় প্রারব্ধ: -
সাধারণ সফটওয়্যার রক্ষণাবেক্ষণ প্রচেষ্টা প্রয়োজন পণ্য নিজেই বিকাশ বেশি প্রয়োজন. আরো
অনেক গবেষণা অতীতে চালিয়ে এই নিশ্চিত এবং নির্দেশ করে যে একটি সাধারণ
সফটওয়্যার উন্নয়ন আপেক্ষিক এর রক্ষণাবেক্ষণ প্রচেষ্টা প্রচেষ্টা 40:60
অনুপাত মধ্যে প্রায় হল. রক্ষণাবেক্ষণ জড়িত কোনো এক নিম্নলিখিত কার্যকলাপের তিন প্রকারের অথবা অধিক করণ:
ত্রুটি যে পণ্য বিকাশ সময়ে আবিষ্কৃত হয়নি সংশোধন. এই সংশোধনী রক্ষণাবেক্ষণ বলা হয়.
সিস্টেম বাস্তবায়ন উন্নতি, এবং গ্রাহকের প্রয়োজনীয়তা অনুযায়ী সিস্টেমের functionalities বৃদ্ধিকারী. এই perfective রক্ষণাবেক্ষণ বলা হয়.
একটি নতুন পরিবেশে কাজ করার জন্য সফ্টওয়্যার Porting. উদাহরণস্বরূপ,
porting প্রয়োজন একটি নতুন কম্পিউটার প্ল্যাটফর্মের উপর অথবা একটি নতুন
অপারেটিং সিস্টেম কাজ করার জন্য সফ্টওয়্যার পাওয়া যেতে পারে. এই অভিযোজিত রক্ষণাবেক্ষণ বলা হয়.
v শাস্ত্রীয় জলপ্রপাত মডেল Shortcomings:
শাস্ত্রীয়
জলপ্রপাত মডেল একটি আধ্যাত্মবাদী এক যেহেতু এটা অনুমান করা যে কোন উন্নয়ন
ত্রুটি কখনো ইঞ্জিনিয়ারদের হয় জীবনচক্র পর্যায়ের কোনো সময়
প্রতিশ্রুতিবদ্ধ. বাস্তবিক উন্নয়ন পরিবেশের তবে,, প্রকৌশলীরা ত্রুটি বৃহৎ সংখ্যা প্রায় জীবনচক্র প্রতিটি পর্যায়ে না করা. ত্রুটি
উত্স অনেক হতে পারে: ভ্রম, সাধারণত ভুল অনুমিতি, অনুপযুক্ত প্রযুক্তির
ব্যবহার, প্রকল্প ইঞ্জিনিয়ারদের মধ্যে যোগাযোগ ফাঁক, ইত্যাদি এই ত্রুটি
সনাক্ত অনেক পরে জীবনচক্র পেতে. উদাহরণস্বরূপ, একটি ডিজাইন ত্রুটি অলক্ষিত পর্যন্ত আমরা কোডিং বা ফেজ পরীক্ষণের পৌঁছানোর যেতে পারে. একবার
একটি ত্রুটি সনাক্ত করা হলে, ইঞ্জিনিয়ার থেকে ফেজ ফিরে যান যেখানে ত্রুটি
ঘটেছে ছিল এবং যে কাজ করিয়েছেন যে ফেজ এবং পরবর্তী পর্যায়ের সঙ্গে সময়
পরে পর্যায়ক্রমে উপর ত্রুটি এবং এর প্রভাব সংশোধন কিছু করা প্রয়োজন. কোনো ব্যবহারিক সফটওয়্যার উন্নয়ন কাজের অতএব, এটি কঠোরভাবে শাস্ত্রীয় জলপ্রপাত মডেল অনুসরণ করা সম্ভব নয়.
v প্রত্যেক পর্যায়ের ফেজ-ভুক্তি এবং ফেজ-প্রস্থান বৈশিষ্ট্যঃ
সম্ভাব্যতা
নিয়ে চর্চা শুরু হয়, প্রজেক্ট ম্যানেজার বা দলের নেতাদের কি ক্লায়েন্ট
প্রান্তের পরিদর্শন প্রকৃত সমস্যা বুঝতে চেষ্টা করুন. যে ফেজ শেষে তারা ভালো সমাধান বাছাই এবং কিনা সমাধান সম্ভবপর আর্থিকভাবে এবং টেকনিক্যালি নির্ধারণ করা.
প্রয়োজনীয়তা বিশ্লেষণ এবং স্পেসিফিকেশন ফেজ শুরু প্রয়োজনীয় তথ্য সংগ্রহ করা হয়. পরে যে প্রয়োজন স্পেসিফিকেশন আউট বাহিত হয়. অবশেষে, SRS নথি উত্পাদিত হয়.
নক্সা পর্যায়ের, কনটেক্সট ডায়াগ্রাম এবং DFDs বিভিন্ন স্তরের শুরু থেকে SRS নথি অনুযায়ী উত্পাদিত হয়. এই ফেজ মডিউল গঠন শেষে (গঠন লেখচিত্র) উত্পাদিত হয়.
আইনসংগ্রহ সময়ে প্রতিটি নকশা মডিউল (স্বাধীনভাবে কম্পাইলেশন ইউনিট) একটি কোডেড হয়. এর পরে প্রতিটি মডিউল Stand-Alone ইউনিট হিসেবে পরীক্ষিত স্বাধীনভাবে হয় এবং debugged আলাদাভাবে. এই পরে পৃথকভাবে প্রত্যেক মডিউল নথিভুক্ত করা হয়. বাস্তবায়ন পর্যায়ে শেষ পণ্য হল প্রোগ্রাম মডিউল স্বতন্ত্রভাবে আছে পরীক্ষা কিন্তু একসঙ্গে পরীক্ষা না একটি সেট.
বাস্তবায়ন পর্যায়ের পর, বিভিন্ন মডিউল যা স্বতন্ত্রভাবে আছে পরীক্ষিত হয়েছে একটি পরিকল্পিত এমনভাবে একত্রিত করা হয়. পরে সমস্ত মডিউল সাফল্যের সাথে সম্পন্ন হয়েছে ইন্টিগ্রেটেড এবং পরীক্ষিত, সিস্টেম টেস্টিং আউট বাহিত হয়.
সফটওয়ার রক্ষনা বেক্ষণ কোনো প্রণীত একটি সফটওয়্যার থেকে পরে গ্রাহকের হয়েছে বিতরণ পরিবর্তন উল্লেখ করে. উত্পাদনের প্রায় কোনো ধরনের জন্য পরিচালনার অবশ্যম্ভাবী. তবে, অধিকাংশ পণ্য রক্ষণাবেক্ষণের কারণে পরিধান এবং টিয়ার ব্যবহারের ফলে প্রয়োজন.
