আনুষ্ঠানিক পদ্ধতিগুলি ব্যাপকভাবে গ্রহণে বাধা কী? [বন্ধ]

বন্ধ । এই প্রশ্নটি মতামত ভিত্তিক । এটি বর্তমানে উত্তর গ্রহণ করছে না।

এই প্রশ্নটি উন্নত করতে চান? প্রশ্নটি আপডেট করুন যাতে পোস্টটি সম্পাদনা করে সত্য এবং উদ্ধৃতি দিয়ে উত্তর দেওয়া যায় ।

2 বছর আগে বন্ধ ।

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

আমরা কেন এটি প্রতিদিনের প্রোগ্রামিং বা ওয়েব অ্যাপ্লিকেশন ইত্যাদির জন্য প্রায়শই ব্যবহার করি না ...?

তথ্যসূত্র:

development-process code-quality formal-methods

— Toto
সূত্র

আমরা মধ্যযুগীয় দুর্গগুলির মতো - 5 ফুট পুরু প্রাচীর সহ ঘর তৈরি করতে পারি। বেশিরভাগ সময়, এটি এর চেয়ে মূল্যবান হতে হবে।

— বাল্ড্রিক

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

— আমন

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

— ক্রিস্টোফ

@ টোটোটি প্রশ্নটি হ'ল: জিনিসগুলি সঠিকভাবে করা (চশমা অনুসারে কাজ করুন) বা সঠিক জিনিসগুলি করা (ভাল চশমা থাকা)। তত্ত্বের ভিত্তিতে অনুমানটি

— ক্রিস্টোফ

যারা হতাশ হয়ে পড়েছেন যে এটি বন্ধ হয়ে গেছে তাদের জন্য এখন দুর্দান্ত একটি ব্লগ পোস্ট রয়েছে: লোকেরা কেন সাধারণ পদ্ধতি ব্যবহার করেন না?

— icc97

উত্তর:

একজন ইঞ্জিনিয়ার হলেন এমন একজন ব্যক্তি যা ডলার দিয়ে কোনও ইডিয়ট 10 দিয়ে কী করতে পারে।

রিসোর্সের সীমাবদ্ধতা, বাজেটের সীমাবদ্ধতা, সময়ের সীমাবদ্ধতা এগুলি সব গুরুত্বপূর্ণ।

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

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

— জার্গ ডব্লু মিত্তাগ
সূত্র

আমি আরও যুক্ত করব যে প্রোগ্রামিং ভাষায় আনুষ্ঠানিক পদ্ধতিগুলি সক্রিয় গবেষণার একটি ক্ষেত্র যা বর্তমানে মূলধারার

— জে কে

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

— Toto

টিডিডি এবং বিডিডি হ'র যুক্তির নীতিতে নির্মিত প্রথা যা আনুষ্ঠানিক পদ্ধতির একটি ভিত্তি। তারা দক্ষতা উন্নতি এটি থেকে বিরত না।

— মার্টিন স্পামার

@ টোটো প্রুফগুলি সত্যই, সত্যই শক্ত। গণিতবিদগণ প্রমাণ হিসাবে মঞ্জুর করেছেন এমন অনেক কিছুই প্রোগ্রামগুলিতে প্রয়োগ হয় না। উদাহরণস্বরূপ, C ++, উপরন্তু না মিশুক হল: (-1 + 1) + INT_MAX = INT_MAX, -1 + (1 + INT_MAX)অনির্ধারিত আচরণ।

— হোভারকাচ

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

— জার্গ ডব্লু মিট্টাগ

প্রোগ্রাম করতে না প্রোগ্রাম করতে?

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

জিনিসগুলি সঠিকভাবে করা বা সঠিক জিনিসগুলি করা?

আনুষ্ঠানিক পদ্ধতির সাহায্যে আপনাকে একটি প্রমাণ দেয় যে আপনার সফ্টওয়্যার স্পেসিফিকেশন অনুযায়ী কাজ করে। সুতরাং আপনার পণ্য জিনিস সঠিকভাবে না। তবে এটি কি সঠিক কাজ করে?

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

আনুষ্ঠানিকতা ব্যয়

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

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

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

প্রস্তুতিতে

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

আপডেট: পরিমাপ প্রচেষ্টা

এসিএমের যোগাযোগের অক্টোবর 2018 ইস্যুতে প্রচেষ্টার কিছু অনুমান সহ বাস্তব বিশ্বে ফর্মালালি যাচাই করা সফ্টওয়্যার সম্পর্কে একটি আকর্ষণীয় নিবন্ধ রয়েছে ।

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

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

SEL4 ডিজাইন এবং কোড বিকাশ দুটি ব্যক্তি-বছর সময় নিয়েছে। বছরের পর বছর ধরে সমস্ত সেরোস্পেসিফিক প্রমাণ যুক্ত করা সি কোডের 8,700 লাইনের জন্য মোট 18 ব্যক্তি-বছর আসে। তুলনায়, এল 4 কেএ :: পিস্তাদিও, এল 4 পরিবারের আরেকটি মাইক্রোকার্নেল, আকারে তুলনীয়ভাবে এসএল 4, বিকাশে ছয় ব্যক্তি-বছর সময় নিয়েছে এবং কোনও উল্লেখযোগ্য স্তরের আশ্বাস দেয় না। এর অর্থ যাচাই করা সফ্টওয়্যার এবং traditionতিহ্যগতভাবে ইঞ্জিনিয়ারড সফ্টওয়্যার মধ্যে কেবলমাত্র 3.3 ফ্যাক্টর রয়েছে। কলবার্ট এবং বোহেমের অনুমান পদ্ধতি অনুসারে, 8 টি ,,০০০ লাইনের সি কোডের জন্য একটি traditionalতিহ্যবাহী প্রচলিত সাধারণ মাপদণ্ড EAL7 শংসাপত্রটি 45.9 ব্যক্তির-বয়সের বেশি সময় নিতে পারে। তার মানে আনুষ্ঠানিক বাইনারি-স্তরের বাস্তবায়ন যাচাইকরণ ইতিমধ্যে ২.৩ এর ফ্যাক্টরের চেয়ে বেশি সাধারণ মানদণ্ডের সর্বোচ্চ শংসাপত্র স্তরের চেয়ে কম ব্যয়বহুল এখনও উল্লেখযোগ্যভাবে দৃ stronger় নিশ্চয়তা প্রদান করে।

— ক্রিস্টোফ
সূত্র

চুক্তি ভিত্তিক প্রোগ্রামিং কমপক্ষে অনানুষ্ঠানিক প্রমাণ ব্যবহার করে।

— ফ্রাঙ্ক হিলেমান

@ ফ্র্যাঙ্কহিল্যান হ্যাঁ! এবং পূর্বশর্ত, পোস্টকন্ডিশন এবং আক্রমণকারীদের স্পষ্ট করার সহজ ঘটনাটি কোডকে দক্ষতার সাথে পর্যালোচনা করতে, ত্রুটিগুলি হ্রাস করতে এবং সিস্টেমেটাইজ টেস্টগুলিকে ব্যাপকভাবে সহায়তা করে।

— ক্রিস্টোফ

এটি এখন পর্যন্ত সেরা উত্তর হওয়া উচিত।

— হাশিম

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

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

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

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

— লুইস প্রিংল
সূত্র