একটি সফ্টওয়্যার বিকাশ ধারণা বা কৌশল যে একটি ব্যর্থতা ছিল একটি ভাল উদাহরণ কি?

Question

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

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

Comments

এক্সএক্সএক্সএক্সএক্সএক্সএক্সএক্সএক্সএক্সএক্সএক্সএক্সএক্সএক্সএক্সআরইইইইইইইইইইইইএমইইইইএমইইইএমইই প্রোগ্রামিং ...

— ক্রাসিক

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

— মাইকেল বর্গওয়ার্ট

কর্বা কোনও ব্যর্থতা নয় .. এটি এখনও ব্যবহারের মধ্যে রয়েছে

— ওনোন

@ ওনোন, এটি এই অর্থে ব্যর্থতা যে এটি সাধারণভাবে আন্তঃঅযোগিতা সমস্যা সমাধানের মূল প্রতিশ্রুতি দেয় নি, এবং এটি এখন একটি কুলুঙ্গি প্রযুক্তি।

— প্যাটার টারিক

এইচটিটিপি জেএসএন ওয়েবসার্ভিসগুলি দিয়ে সমস্যার সমাধান করেছে তবে সফ্টওয়্যারগুলির অন্যান্য ক্ষেত্রের সাথে নয়!

— শরৎ

Answer 1

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

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

শেষ পর্যন্ত, এইচটিটিপি + জেএসএন জনগণের জন্য সমস্যার সমাধান করে

কমপক্ষে এমন এক ব্যক্তির জন্য যিনি দু'একটি একই রকমের "চূড়ান্ত সমাধান" উত্থান এবং শেষ পর্যন্ত পড়ে দেখেন নি ... মনে রাখা ভাল যে এর সময়ে কর্বা সম্পর্কে একই রকম অনুভূতি ছিল ;-)

আমি মনে করি এটি কর্বার উত্থান ও পতনের উদ্ধৃতিটি উত্সাহিত করেছে :

কর্বার ইতিহাস এমন একটি যা কম্পিউটিং শিল্প বহুবার দেখেছিল এবং সম্ভবত মনে হয় যে বর্তমান মিডলওয়্যার প্রচেষ্টা, বিশেষত ওয়েব পরিষেবাদি একটি অনুরূপ ইতিহাসকে পুনরায় প্রকাশ করবে। [...]

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

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

---

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

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

Comments

এই লিঙ্কটির মাধ্যমে পড়া: প্রিয় godশ্বর, কর্বা অবশ্যই ভীষণ ভয়ঙ্কর হয়ে উঠেছে যদি ভি 1 ইজেবিগুলি এগুলি সহজতর বলে উপস্থাপন করে ...

— মাইকেল বার্গওয়ার্ট

মিচি হেনিং পণ্যটি বিকাশ করে চলেছে CORBA এর প্রচুর ঘাটতি পূরণ করে।

— ব্লারফ্লায়

Answer 2

মানুষের ঘন ঘন ভুল হয়ে যাওয়ার উদাহরণ হ'ল জলপ্রপাতের মডেল। এই বাঁধা জলপ্রপাত মডেল, যা দেখা একটি ডায়াগ্রাম হয় উইনস্টন রয়েস এর কাগজ "লার্জ সফটওয়ার সিস্টেমস উন্নয়ন ম্যানেজিং" ।

এই চিত্রটি এই পাঠ্য অনুসরণ করে:

আমি এই ধারণায় বিশ্বাস করি, তবে উপরে বর্ণিত বাস্তবায়ন ঝুঁকিপূর্ণ এবং ব্যর্থতার আমন্ত্রণ জানিয়েছে ... উন্নয়ন চক্রের শেষে টেস্টিং পর্বটিই প্রথম ইভেন্ট যার জন্য সময়, সঞ্চয়, ইনপুট / আউটপুট, স্থানান্তর ইত্যাদি, বিশ্লেষণ থেকে পৃথক হিসাবে অভিজ্ঞতা। এই ঘটনাগুলি বিশ্লেষণযোগ্য নয়। উদাহরণস্বরূপ তারা গাণিতিক পদার্থবিজ্ঞানের মানক আংশিক ডিফারেনশিয়াল সমীকরণের সমাধান নয়। তবুও যদি এই ঘটনাগুলি বিভিন্ন বাহ্যিক প্রতিবন্ধকতাগুলি পূরণ করতে ব্যর্থ হয়, তবে অদৃশ্য একটি বড় নতুন নকশার প্রয়োজন es একটি সাধারণ অষ্টাল প্যাচ বা কিছু বিচ্ছিন্ন কোডের পুনরায় করা এই ধরণের অসুবিধা সমাধান করবে না। প্রয়োজনীয় নকশা পরিবর্তনগুলি এত বিঘ্নিত হতে পারে যে সফ্টওয়্যার প্রয়োজনীয়তার উপর যার নকশাটি ভিত্তিক এবং যা প্রতিটি কিছুর জন্য যৌক্তিকতা লঙ্ঘন করে। হয় প্রয়োজনীয়তাগুলি সংশোধন করতে হবে, বা ডিজাইনে যথেষ্ট পরিবর্তন প্রয়োজন। কার্যত বিকাশ প্রক্রিয়াটি মূলদিকে ফিরে এসেছে এবং এক সময়সূচী এবং / অথবা ব্যয়ের ক্ষেত্রে 100 শতাংশ ওভাররন আশা করা যায়।

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

লোকেরা কেন প্রথম জলপ্রপাতের দিকে লেট করল, আমি জানি না। আমার ধারণা তারা ঝুঁকি নিয়ে নিতে এবং ব্যর্থতাকে আমন্ত্রণ জানায়।

Comments

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

— maple_shaft

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

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

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

— tdammers

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

— ম্যাপেল_শ্যাফট

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

— এসডাব্লু

Answer 3

একটি উচ্চ বিমূর্ত স্তর বা স্বয়ংক্রিয় প্রোগ্রামিং থেকে কোডের স্বয়ংক্রিয় জেনারেশন ।

উইকিপিডিয়া নিবন্ধটিতে কিছুটা historicalতিহাসিক তথ্যের অভাব রয়েছে, তবে প্রোগ্রামাররা কম্পিউটারের চেয়ে বেশি ব্যয়বহুল হয়ে উঠার পর থেকেই এটি পরিচালকদের স্বপ্ন ছিল dream

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

১৯৮০ এর সিএএসই-র সরঞ্জামগুলির সময় ক্রোধ ছিল। CASE এর অর্থ কম্পিউটার-সাহায্য প্রাপ্ত সফটওয়্যার ইঞ্জিনিয়ারিং। ধারণা করা হয়েছিল ইঞ্জিনিয়ারিং নীতিগুলির কঠোর প্রয়োগ সফ্টওয়্যার বিকাশকে দ্রুততর করবে। ব্যয় ব্যতীত এই সরঞ্জামগুলি ধরতে না পারার প্রধান কারণটি ছিল সরঞ্জামগুলি কার্যকরভাবে কাজ করার জন্য উচ্চ স্তরের ডেটা মানককরণের প্রয়োজনীয়তা।

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

আউটসোর্সিং প্রোগ্রামিংকে কম দামে প্রোগ্রামার ব্যয় হ্রাস করার কয়েকটি উপায়ের মধ্যে একটি। আউটসোর্সিংয়ের সমস্যাগুলির মধ্যে রয়েছে যোগাযোগের সমস্যা এবং স্পেসিফিকেশন সমস্যা।

Comments

এছাড়াও, এসকিউএল এবং ভিজ্যুয়াল বেসিক, উভয়ই নন-প্রোগ্রামারদের প্রোগ্রাম লেখার অনুমতি দেওয়ার জন্য বিজ্ঞাপন দেওয়া হয়েছিল।

— শান ম্যাকমিলান

Answer 4

আনুষ্ঠানিক পদ্ধতি

একসময় এটি প্রস্তাব করা হয়েছিল যে সফ্টওয়্যারটি সঠিক প্রমাণিত হতে পারে। (এই ধারণাটি হ'ল যে পরীক্ষাটি দেখাতে পারে না যে কোনও ত্রুটি নেই, তবে প্রমাণগুলি সক্ষম হবে)) দুর্ভাগ্যক্রমে, কোনও প্রোগ্রামের জন্য একটি প্রমাণ তৈরি করার ক্ষেত্রে কিছু বড় ত্রুটি রয়েছে:

• প্রোগ্রামটি লেখার চেয়ে এটি আরও কঠিন এবং সময়সাপেক্ষ।
• এটি পুরো প্রোগ্রামটি কভার করতে হবে যার অর্থ আপনার কোনও লাইব্রেরি, ওএস ইত্যাদির জন্য প্রমাণ প্রয়োজন ...
• এটি বাগগুলির অনুপস্থিতি প্রমাণ করে না, কারণ এই বাগগুলি দুর্ঘটনার কারণে হতে পারে।

এই ধারণাটি 70 এর দশকে খুব জনপ্রিয় ছিল।

লিংকেজ: http://en.wikedia.org/wiki/formal_methods http://c2.com/cgi/wiki?ProofOfCor درست ness http://c2.com/cgi/wiki? অনুশীলনকারীদের রেজিটাক্স ফর্মাল মেথডস

Comments

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

— টমাস ওয়েন্স

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

— শান ম্যাকমিলান

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

— টমাস ওয়েন্স