প্রয়োজনে ব্যয় করা সময় এবং প্রকল্পের সাফল্য এবং বিকাশের সময়ে এর প্রভাব


15

লেখার জন্য ব্যয় করা সময়, বা প্রয়োজনীয়তাগুলি নিয়ে চিন্তাভাবনার ফলে বিকাশের কোনও প্রভাব পড়বে কি এমন কোনও প্রমাণ রয়েছে? স্ট্যান্ডিশ (1995) দ্বারা করা অধ্যয়ন পরামর্শ দেয় যে অসম্পূর্ণ প্রয়োজনীয়তাগুলি (13.1%) প্রকল্পগুলির ব্যর্থতায় অবদান রেখেছিল। এমন কোনও গবেষণা করা হয়েছে যা দেখায় যে প্রয়োজনীয়তা বিশ্লেষণে ব্যয় করা সময় কোনও প্রকল্পের বিকাশের সময় বা প্রকল্পটি কতটা সফল হবে তার কোনও প্রভাব ফেলবে।


3
চটপটে মডেলগুলি এখানে কীভাবে ফিট করে? যে কেউ তর্ক করতে পারে যে তারা প্রয়োজনীয়তার সময় ব্যয় করে (চালু এবং বন্ধ) তবে কোনও প্রয়োজনীয়তা "ধাপ" নেই।
রাফেল

1
@ রাফেলের সাথে একমত আমরা কি সফটওয়্যার ইঞ্জিনিয়ারিংয়ে প্রশ্ন নিতে যাচ্ছি? অথবা সাইটের সরকারী নীতি কি এই সময়ে "কম্পিউটার বিজ্ঞান" এবং "সফটওয়্যার ইঞ্জিনিয়ারিং" এর মধ্যে পার্থক্য করা সার্থক নয়?
প্যাট্রিক 87

1
@ Patrick87 আসুন আমাদের এই সরাতে মেটা
রাফেল

আমার কাছে মনে হচ্ছে বিদ্যমান সফ্টওয়্যার ইঞ্জিনিয়ারিং এবং প্রকল্প পরিচালনা সাইটগুলির জন্য এই প্রশ্নটি আরও ভাল ফিট হবে ।
অ্যাডাম শিখুন

উত্তর:


10

স্টিভ ম্যাককনেল দ্বারা সারণী 3-1-এ কোড সম্পূর্ণ দেখুন। ত্রুটিগুলি যখন পরিচয় করানো হয় এবং সনাক্ত করা হয় তার ভিত্তিতে তিনি ফিক্সিংয়ের গড় ব্যয়ের তুলনা করেন। নির্মাণের সময় সনাক্তকরণের জন্য প্রয়োজনীয় সময়ে সনাক্তকরণের চেয়ে 5-10 গুণ বেশি এবং রিলিজের পরে 10-100 গুণ বেশি খরচ হয়।

সারণিটি নিম্নলিখিত উত্সগুলির উপর ভিত্তি করে:

  1. "প্রোগ্রাম ডেভেলপমেন্টে ত্রুটিগুলি হ্রাস করার জন্য ডিজাইন এবং কোড পরিদর্শন" (ফাগান 1976)

  2. সফ্টওয়্যার ত্রুটি অপসারণ (ডান 1984)

  3. "হিউজ এয়ারক্রাফ্ট এ সফ্টওয়্যার প্রক্রিয়া উন্নতি" (হামফ্রে, স্নাইডার এবং উইলিস 1991)

এবং আরও বেশ কিছু


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

সেটা সত্য. আমাদের ধরে নিতে হবে একটি নির্দিষ্ট পয়েন্ট অবধি, প্রয়োজনীয়তার উপর ছুটে যাওয়া না হওয়া মানে প্রয়োজনীয়তাগুলির মধ্যে কম ত্রুটি রয়েছে, তবে এটি খুব বেশি প্রসারিত বলে মনে হয় না।
জো

10

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

গ্লাস আইন: প্রয়োজনীয়তার ঘাটতিগুলি প্রকল্প ব্যর্থতার মূল উত্স।

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

এটি পরামর্শ দেয় যে প্রয়োজনীয়তার গুণমান এবং প্রকল্পের ফলাফলের মধ্যে একটি সম্পর্ক রয়েছে।

বোহেমের প্রথম আইন: ত্রুটিগুলি প্রয়োজনীয়তা এবং নকশা সংক্রান্ত ক্রিয়াকলাপগুলির মধ্যে সর্বাধিক ঘন ঘন হয় এবং পরে সেগুলি অপসারণ করা আরও ব্যয়বহুল।

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

বোহেমের দ্বিতীয় আইন: প্রোটোটাইপিং বিশেষত ব্যবহারকারীর ইন্টারফেসের জন্য প্রয়োজনীয়তা এবং নকশার ত্রুটিগুলি হ্রাস করে।

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

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

এই আইনগুলির জন্য উল্লেখগুলি হল:

গ্লাস আইন: গ্লাস, আরএল: সফটওয়্যার পালাতে। ম্যাসিভ সফটওয়্যার প্রকল্পের ব্যর্থতা থেকে শিক্ষা নেওয়া পাঠ। আপার স্যাডল রিভার, এনজে: প্রেন্টাইস হল 1998

বোহেমের প্রথম আইন: বোহেম, বিডাব্লু, ম্যাকক্লেইন, আরকে, উরফ্রিগ, ডিবি: বৃহত্তর স্কেল নির্ভরযোগ্য সফ্টওয়্যার ডিজাইনের স্বয়ংক্রিয় সহায়তা সম্পর্কিত কিছু অভিজ্ঞতা। আইইইই ট্রান্স অন সফটওয়্যার ইঞ্জিনিয়ারিং 1, 1 (1975), 125–133

বোহেমের দ্বিতীয় আইন: বোহেম, বিডাব্লু, গ্রে, টিই, সিওয়াল্ডট, টি .: প্রোটোটাইপ ভার্সেস নির্দিষ্টকরণ: একটি মাল্টিপ্রজেক্ট এক্সপেরিমেন্ট। আইইইই ট্রান্স অন সফটওয়্যার ইঞ্জিনিয়ারিং 10, 3 (1984), 290–302

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

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.