সফ্টওয়্যার পরীক্ষার পদ্ধতিটি কি ত্রুটিযুক্ত ডেটার উপর নির্ভর করে?

Question

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

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

এটিকে সংশোধন বা খণ্ডন করার জন্য কোনও স্বাধীন ডেটা নেই?

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

Comments

এটি যৌক্তিক মনে হয়, কারণ বেশিরভাগ ক্ষেত্রে বাগটি আবিষ্কারের পরে ডেটা দুর্নীতিও জড়িত। আরও বেশি, দুর্নীতিগ্রস্ত ডেটা থাকার কারণে ব্যবসায়গুলি অনেক বেশি ব্যয় করে যদি এটি পরে বাগটি ঠিক করার প্রক্রিয়াতে আবিষ্কার হয়।

— ই এল ইউসুবভ

@ এল ইউসুবুভ এটি সত্যই করে। কিন্তু সাধারণ জ্ঞান খুব বিভ্রান্তিকর হতে পারে । আমাদের মন সহজেই আপাত যুক্তি দ্বারা চালিত হয় যখন এটি অন্যভাবে হয়। এজন্য প্রমাণ-ভিত্তিক সফ্টওয়্যার ইঞ্জিনিয়ারিং এত গুরুত্বপূর্ণ।

— কনরাড রুডলফ

সম্পর্কিত: প্রোগ্রামার্স.স্ট্যাকেক্সেঞ্জারএইউ / কি

— 133824/41381

রেকর্ডটির জন্য (এবং আমার উত্তরে উল্লিখিত), আমি এর প্রথম দিকের উল্লেখটি কোড সম্পূর্ণ করার আগে ভালভাবে খুঁজে পেতে সক্ষম হয়েছি। 1976 সালে ফাগান এবং স্টিফেনসনের কাজ (স্বতন্ত্রভাবে) এর সর্বাধিক উল্লেখ যা আমি এটি পাই find কোড কমপ্লিটের প্রথম সংস্করণটি প্রায় 20 বছর পরে 1993 সাল পর্যন্ত প্রকাশিত হয়নি। আমি প্রত্যাশা করব যে 1980 এর দশকে ব্যারি বোহমের কাজ এই ধারণার জনপ্রিয়তা বাড়িয়েছে - বোহমের কাজটি 1980 এর দশকে এবং এমনকি 2000 এর দশকের শেষের দিকে সফ্টওয়্যার ইঞ্জিনিয়ারিং প্রক্রিয়াতে খুব প্রভাবশালী ছিল।

— থমাসের মালিক

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

— ড্যানিয়েল আর হিকস

Answer 1

সফ্টওয়্যার পরীক্ষার পদ্ধতিটি কি ত্রুটিযুক্ত ডেটার উপর নির্ভর করে?

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

এটিকে সংশোধন বা খণ্ডন করার জন্য কোনও স্বাধীন ডেটা নেই?

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

সুতরাং, ধরে নিই যে এই সংখ্যাগুলি ন্যায্য করতে আমাদের এখনও সমস্যা আছে:

এই সফ্টওয়্যার বিকাশের পদ্ধতি কীভাবে প্রভাব ফেলবে?

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

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

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

Comments

প্রমাণ-ভিত্তিক ইঞ্জিনিয়ারিং সম্পর্কে অসাধারণ মেটা-উত্তর। ধন্যবাদ।

— কনরাড রুডলফ

জঘন্য, আমি ঠিক বুঝতে পেরেছিলাম যে এটি সরাসরি ঘোড়ার মুখ থেকে আসছে। হে হে। অসাধারণ.

— কনরাড রুডলফ

আমি অনুভূতিটি পেয়েছি যে প্রত্যেকে "ত্রুটিযুক্ত ডেটা" "সম্পূর্ণ অসত্য, বিপরীত সত্য" হিসাবে ব্যবহারের ব্যাখ্যা দিচ্ছে, তবে আমি অনুভূতি পেয়েছি যে আপনার অবস্থানটি এটি অসত্য হতে পারে তা উল্লেখ করার জন্যই । এটা কি সঠিক?

— ড্যানিয়েল বি

পছন্দ করুন আমাকে সত্য প্রমাণ দিন যে এটি আসলে ভুল এবং আমি আমার মতামত পরিবর্তন করতে পারি; ততক্ষণ আমি কেবল জানি যে এটি প্রদর্শনযোগ্যভাবে সঠিক নয়।

@ গ্রাহামলি আমি আপনার বক্তব্যটি দেখতে পাচ্ছি (কেবলমাত্র মনে করুন যে শব্দবন্ধটি কিছুটা অযৌক্তিকভাবে আক্রমণাত্মক হতে পারে)। কৌতূহলবশত, আমি এখানে ফাগান কাগজটি পেয়েছি এবং এটি বলে ... "... পুনরায় কাজ করার অনুমতি দেয় ... তাদের উত্সার কাছাকাছি ... প্রক্রিয়াটির শেষার্ধে করা হয় যদি তার চেয়ে 10 থেকে 100 গুণ কম ব্যয় হয়"। যদিও আমি এই পাঠ্যের কাছে কোনও উদ্ধৃতি দেখতে পাচ্ছি না।

— ড্যানিয়েল বি

Answer 2

আমার অংশ হিসাবে, "এই সফ্টওয়্যার বিকাশের পদ্ধতিটি কীভাবে প্রভাবিত করে" এর উত্তর "খুব বেশি নয়"।

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

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

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

Comments

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

— কर्क ব্রডহર્স্ট

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

— পিট কিরখাম

Answer 3

আমি এই বিষয়টিকে উপস্থাপন করতে যাচ্ছি যে আমি যা সন্ধান করছি তার বেশিরভাগই 1970 এর দশক এবং 1980 এর দশকের শুরু থেকেই আসে। এই সময়ে, ক্রমবর্ধমান প্রক্রিয়া মডেলগুলি পুনরাবৃত্ত এবং / বা বর্ধমান পদ্ধতির (সর্পিল মডেল বা চতুর পদ্ধতি) এর চেয়ে অনেক বেশি সাধারণ ছিল। এই কাজের বেশিরভাগটি এই সিক্যুয়াল মডেলগুলিতে নির্মিত। যাইহোক, আমি মনে করি না যে সম্পর্কটি ধ্বংস করে দেয়, তবে পুনরুক্তি / বর্ধনশীল পদ্ধতির একটি সুবিধা হ'ল বৈশিষ্ট্যগুলি (একটি অ্যাপ্লিকেশনটির সম্পূর্ণ উল্লম্ব টুকরো) মুক্তি এবং নির্ভরতা ইনজেকশনের আগে এবং প্রতিটি পর্বের জটিলতার আগে এতে সমস্যাগুলি সংশোধন করা যথোপযুক্ত সৃষ্টিকর্তা.

---

আমি শুধু আমার কপি টেনে বের সফটওয়্যার ইঞ্জিনিয়ারিং অর্থনীতি এবং অধ্যায় 4. মধ্যে এই চার্ট তিনি উল্লেখ "ডিজাইন এবং কোড পরিদর্শন কর্মসূচী উন্নয়ন ত্রুটি কমাতে করতে" আমার Fagan (দ্বারা পিছনে ডেটা একটি রেফারেন্স পাওয়া আইইইই , UMD থেকে PDF ) প্রিন্সিপাল, EB ডালির "ম্যানেজমেন্ট অফ সফটওয়্যার ইঞ্জিনিয়ারিং", ডব্লিউই স্টিফেনসনের "সেফগার্ড সিস্টেম সফটওয়্যার ডেভেলপমেন্টে ব্যবহৃত সম্পদগুলির একটি বিশ্লেষণ" ( এসিএম ), এবং "বেশ কয়েকটি টিআরডাব্লু প্রকল্প"।

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

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

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

সফটওয়্যার ইঞ্জিনিয়ারিং অর্থনীতিতে বোহেমের ভিত্তিতে কোড কমপ্লিটের টেবিলটি বরং ফুলে যায় (রেঞ্জগুলির নিম্ন প্রান্তটি প্রায়শই খুব বেশি থাকে)। পর্বের মধ্যে যে কোনও পরিবর্তন আনতে ব্যয় করতে হবে প্রকৃতপক্ষে ১. সফ্টওয়্যার ইঞ্জিনিয়ারিং অর্থনীতিতে চিত্র 4-2 থেকে এক্সট্র্যাপোলেটিংয়ের প্রয়োজনে আর্কিটেকচারে 1.5-2.5 গুণ, কোডিংয়ের 2.5-10-10, পরীক্ষায় 4-20, এবং 4- হওয়া উচিত রক্ষণাবেক্ষণে 100 পরিমাণটি প্রকল্পের আকার এবং জটিলতার পাশাপাশি ব্যবহৃত প্রক্রিয়াটির আনুষ্ঠানিকতার উপর নির্ভর করে।

---

ব্যারি বোহেমের অ্যাপেনডিক্স ই এবং রিচার্ড টার্নারের ব্যালেন্সিং এগ্রিলিটি এবং ডিসিপ্লিনে পরিবর্তনের ব্যয় সম্পর্কিত অভিজ্ঞতাগত গবেষণার উপর একটি ছোট্ট অংশ রয়েছে।

উদ্বোধনী অনুচ্ছেদগুলিতে বেন্টকে উদ্ধৃত করে কেন্ট বেকের চরম প্রোগ্রামিংয়ের ব্যাখ্যা দেওয়া হয়েছে। এটি বলে যে সময়ের সাথে সাথে পরিবর্তনের ব্যয়টি ধীরে ধীরে বেড়ে গেলে সিদ্ধান্তগুলি যতটা সম্ভব দেরী করা হত এবং কেবল যা প্রয়োজন তা কার্যকর করা হত। এটি "ফ্ল্যাট কার্ভ" হিসাবে পরিচিত এবং এটি চরম প্রোগ্রামিং চালায়। তবে পূর্ববর্তী সাহিত্যে যা পাওয়া গেছে তা হ'ল "খাড়া বাঁকা", ছোট সিস্টেমগুলির সাথে (<5 কেএসএলসিপি) পরিবর্তন হয়েছে 5: 1 এবং বৃহত সিস্টেমে 100: 1 পরিবর্তন হয়েছে of

বিভাগটি মেরিল্যান্ডের ইউনিভার্সিটির সেন্টার ফর এম্পিরিকালি বেসড সফটওয়্যার ইঞ্জিনিয়ারিংয়ের (জাতীয় বিজ্ঞান ফাউন্ডেশন দ্বারা স্পনসরিত) উদ্ধৃত করেছে। তারা উপলভ্য সাহিত্যের অনুসন্ধান চালিয়েছে এবং দেখা গেছে যে ফলাফলগুলি 100: 1 অনুপাতের নিশ্চয়তা দেয়, কিছু ফলাফল 70: 1 থেকে 125: 1 এর পরিসীমা নির্দেশ করে। দুর্ভাগ্যক্রমে, এগুলি সাধারণত "বিগ ডিজাইন আপ ফ্রন্ট" প্রকল্প এবং ক্রমানুসারে পরিচালিত হয়েছিল।

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

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

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

---

সফটওয়্যার কোয়ালিটি ইঞ্জিনিয়ারিংয়ের স্টিফেন কানের মেট্রিক্স এবং মডেলগুলির ধাপের ত্রুটি অপসারণের কার্যকর কার্যকারিতা সম্পর্কে অধ্যায় 6 এর একটি বিভাগ রয়েছে।

তিনি ফাগানের ১৯ 1976 এর কাগজ (সফটওয়্যার ইঞ্জিনিয়ারিং অর্থনীতিতেও উদ্ধৃত) উদ্ধৃত করে বলেছিলেন যে উচ্চ স্তরের নকশা (সিস্টেম আর্কিটেকচার), নিম্ন-স্তরের নকশা (বিস্তারিত নকশা) এবং পুনর্নির্মাণ 10 থেকে 100 গুণ কম ব্যয়বহুল হতে পারে উপাদান এবং সিস্টেম স্তর পরীক্ষার সময় কাজ চেয়ে।

তিনি 1982 এবং 1984 সালে দুটি ফ্রিডম্যান এবং ওয়েইনবার্গের দুটি প্রকাশনার উদ্ধৃতি দিয়েছিলেন যাতে বড় ব্যবস্থাগুলি নিয়ে আলোচনা হয়। প্রথমটি হ'ল হ্যান্ডবুক অফ ওয়াকথ্রুজস, ইন্সপেকশনস এবং টেকনিক্যাল রিভিউগুলি এবং দ্বিতীয়টি হ'ল "রিভিউ, ওয়াকথ্রু এবং পরিদর্শন"। বিকাশের চক্রের প্রথম দিকে পর্যালোচনা প্রয়োগের ফলে 10 টি ফ্যাক্টর দ্বারা পরীক্ষার পর্যায়ে পৌঁছে যাওয়া ত্রুটির সংখ্যা হ্রাস করতে পারে ত্রুটিগুলির সংখ্যা হ্রাস এই পরীক্ষার ব্যয়কে 50% থেকে 80% হ্রাস করে। আমাকে আরও বিশদে পড়াশোনা পড়তে হবে, তবে মনে হয় যে ব্যয়টির মধ্যে ত্রুটিগুলি সন্ধান করা এবং ফিক্স করাও অন্তর্ভুক্ত।

"পরিদর্শন / পর্যালোচনার দৃষ্টিতে ইন্টিগ্রেটেড সফ্টওয়্যার বৈধকরণ" রেমাসের 1983 সালের একটি গবেষণা, ক্যালিফোর্নিয়ায় আইবিএম-এর সান্তা টেরেসা ল্যাবরেটরির ডেটা ব্যবহার করে বিভিন্ন পর্যায়ে ত্রুটিগুলি বিশেষত নকশা / কোড পরিদর্শন, পরীক্ষার, এবং রক্ষণাবেক্ষণের ব্যয় নিয়ে গবেষণা করেছে। উদ্ধৃত ফলাফলগুলি 1:20:82 এর ব্যয় অনুপাত নির্দেশ করে। অর্থাত, নকশা বা কোড পরিদর্শনগুলিতে পাওয়া একটি ত্রুটির দাম 1 থেকে পরিবর্তন হতে পারে the যদি একই ত্রুটি পরীক্ষায় পালিয়ে যায় তবে এটির জন্য 20 গুণ বেশি ব্যয় হবে। যদি এটি কোনও ব্যবহারকারীর কাছে পুরোপুরি পালিয়ে যায়, তবে এটি ব্যয় থেকে সঠিক পর্যন্ত 82-এর মধ্যে একাধিক হবে Kan আইবিএম এর রচেস্টার, মিনেসোটা সুবিধা থেকে প্রাপ্ত নমুনা তথ্য ব্যবহার করে কান, AS / 400 প্রকল্পের ত্রুটি অপসারণ ব্যয়ের অনুরূপ বলে মনে করেছিল 1:13:92 এ। তবে, তিনি উল্লেখ করেছেন যে কোনও ত্রুটি খুঁজে পেতে অসুবিধা বাড়ার কারণে ব্যয় বৃদ্ধি হতে পারে।

গিল্বের 1993 ( "সফটওয়্যার ইন্সপেকশন" ) এবং 1999 ("অনুকূলিতকরণ সফ্টওয়্যার ইঞ্জিনিয়ারিং স্পেসিফিকেশন এবং কোয়ালিটি কন্ট্রোল প্রসেসগুলি") সফ্টওয়্যার পরিদর্শন সম্পর্কিত প্রকাশনাগুলিতে অন্যান্য গবেষণাগুলিকে সংশোধন করার জন্য উল্লেখ করা হয়েছে।

---

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

---

আমি সম্প্রতি লোন স্টার রুবি সম্মেলনে গ্লেন ভ্যান্ডারবার্গের দেওয়া রিয়েল সফটওয়্যার ইঞ্জিনিয়ারিংয়ের একটি বক্তব্য শুনেছি । ২০১১ সালে স্কটিশ রুবি সম্মেলন এবং এরুবাইকন , ২০১২ সালে কিউন সান ফ্রান্সিসকো এবং ও'রিলি সফটওয়্যার আর্কিটেকচার কনফারেন্সে তিনি একই বক্তব্য দিয়েছেন। 2015 সালে । আমি কেবল লোন স্টার রুবি সম্মেলন শুনেছি, তবে তাঁর ধারণাগুলি পরিমার্জিত হওয়ার সাথে সাথে সময়ের সাথে আলাপটি বিকশিত হয়েছে।

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

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

Comments

@AndresF। এই উদ্ধৃতিগুলি সনাক্ত করতে আমি যে সমস্যার মুখোমুখি হয়েছি সেগুলির মধ্যে একটি হ'ল বোসাভিট আপনার লিঙ্কিত বইটিতে "একটি খড়ের কাঁধের সূঁচ" সমস্যা হিসাবে বর্ণনা করেছেন। বইয়ের উদ্ধৃতি দারুণ আপত্তি - যদিও আপনি যখন উদ্ধৃতিটি পড়তে যান তখনও এটি মুদ্রণযোগ্য, আপনি উদ্ধৃত লেখকের দাবির পিছনে থাকা ছোট্ট নাগেটটি সন্ধান করতে কয়েকশ পৃষ্ঠা পেয়েছেন।

Answer 4

এটি কেবল সাধারণ যুক্তি।

বিশেষায় ত্রুটি সনাক্ত করা হয়েছে।

Case : Error found while reviewing UseCase/Function spec.
Actions:
        Rewrite paragraph in error.

Case : Error found during unit test.
Actions:
        Fix code.
        (Possibly) rewrite paragraph in spec.
        rerun unit test.

Case : Error found in integration test.
        Fix code.
        (possibly) rewrite paragraph in spec.
        rerun unit test.
        build new release.
        rerun integration test for whole system.

Case : Error found in UAT
        Fix code.
        (possibly) rewrite paragraph in spec.
        rerun unit test.
        build new release.
        rerun integration test for whole system.
        deploy release to UAT.
        rerun UAT tests.


Case : Error found in production
        Fix code.
        (possibly) rewrite paragraph in spec.
        rerun unit test.
        Build release.
        rerun integration test for whole system.
        deploy release to UAT.
        rerun UAT tests.
        deploy release to production.

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

উত্পাদনের সফ্টওয়্যারটিতে ত্রুটির কারণে কোনও ব্যবসায়ের যে পরিমাণ ব্যয় হতে পারে সেগুলি ছাড়াই (হ্রাস বিক্রয়, অর্ডার দেওয়া, গ্রাহকদের হ্যাক করা ইত্যাদি)

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

Comments

এটি কেবলমাত্র একটি কেস কভার করে: বিশেষায় ত্রুটি সনাক্ত করা হয়েছে, অর্থাত প্রথমদিকে প্রবর্তিত একটি ত্রুটি। কিন্তু ত্রুটি (পোস্ট-স্থাপনার বাগ ফিক্সিং সহ) এবং ফিক্সিং বিকাশের সকল পর্যায়ে চালু করা যেতে পারে সেই ত্রুটির কারণে তারা সম্ভবত সিস্টেমের একটি ছোট অংশ প্রভাবিত করবে যথেষ্ট সহজ হবে।

— কনরাড রুডলফ

তবে সমস্যাটি হ'ল বাগ ফিক্সগুলি অপ্রত্যাশিত পার্শ্ব প্রতিক্রিয়াগুলি হতে পারে, সুতরাং আপনি যদি নিশ্চিতভাবে গ্যারান্টি দিতে না পারেন তবে আপনি কেবলমাত্র এসআইটি ইউএটি ইত্যাদি পুনরায় করাতে আটকে থাকা উপাদানগুলির একটি নির্দিষ্ট উপ সেটকেই প্রভাবিত করবেন Also পরিবর্তন.

— জেমস অ্যান্ডারসন

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

— কনরাড রুডলফ

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

— টমাসের মালিক

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

— কনরাড রুডলফ

Answer 5

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

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

দ্রুত অনুসন্ধান থেকে কিছু প্রাসঙ্গিক কাগজপত্র (সম্পূর্ণ কাগজপত্র পড়ুন, আরও গবেষণা করুন এবং নিজের মতামত তৈরি করুন):

সফ্টওয়্যার মানের মূল্য গবেষণা (2011) এর একটি পদ্ধতিগত সাহিত্য পর্যালোচনা

"যদিও এই সম্প্রদায়টি গবেষণা ডোমেনের কাঠামোর বিষয়ে যথাযথ বোঝার বিকাশ করেছে, অভিজ্ঞতাগত বৈধতার প্রায়শই ঘাটতি থাকে। বিশ্লেষণ করা নিবন্ধগুলির প্রায় এক তৃতীয়াংশ একটি কেস স্টাডি বা আরও বিস্তৃত অভিজ্ঞতামূলক ফলাফল উপস্থাপন করে software এটি সফ্টওয়্যার মানের ব্যয় গবেষণার জন্য অপর্যাপ্ত বলে মনে হয় appears , যা নতুন অনুসন্ধান উত্পন্ন করার জন্য পরিমাণগত ডেটার উপর দৃ strongly়ভাবে নির্ভর করে thus সুতরাং মানসম্মত ব্যয়ের তথ্য সংগ্রহের জন্য উপন্যাসের পদ্ধতির পাশাপাশি এই জাতীয় ডেটা উপলভ্য করার জন্য শিল্প এবং গবেষণার মধ্যে আরও দৃ cooperation় সহযোগিতা প্রয়োজন। "

সফ্টওয়্যার মানের মূল্য নির্ধারণ (1998)

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

সফ্টওয়্যার ত্রুটির ব্যয় আচরণ (2004)

বিমূর্ত ... "বর্তমান গবেষণাটি আমাদের জ্ঞানকে যেভাবে ত্রুটিগুলি সংশোধন করে এবং তাদের সংশোধন করার ব্যয় (বা বিকল্পভাবে, তাদের অকার্যকর করে ফেলেছে) সফ্টওয়্যারটির চূড়ান্ত ব্যয়কে প্রভাবিত করে তার আপডেট করার চেষ্টা করে" ... "অপরিবর্তিত ত্রুটিগুলি তাত্পর্যপূর্ণভাবে আরও ব্যয়বহুল হয়ে ওঠে প্রতিটি পর্যায়ে যাতে তারা অমীমাংসিত হয় "

পরীক্ষার কভারেজ এবং যাচাই-পরবর্তী ত্রুটি: একাধিক কেস স্টাডি (২০০৯)

"আমরা আরও দেখতে পেলাম যে পরীক্ষার প্রচেষ্টা টেস্ট কভারেজের সাথে তাত্পর্যপূর্ণভাবে বৃদ্ধি পায়, তবে ক্ষেত্রের সমস্যার হ্রাস পরীক্ষা কভারেজের সাথে ধারাবাহিকভাবে বৃদ্ধি পায়। এটি সুপারিশ করে যে বেশিরভাগ প্রকল্পের ক্ষেত্রে কভারেজের সর্বোত্তম স্তরটি সম্ভবত 100% এর চেয়ে কম হবে।"

সফ্টওয়্যার টেস্ট প্রক্রিয়া এবং ব্যবসায়িক মানের মধ্যে গ্যাপটি ব্রিজ করুন: কেস স্টাডি (২০০৯)

Answer 6

আমি আপনার প্রশ্নের প্রথম অংশটির উত্তর দিতে পারছি না, কারণ আমি কেবল চেক করে নিই। তবে আমি আপনার দ্বিতীয় প্রশ্নের একটি উত্তর তৈরি করতে পারি এবং সম্ভবত প্রথমটির একটি উত্তরের ইঙ্গিত দিতে পারি।

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

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

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

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

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

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

Comments

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

— মিহাই ড্যানিলা

Answer 7

আর একটি উত্তর! এবার শিরোনাম প্রশ্নে সম্বোধন করার জন্য "সফ্টওয়্যার মুর্তটোডোলজি কি ত্রুটিযুক্ত ডেটার উপর নির্ভর করে"।

আসল উত্তরটি "কোনও ডেটা নেই"। সফ্টওয়্যার প্রকল্পগুলিতে ডেটাগুলির কোনও বৃহত নির্ভরযোগ্য সংস্থা নেই কারণ সেখানে ত্রুটি, বাজারে সময় সাফল্য ইত্যাদি etc.

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

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

সফ্টওয়্যার প্রকল্পগুলির ব্যয় এবং সাফল্যের উপর সংখ্যা প্রকাশ করে এমন একমাত্র সংস্থা হ'ল
সরকারী বিভাগ এবং কেবলমাত্র তাদের কারণগুলি এবং হ্যাঁ এই সংখ্যাগুলি তারা যতটা পরিসংখ্যান ম্যাসেজ করে না কেন গভীর বিব্রতকর।

সুতরাং উপসংহারে সমস্ত সফ্টওয়্যার অধ্যয়ন অগত্যা বিশুদ্ধভাবে বিষয়ভিত্তিক কারণ কোনও উদ্দেশ্য উপসংহারের ভিত্তিতে কোন বাস্তব তথ্য নেই।

Comments

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

— কনরাড রুডলফ

@ কনরাড - "ত্রুটি গণনা" এর মতো মৌলিক এবং সাধারণ কিছু নিন, কিছু দোকান ইউনিট পরীক্ষার ব্যর্থতা গণনা করে, কিছু দোকানগুলি ইউএটি অবধি ত্রুটিগুলি ট্র্যাক করা শুরু করে না, কিছু দোকানে কেবল কোডটিতে ত্রুটিগুলি ট্র্যাক করে, কিছু দোকানে ডকুমেন্টেশন, কনফিগারেশন এবং অন্তর্ভুক্ত থাকে তাদের ত্রুটিযুক্ত ট্র্যাকিং প্রক্রিয়াতে স্থাপনার স্ক্রিপ্টগুলি। ভুল ব্যাকগ্রাউন্ডের রঙটি একটি ত্রুটি হিসাবে গণনা করে? কিছু প্রকল্প এটির ত্রুটি হিসাবে ট্র্যাক করবে অন্যরা এটিকে উপেক্ষা করবে।

— জেমস অ্যান্ডারসন

এগুলি সমস্ত প্যারোচিয়াল - অর্থাত্ সমাধানযোগ্য - সমস্যা। তারা যা সম্ভব তা নিয়ে মৌলিক প্রতিবন্ধকতা রাখে না, তারা কেবল এমন সমস্যাগুলি যুক্ত করে যার সমাধানের প্রয়োজন।

— কনরাড রুডলফ