আইটি শিল্প অন্যান্য শিল্পের মতো দ্রুত, ত্রুটিযুক্ত প্রকল্পগুলি কেন সরবরাহ করতে পারে না?

Question

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

উদাহরণস্বরূপ, এয়ারবাস এ 380 "19 ডিসেম্বর, 2000 এ আনুষ্ঠানিকভাবে চালু হয়েছিল" এবং "মার্চ মাসের প্রথম দিকে, 2005" বিমানটি ইতিমধ্যে পরীক্ষা করা হয়েছিল। বিশাল তেলের ট্যাঙ্কার, আকাশচুম্বী ইত্যাদি for

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

---

এয়ারবাস এ 380 এর মতো প্রকল্পগুলি উভয়ই উপস্থিত করে:

• অপ্রত্যাশিত বড় ঝুঁকি: যদিও এটি নির্মিত প্রথম বিমান নয়, এটি এখনও প্রযুক্তির সীমাবদ্ধতার দিকে ঠেলে দেয় এবং ছোট বিমানগুলির জন্য ভাল কাজ করে এমন জিনিসগুলি শারীরিক প্রতিবন্ধকতার কারণে বৃহত্তরটির পক্ষে কাজ করতে পারে না; একইভাবে, নতুন প্রযুক্তি ব্যবহৃত হয় যা এখনও ব্যবহৃত হয়নি, কারণ উদাহরণস্বরূপ বোয়িং 7৪ 74 করার সময় ১৯ 19৯ সালে সেগুলি পাওয়া যায় নি।

• সাধারণভাবে মানব সম্পদ এবং ব্যবস্থাপনার ঝুঁকিগুলি: প্রকল্পের মাঝামাঝি সময়ে ছেড়ে যাওয়া লোকেরা, কোনও ব্যক্তির কাছে পৌঁছাতে অক্ষম কারণ সে ছুটিতে থাকে, সাধারণ মানুষের ত্রুটি ইত্যাদি

এই ঝুঁকিগুলির সাথে, লোকেরা এখনও খুব অল্প সময়ের মধ্যে সেই বৃহত বিমানের মতো প্রকল্পগুলি অর্জন করে এবং বিতরণে বিলম্ব সত্ত্বেও, সেই প্রকল্পগুলি এখনও প্রচুর সফল এবং একটি উচ্চ মানের।

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

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

যেগুলি এখনও বিতরণ করা হয় তাদের প্রায়শই প্রচুর বাগ থাকতে পারে, যার জন্য ক্রমাগত পরিষেবা প্যাক এবং নিয়মিত আপডেটের প্রয়োজন হয় (মূল পণ্যটিতে বাগগুলি প্যাচ করতে এবং বিমানটি বিধ্বস্ত হওয়া থেকে রোধ করতে প্রতি এয়ারবাস A380 এ প্রতি সপ্তাহে দু'বার "আপডেট ইনস্টল করুন")।

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

Comments

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

— নলডোরিন

এমন কে খুঁজে পান যিনি আসলে those অন্যান্য শিল্পের কোনওটিতে কাজ করেন (তবে পিআর তে নয়) এবং তাদেরকে "বড় ত্রুটিযুক্ত প্রকল্পগুলি" সম্পর্কে জিজ্ঞাসা করুন। আমি কার্যত গ্যারান্টি দিতে পারি যে আপনি বেদনাদায়ক হাসি উপার্জন করবেন।

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

একটি সফ্টওয়্যার প্রকল্পের উপলব্ধি কয়েক সেকেন্ড বা মিনিট সময় নেয়; আপনি যখন আপনার আইডিইতে "সংকলন" ক্লিক করেন তখনই এটি ঘটে। অন্যদিকে প্রোগ্রামিং হ'ল ডিজাইন । A380 ডিজাইন করতে কত সময় লেগেছে?

— পিঁপড়া

সেই টিভি প্রোগ্রামটি একটি হাইপ। তারা কেবল সফল প্রকল্পগুলি প্রচার করে। যে কোনও চ্যানেল দর্শকদের দৃষ্টি আকর্ষণ করার জন্য প্রোগ্রাম তৈরি করবে।

— পান্ডু

'প্রতি এয়ারবাস A380 প্রতি সপ্তাহে দু'বার "আপডেট ইনস্টল করার" কল্পনা করুন ...' কল্পনা করুন শত্রু রোবটরা নিয়মিতভাবে বিমানটিকে দুর্বলতার জন্য তদন্ত করছে যখন প্রশিক্ষণপ্রাপ্ত পাইলটরা এলোমেলোভাবে বোতামগুলি চাপান। আমি বাজি ধরলাম আপনার নিয়মিত প্যাচ দরকার।

— নাথান লং

Answer 1

এড আপনারডনের ডেথ মার্চ এই মেটা টাইপ প্রশ্নের একটি সংখ্যা স্পর্শ করে।

সাধারণভাবে, সফ্টওয়্যার শিল্পে নিম্নলিখিতগুলির প্রচুর অভাব রয়েছে যা বড় প্রকল্পগুলির পথে আসে।

• মানককরণ এবং কাজের আইটেম ভাঙ্গন।

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

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

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

• "কখনও" একই জিনিস দু'বার তৈরি করা না। বিভিন্ন উপায়ে, একটি বিমান অন্য যে কোনও বিমানের মতো। এটি উইংস, ইঞ্জিন, আসন ইত্যাদি পেয়েছে Lar বড় সফ্টওয়্যার প্রকল্পগুলি খুব কমই নিজের পুনরাবৃত্তি করে। প্রতিটি ওএস কার্নেল উল্লেখযোগ্যভাবে পৃথক। ফাইল সিস্টেমে বৈষম্য দেখুন। এবং এই বিষয়টির জন্য, সেখানে কতগুলি সত্যই অনন্য ওএস রয়েছে? বড়গুলি এক পর্যায়ে একটি বেস আইটেমের ক্লোন হয়ে যায়। , AIX , সোলারিস , এইচপি-ইউএক্স ... হেরাল্ড ফিরে যেমন AT & T সিস্টেম ভী । উইন্ডোজের প্রতিটি পুনরাবৃত্তির মাধ্যমে অবিশ্বাস্য পরিমাণে এগিয়ে টানা এগিয়ে নেওয়া হয়েছিল। লিনাক্স ভেরিয়েন্টগুলি সাধারণত লিনাস যে একই কোরে শুরু হয়েছিল সেটিতে ফিরে যায়। আমি এটি এনেছি, কারণ বৈকল্পিকগুলি সত্যিকারের অনন্য, মালিকানাধীন ওএসগুলির চেয়ে দ্রুত প্রচার করতে ঝোঁক।

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

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

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

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

Comments

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

— আর্সেনী মোরজেনকো

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

— স্পেন্সার রথবুন

খুব ভাল উত্তর। একটি আকর্ষণীয় উদাহরণ হিসাবে - কল্পনা করুন যে কোনও প্রক্রিয়া বা সংস্থার ইতিহাস ছাড়াই একটি বিশাল গোছা লোকেরা বিশাল প্লেনটি ডিজাইন ও প্রয়োগ করেছে - এমন লোকেরা যারা সবেমাত্র একত্রিত হয়ে স্ক্র্যাচ থেকে of৪7 স্কেলে একটি বিমান তৈরির জন্য একটি ব্যবসা প্রতিষ্ঠা করেছিল। আমি যে 90% সফ্টওয়্যার প্রকল্প দেখেছি তা সম্পন্ন হয়েছে। অন্যান্য 10% অভিজ্ঞ স্থপতি এবং ইতিহাস এবং প্রক্রিয়াযুক্ত সংস্থাগুলি অনেক বেশি সফল বলে মনে হচ্ছে। একটি পাল্টা উদাহরণের জন্য সফ্টওয়্যারটির পিছনে বিকাশ প্রক্রিয়াটি দেখুন যা ব্যর্থ হলে লোকেরা মারা যায়।

— বিল কে

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

— মাইকেল ব্রাউন 14

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

— মাইকেল ব্রাউন 18

Answer 2

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

অন্যান্য শিল্পের অনেক ডিজাইন হয় হয় মূল অনুমানের চেয়ে বেশি সময় নেয়, ব্যয় আরও বেশি করে, বা কখনই শেষ হয় না। পরিচিত শব্দ?

সুতরাং, আমরা যখন সফ্টওয়্যার পরিকল্পনা করছি আমরা কি করছি? ঠিক আছে, আমরা এখনও ডিজাইন করছি তবে আগের পর্যায়ে।

সফ্টওয়্যারটিতে নোটের কোনও উত্পাদন লাইন নেই। চূড়ান্ত উপাদানটি তৈরি করা (তুলনামূলকভাবে) সস্তা, এবং সেই চূড়ান্ত পণ্যটির প্রতিলিপি নিখুঁত এবং কার্যকরভাবে উভয়ই বিনামূল্যে - আপনি বিল্ড শিল্পকর্মগুলি অনুলিপি করেন।

Comments

এমনকি ওপির উল্লিখিত শিল্পে, অ্যারোস্পেস, বোয়িং 787 ড্রিমলাইনার এবং জেএসএফ এফ -35 উভয়েরই উল্লেখযোগ্য বিলম্ব হয়েছে। সিডনির অন্যতম বড় শপিং সেন্টারে গত সপ্তাহে একটি কার্পার্ক ভেঙে পড়েছিল। সিডনির খুব কঠোর বিল্ডিং মান রয়েছে তবে ভুলগুলি ঘটে।

— Teambob

এই হাজার বার। এমনকি প্রশ্নের তফসিলের লিঙ্কটি দেখায় যে প্রকল্পটি আসলে 1988 সাল থেকে বিকাশে ছিল The উত্স কোডটি হ'ল নকশা: বিকাশকারী

— ম্যাট

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

— মিস্টারলেন

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

— unk

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

— ডাঙ্ক

Answer 3

কিছু পরিসংখ্যান নির্দেশ করতে:

1. বাস্তবায়ন শুরু হওয়ার পরে প্রয়োজনীয়তার পরিবর্তন ; উদাহরণস্বরূপ যখন কারখানায় প্রথম এয়ারবাস এ 380 তৈরি করা শুরু হয়েছিল তখন আমি বিশ্বাস করতে পারি না যে কেউ যদি আরও 200 আসন চায় তবে সেগুলি সেখানে রাখা হবে; তবে একটি বড় সফ্টওয়্যার প্রকল্পে প্রোগ্রামাররা বিকাশ শুরু করার পরেও আরও 5 ধরণের ব্যবহারকারী যুক্ত করা যায়।
2. জটিলতা - বড় সফ্টওয়্যার প্রকল্পগুলি অত্যন্ত জটিল; সম্ভবত সবচেয়ে জটিল প্রকল্পগুলি হ'ল মানব ধরণের নকশা করা এবং বিকাশযুক্ত;
3. আর্কিটেকচার এবং ডিজাইনের পর্যায়ে পর্যাপ্ত সংস্থান ব্যয় হয় না ;
4. ক্ষেত্রের অপরিপক্কতা - সফটওয়্যার ইঞ্জিনিয়ারিং অন্যান্য ইঞ্জিনিয়ারিং বোনদের তুলনায় তুলনামূলকভাবে একটি তরুণ শৃঙ্খলা; এর দুটি বিষয় অন্তর্ভুক্ত রয়েছে: ক) এতগুলি হিউরিস্টিকস এবং ভাল অভ্যাস নয়; খ) এত অভিজ্ঞ বিশেষজ্ঞ অনেকেই নন;
5. গাণিতিক প্রমাণের অভাব - বেশিরভাগ ক্ষেত্রে গাণিতিক আনুষ্ঠানিক পদ্ধতিগুলি প্রমাণ করার জন্য ব্যবহার করা হয় না যে কোনও টুকরো সফ্টওয়্যার প্রয়োজনীয় হিসাবে কাজ করে; পরিবর্তে পরীক্ষার ব্যবহার করা হয়। এটি অন্যান্য প্রকৌশল ক্ষেত্রে সত্য যা গণিতে বেশি নির্ভর করে; এর কারণ হিসাবে জটিলতা;
6. রাশ - অনেক পরিচালকের অগ্রহণযোগ্য সময়সীমা রয়েছে; সুতরাং কোডের মানটি দ্বিতীয় স্থানে রাখা হয়েছিল, কারণ সময়সীমাটি।

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

Comments

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

— টিডামার্স

টিডামারস, এমন একটি সরঞ্জাম রয়েছে যা আপনাকে দু'জনে একবারে লিখতে সহায়তা করতে পারে: কোক একটি প্রত্যয়িত কোক প্রোগ্রাম থেকে ওকামল বা স্কিমের কোনও প্রোগ্রাম নিষ্কাশন করতে "প্রোগ্রাম এক্সট্রাকশন" সমর্থন করে।

— jkff

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

— অলস ডিবিএ

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

— মিথ্যা রায়ান

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

— সিড করুন

Answer 4

প্রশ্নের ভিত্তি কিছুটা ত্রুটিযুক্ত। A380 এবং বোয়িং 787 উভয়ই বছরের পর দেরীতে সরবরাহ করা হয়েছিল।

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

ক্যাটিএ-তে কোনও ভুল ছিল না, যা সর্বাধিক ব্যবহৃত এয়ারক্রাফ্ট ডিজাইনের সফটওয়্যার, তবে কেউ কোথাও সফ্টওয়্যার কনফিগারেশন বলটি বাদ দিয়েছে।

বোয়িং 787 সফ্টওয়্যার সম্পর্কিত বিলম্বের কারণেও ভুগছিল, তবে এর বেশিরভাগ সমস্যা হ'ল ওজন নিয়ন্ত্রণ এবং সরবরাহকারীরা নিম্নমানের অংশ সরবরাহের মতো নতুন plaতিহ্যবাহী বিমানের সমস্যা।

প্রাথমিক বিমানের কাঠামোগত সমস্যা হওয়ার পরে A380 এবং B787 উভয়কেই তাদের ডানার নকশা সংশোধন করতে হয়েছিল।

বড় জটিল প্রকল্পগুলি সকল ক্ষেত্রেই মানুষের পক্ষে কঠিন difficult

Comments

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

— বেন ব্রোকা

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

— ইউফোরিক

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

— পয়েন্টি

এবং যে এ 2010 এর সাম্প্রতিক হিসাবে A380 এর একটি বড় স্মরণ রয়েছে, আমি তখনও এটিকে "নির্দোষ" বলব না।

— মুহাম্মদ আলকারৌরি

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

— সিলভারব্যাক

Answer 5

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

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

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

নকশাকৃত পরিকল্পনাটি পরিকল্পনার জন্য এক মাস সময় লাগে, বিকাশের নকশা করতে দুই থেকে ছয় মাস, স্থপতি, পরিকল্পনা পরামর্শক, কাঠামোগত প্রকৌশলী, বায়ু প্রকৌশলী, পরিষেবাদি প্রকৌশলী, পরিমাণ এবং ব্যয় পরামর্শদাতা, সমীক্ষক, অ্যাক্সেসিবিলিটি ইঞ্জিনিয়ারদের এবং তালিকাটিতে রয়েছে ...

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

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

নকশা বনাম বিকাশের যুক্তি হিসাবে, আমি মনে করি উভয় প্রক্রিয়া নকশা-অন্তর্নির্মিত। এগুলি পৃথক করে রাখা একাডেমিকভাবে দুর্দান্ত লাগছে তবে জিনিসগুলি কীভাবে কাজ করে তা আপনি যদি না জানেন তবে ডিজাইন করা সম্ভব নয়। আপনি কেবল ব্যর্থতার ঝুঁকি বাড়িয়েছেন।

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

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

Comments

+1 অন্তর্দৃষ্টি জন্য ধন্যবাদ। "আপনি কীভাবে জিনিসগুলি কীভাবে কাজ করে তা জানেন কিনা তা ডিজাইন করতে" -> "জিনিসগুলি কীভাবে কাজ করে তা আপনি যদি জানেন না তবে ডিজাইন করতে"?

— টোকল্যান্ড

আরে বিল্ডার, আমি এই পোস্টে কিছু সম্পাদনা করার পরামর্শ দিয়েছিলাম, আমার মনে হয় আপনার কাছে চমৎকার পয়েন্ট রয়েছে, আমি কিছু ব্যাকরণ পরিষ্কার করার চেষ্টা করেছি।

— স্টিভেন

ইঞ্জিনিয়ারিংয়ের চেয়ে প্রোগ্রামিং একটি শিল্পের চেয়ে বেশি হওয়ার বিষয়ে আমি অবশ্যই একমত। আমি প্রায়শই সফটওয়্যার ডিজাইনের মূল দিক হিসাবে সৃজনশীলতাকে পাই।

— ল্যাঞ্জাফাম

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

— সাইমন রব 11 ই

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

— পিটার এ স্নাইডার

Answer 6

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

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

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

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

Comments

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

— নাথান লং

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

— টিএমএন

"সফ্টওয়্যার বিকাশ বেশিরভাগ ডিজাইন প্রক্রিয়া যেখানে নকশার নথিটি সোর্স কোড হয়" আপনি কেবল আমার চোখ খুললেন opened ধন্যবাদ।

— ব্রো কেভিন ডি

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

— সরবরাহকে শ্যাফটে আটকানোর

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

— টিএমএন

Answer 7

ভাবুন, এয়ারবাস এ 380 এর ডিজাইনের মাঝখানে, কেউ একটি সভায় পাইপ লাগিয়ে বললেন, "হেই, এটাকে ট্রিপলিন হিসাবে গড়ে তুলতে পারবে?" অন্যরা এই বলে যোগ দিয়েছিলেন, "হ্যাঁ, হ্যাঁ। একটি ট্রিপলেন। আরও ডানা আরও ভাল।" পরের বছরগুলিতে আপনি A380 ডিজাইনটিকে ট্রিপলেনে পরিণত করতে ব্যয় করেছেন। অন্য সভায় কেউ বলে, "একটি ট্রিপলেন? এটি পুরানো। আমরা বাইপ্লেইন চাই Just একটি ডানা সরিয়ে ফেলুন।"

বা কল্পনা করুন, একটি সেতু নির্মাণ প্রকল্পের মাঝামাঝি কেউ বলে, "হে, আমরা কেবল একটি শিপিং সংস্থার সাথে একটি চুক্তি করেছি They সেতুটি আরও 40 ফুট উঁচু হওয়া দরকার কারণ তাদের জাহাজগুলি অনেক লম্বা it এটি ঠিক করুন। ধন্যবাদ । "

এগুলি তবে কয়েকটি কারণ যা বড় এবং ছোট, সফ্টওয়্যার প্রকল্পগুলি একটি উদ্বেগজনক হারে ব্যর্থতায় শেষ হয়।

Comments

ঠিক এটাই ঘটে what পরিচালনার ধরণগুলি বা ক্লায়েন্টরা প্রতি 10 সেকেন্ডে তাদের মন পরিবর্তন করে যা কেবল বিকাশকারীদের হতাশ করে। আমি এর মতো বাজে কারণে আমার শেষ কাজটি ছেড়ে দিয়েছি

— এরিন

এটি মাথায় আসে: youtube.com/watch?v=BKorP55Aqvg&feature=kp

— অলৌকিক ঘটনা

Answer 8

যান্ত্রিক ইঞ্জিনিয়ারিং ব্যাকগ্রাউন্ডের কেউ আইটিতে কর্মরত হিসাবে আমি প্রায়শই আইটি-তে সাফল্যের হার কম হওয়ার কারণগুলি নিয়ে ভাবছিলাম won

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

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

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

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

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

Comments

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

— আর্সেনী মোরজেঙ্কো

@ মাইনমা: খারাপ উদাহরণ, আপনি কি ডিভিড থেকে আপনার বোতাম, পাঠ্যবক্স, বিকল্প বাক্স, বিকল্প বাক্সগুলি তৈরি করেন? না, আপনি ব্রাউজারের ফর্ম উপাদানগুলি পুনরায় ব্যবহার করেছেন; এবং ব্রাউজারগুলি অপারেটিং সিস্টেমের ফর্ম উপাদানগুলি ব্যবহার করে।

— মিথ্যা রায়ান

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

— আরসেনি Mourzenko

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

— মাইকে 30

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

— সেপ্টেম্বর

Answer 9

আমি ভীত যে আপনার বক্তব্যের সাথে আমি একমত নই।

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

কোনও সফ্টওয়্যার প্রকল্প স্ক্রু হিসাবে বিমান বিমান প্রকল্প স্ক্রু করা সমান সহজ। যদি কেবল সফ্টওয়্যার শিল্পে বিমান চালনা শিল্পে প্রবেশের বাধা এত কম থাকে তবে আপনি অবশ্যই অনেকগুলি ব্যর্থ বিমান প্রকল্প দেখতে পাবেন।

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

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

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

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

Comments

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

— কেন ব্লুম

এটি উচ্চ মানের সফ্টওয়্যারটির একটি সর্বোত্তম উদাহরণ: 420,000 লাইন এবং বাগ ফ্রি: স্পেস শাটল চালিত সফ্টওয়্যার । মনে মনে, এই ধরণের মানের পাওয়ার সাথে যুক্ত প্রচুর ব্যয় হয়েছিল।

— dodgy_coder

@ ডডজি_কোডার, নিরাপদ বিমান তৈরি করা সস্তা নয় ;-)

— করিম আঘা

@ পলনাথন শালীন খুব সাবজেক্টিভ;)

— জেমস খুরি

@ করিমা .: নিরাপদ বিমান তৈরি করা সস্তা নয়, তবে একটি বিমান নিরাপদ করে তোলে তার একটি বড় অংশ হ'ল সফটওয়্যার ... সুতরাং বিমানের নকশার একটি গুরুত্বপূর্ণ অংশটি আসলে সফ্টওয়্যার ডিজাইন!

— অবাক

Answer 10

ডিজিটাল বিল্ডিং ব্লকগুলি 1 বা 0 হতে পারে in

একটি যান্ত্রিক ডিজাইনে টোলারেন্সের স্তর রয়েছে। আমি একটি ব্রিজের তুলনায় নিখুঁত rivet এর চেয়ে কম রাখতে পারি এবং এটি সম্ভবত নীচে নেমে আসবে না, তবে কোডে এমনকি একবারে 0 স্থাপনের ক্ষেত্রে যেখানে 1 থাকা উচিত পুরো প্রোগ্রামটি ব্যর্থ করতে পারে।

যৌগিক ও যৌক্তিক প্রকৃতির কারণে কম্পিউটিংয়ের যে কোনও, এমনকি খুব সামান্য পরিবর্তনগুলি কঠোর ব্যর্থতা হতে পারে।

Comments

আমি একবার কাউকে বলতে শুনেছি "নির্মাণটি প্রোগ্রামিংয়ের মতোই হবে যদি আপনি বাড়ির পিছনে চূড়ান্ত ডোরকনব লাগান, পুরো ঘরটি বিস্ফোরিত হয়"।

— মরগান হের্লোকার

Answer 11

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

আমি মনে করি আমরা এমন একটি ব্যবসায় রয়েছি যেখানে ত্রুটি সস্তা । প্যাচিং সফ্টওয়্যারটি আকাশচুম্বী পুনর্নির্মাণের তুলনায়, বা বিক্রি হওয়া প্রতিটি সেলফোনকে স্মরণ করার তুলনায় সস্তা।

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

সংক্ষেপে আমি বিশ্বাস করি এটি একটি সংস্কৃতি সমস্যা, এবং আমি আশা করি এটি পরিবর্তিত হবে।

Comments

আপনি কি প্রোগ্রামারদের বুঝতে পেরেছেন যারা ত্রুটি-মুক্ত কোড তৈরির জন্য সর্বাত্মক প্রচেষ্টা করেন না, কারণ এতে দ্বিগুণ সময় লাগবে এবং গতকাল

— বিটা

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

— ওয়েক্সওয়েং

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

— বিস্মিত

Answer 12

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

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

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

Answer 13

আমার কাছ থেকে কিছু জিনিস:

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

অন্যদিকে, সফ্টওয়্যার প্রকল্পগুলি প্রায় সর্বদা স্ক্র্যাচ থেকে শুরু করে কিছু ছোট ফ্রেমওয়ার্ক / সাহায্যকারী রাখে।

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

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

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

অন্যদিকে সফ্টওয়্যারটির ক্রমবর্ধমান পরিবর্তন রয়েছে যা প্রায়শই কেবল "" সেই কাজগুলি তৈরি করে ", তবে প্রয়োজনীয় পণ্য সমাপ্ত হয় না। এছাড়াও, আইটি-তে এটি বলা অস্বাভাবিক নয় যে "ওহে, আসুন আমাদের বিমানটিতে আরও একটি লাগেজ বগি যুক্ত করুন যা অতিরিক্ত 50 টন ধারণ করে"।

Answer 14

আমি মনে করি উত্তরটি বেশ সহজ:

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

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

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

Answer 15

আমি জ্যাক গ্যানসেলের এমবেডেড মিউজিকের একটি নিবন্ধের ভারব্যাটিম কপি ব্যবহার করে উত্তর দেওয়ার চেষ্টা করব। যদিও এটি সর্বত্র ফার্মওয়্যার বলছে, কেবল মানসিকভাবে এটিকে সফ্টওয়্যার দ্বারা প্রতিস্থাপন করুন।

কিসের তুলনায়?

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

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

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

নিম্নলিখিত বুদ্বুদ সাজানোর বিবেচনা করুন, উইকিপিডিয়া থেকে নির্লজ্জভাবে উত্থাপিত এবং নির্ভুলতার জন্য পরীক্ষা করা হয়নি:

void bubblesort(int * A, int n){

    for(int i(0); i < n; ++i)

        for(int j(0); j < n - i - 1; ++j)

            if(A[j] > A[j + 1])

                std::swap(A[j], A[j + 1]);

}

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

একজন যান্ত্রিক প্রকৌশলী গর্ব করতে পারে যে তার পেশা কম্পিউটারের অনেক আগেই সরার তৈরি করেছিল। আইবিএমের 1949-যুগের মডেল 82 কার্ড সর্দার বিবেচনা করুন ( http://www.columbia.edu/acis/history/sorter.html ) প্রতি মিনিটে 650 কার্ডের মাধ্যমে একটি ইনপুট সহ, আমাদের কোড স্নিপেট এমনকি 4 মেগাহার্টজ-এ পরিচালনা করতে পারে Z80। মডেল ৮২, অবশ্যই, একবারে কেবলমাত্র একটি কার্ডের একটি কলাম সাজাতে; সম্পূর্ণরূপে একটি ডেক সাজানোর জন্য কয়েক ডজন পাস নিতে পারে।

এই জন্তুটির নকশা তৈরি করতে এবং এটি তৈরি করতে কত সময় লেগেছে? বছর, সন্দেহ নেই। এবং এর কার্যকারিতাটি আমাদের কোডের সাথে তুলনা করে যা এত দ্রুত এবং যা বিশাল ডেটাসেটগুলি পরিচালনা করতে পারে। তবে সেটি ছিল 1949. এফপিজিএ এবং ভিএইচডিএল বা সিপিইউ ছাড়াই বৈদ্যুতিন উপাদানগুলি থেকে বুদ্বুদ সাজানোর জন্য কত সময় লাগবে?

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

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

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

এই 7 কোডের ছোট ছোট লাইনগুলি প্রতিস্থাপন করতে। কয়েকটি বাস্তব এম্বেড প্রোগ্রাম 10,000 এর চেয়ে কম; অনেক মিলিয়ন ছাড়িয়ে গেছে। একটি বাস্তব, সুপার-সাইজের কম্পিউটার প্রোগ্রাম প্রতিস্থাপনের জন্য কতটা হার্ডওয়্যার এবং কত প্রকৌশল প্রয়োজন হবে?

একটি স্প্রেডশিটের মত একটি বাস্তব প্রোগ্রাম বিবেচনা করুন। প্রসেসর ছাড়াই একটি তৈরি করতে কত সার্কিটারি লাগবে? এটি কোনও শহরের আকার হতে পারে।

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

তাই তো! সফটওয়্যার / ফার্মওয়্যারের অতুলনীয় জটিলতা রয়েছে।

Answer 16

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

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

Comments

সফ্টওয়্যার বিকাশের অপরিপক্কতার বিষয়ে +1। সিভিল ইঞ্জিনিয়ারিং এর অনুশীলনগুলি বিকাশ করতে কয়েক হাজার বছর কেটে গেছে। এরোস্পেসে একশ হয়েছে এবং অন্যান্য ইঞ্জিনিয়ারিং শাখার উপর ভিত্তি করে। সফটওয়্যার এখনও তরুণ। এটি সাধারণত খারাপভাবে বোঝা যায় না। মানুষ স্ট্রিমের উপর ব্রিজ তৈরি করতে পারে বা বাচ্চাদের হিসাবে কাগজ বিমান তৈরি করতে পারে - এটি সফ্টওয়্যারটির ক্ষেত্রে সত্য নয়।

— অ্যান্ডি বার্নস

Answer 17

সমস্ত বিকাশকারী সমানভাবে তৈরি হয় না। কিছু ভাল, অন্যদের ভাল, না।

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

Answer 18

ক্যাথেড্রালগুলি তৈরি করতে 100 বছর সময় লাগত।

কিছু এয়ারবাস বিমানের কাজ করার জন্য 1 মিলিয়ন লাইন কোডের প্রয়োজন।

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

Comments

কোলোন ক্যাথেড্রালটি 1248 সালে শুরু হয়েছিল এবং 1880 সালে শেষ হয়েছিল 63৩২ বছর।

— gnasher729

Answer 19

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

আশ্চর্যের বিষয়, অনেক লোক আমলাতন্ত্র কী তা জানেন না (এটি প্রায়শই রাজনীতির সাথে বিভ্রান্ত হয়), এমনকি / যখন তাদের আমলাতন্ত্রের সমস্যা থাকে।

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

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

Answer 20

আপনার জন্য আমার একটি সংক্ষিপ্ত সংস্করণ রয়েছে:

যা করা সহজ, বা প্রবাহিত হোক না কেন, আমরা আমাদের পরিবর্তে এটি করার জন্য একটি প্রোগ্রাম লিখি।

এবং তার পরিবর্তে মেটা-প্রক্রিয়াটির সাথে লড়াই করুন।

এটি প্রতি সেকেন্ডে তেমন সত্য নয়, তবে প্রতিদিন হাজার হাজার ব্লগ ব্লগ ইঞ্জিন লেখার পরিবর্তে সেট আপ করা হয়। প্রতিটি কর্ম দিবসে, এগুলির জন্য বিশেষভাবে ডিজাইন করা ডাটাবেস অ্যাপ্লিকেশনগুলি লেখার পরিবর্তে কয়েক হাজার এক্সেল ম্যাক্রো লেখা হয়।

এখানে আরও অনেকগুলি কারণ রয়েছে - এর মধ্যে কয়েকটি এখানে উল্লেখ করা হয়েছে - তবে আমি এই বিষয়টিকে আলোচনায় যুক্ত করতে চেয়েছিলাম।

Comments

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

— ড্রুগানস

কেবল তা-ই নয়, এর আগে আমরা যেভাবে বৃহত প্রোগ্রামগুলি নির্বিঘ্নে বিতরণ করি সেগুলিই কি আমরা কেবল তার ওয়েবসাইট থেকে পুরানো প্রোগ্রামটি ডাউনলোড করে একটি অনুলিপি তৈরি করি। তবে কোনও কারণে এটি সফল একটি বৃহত সফ্টওয়্যার প্রকল্প হিসাবে গণনা করে না।

— বিডএসএল

Answer 21

জবাবদিহিতার অভাব ... একটি বিমান বিধ্বস্ত হলে লোকেরা মামলা করে। সফ্টওয়্যার শিল্প যেকোন সফ্টওয়্যার ত্রুটিতে কোনও দায়বদ্ধতা অস্বীকার করে, তাই একটি শক্তিশালী এবং নিরাপদ পণ্য তৈরি করতে উত্সাহের অভাব তৈরি করে।

Comments

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

— ভেক্টর

যদি এমনটি হয় তবে ব্যয় বৃদ্ধি পাবে এবং বৈশিষ্ট্যগুলি হ্রাস পাবে।

— জিম জি।

@JimG। প্রশ্নটি নির্ভরযোগ্যতা সম্পর্কে ছিল, বৈশিষ্ট্য বা দাম নয়। অবশ্যই আরও নির্ভরযোগ্য পণ্য তৈরি করা আপনার নকশার স্থানের আরও প্রতিবন্ধকতাগুলির পরিচয় দেবে এবং অন্যান্য দিকগুলি (বৈশিষ্ট্য এবং ব্যয়) ভোগ করতে পারে।

— গ্রেজিগ

এবং বোয়িং 7৩7 এর মূল্য $ 50-80 মিলিয়ন। আপনি প্রতিবার একবার পেলে অর্থ প্রদান করেন - আপনি প্রতিবার অফিস খোলার জন্য কি অর্থ প্রদান করেন? যদি প্রতিবার আমার অর্থ প্রদান করা হয় তবে কেউ আমার সফ্টওয়্যারকে অভিঘাত ব্যবহার করে সরাসরি আমি নির্ভরযোগ্যতার জন্য উত্সর্গীকৃত হয়ে থাকি।

— ফ্লাওয়ারস্কেপ

@ জিম জি: আমি 5 টি ক্রেপী না হয়ে একটি পণ্যের স্থিতিশীল সংস্করণ পছন্দ করতে চাই।

— জর্জিও

Answer 22

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

সফটওয়্যার প্রকল্পগুলিতে এটি ব্যবহারিকভাবে এবং মানব প্রকৃতির বিষয় হিসাবে উভয়ই সম্ভব তবে কঠিন।

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

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

Answer 23

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

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

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

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

সুতরাং, সংক্ষেপে, বড় প্রকল্পগুলি সরবরাহ করা এবং প্রকল্পের সময়রেখা এবং রোডম্যাপগুলি অনুমান করা কেন শক্ত কারণ হ'ল সফ্টওয়্যার বিকাশ এবং বিশেষত কাজের নকশা অত্যন্ত জটিল ক্ষেত্র। জটিলতা মূল সমস্যা।

Comments

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

— জুলিয়া হ্যাওয়ার্ড

Answer 24

"বৃহত প্রকল্প" এর সংজ্ঞাটি স্কিউড।

প্রযুক্তিগতভাবে একটি বড় প্রকল্প সময়মতো বিতরণ করা যায় এবং নির্বিঘ্নে, মঞ্জুর করা হয় এটি এমন কিছু যা বহু বছর ধরে বহুবার নির্মিত হয়েছে।

• একটি প্যাক ম্যান ক্লোন
• একটি ক্যালকুলেটর
• একটি পাঠ্য সম্পাদক

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

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

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

Comments

ব্ল্যাকহোল চালিত ভ্যাকুয়াম ক্লিনার? কার্যকরী সুরক্ষা সম্পর্কে কি?

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

কার্যকরী সুরক্ষার অভাব? এটি একটি বৈশিষ্ট্য! ব্ল্যাকহোল ভ্যাকুয়াম ক্লিনার দিয়ে কোনও কিছু পরিষ্কার করার চেষ্টা করার সময় আমরা অপরিবর্তনীয় কাঠামোর ব্যবহারের পক্ষে থাকি।

— ড্রোগানস

Answer 25

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

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

সংক্ষেপে, সফ্টওয়্যারটি নিজেই ডিজাইন করা প্রায়শই কাজের সহজ অংশ part শক্ত অংশটি তাদের জন্য মানুষের কাজের পুনর্নির্দেশ করছে। এটি দিয়ে শুরু করা কঠিন; এটি এমনভাবে করা যা কেবল কাজ করবে না, তবে এটি গ্রহণ করা এখনও অনেক বেশি কঠিন।

Answer 26

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

দৃ rob় সফ্টওয়্যার সম্পর্কিত, আপনি যে কোনও বিমান, গাড়ি (এবিএস, ইপিএস, জলবায়ু নিয়ন্ত্রণ ইত্যাদি) দেখুন বা স্পেস শাটলে তাদের 50% এরও বেশি সফ্টওয়্যার রয়েছে যা এগুলি চালাচ্ছে এবং আমাকে বিশ্বাস করুন তারা খুব শক্তিশালী। এটি ঠিক যে আমরা সফ্টওয়্যারটির আরও বেশি কাছাকাছি এবং আরও অনেকগুলি সফ্টওয়্যার প্রোগ্রাম রয়েছে, তাই আমরা সেগুলিতে আরও ত্রুটি দেখতে পাই see

দেখুন: http://www.globalprojectstrategy.com/lessons/case.php?id=23 এবং দেখুন এয়ারবাস এ380 কতটা সফল হয়েছিল।

Answer 27

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

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

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

প্রকৃতপক্ষে, আমি ইঞ্জিনিয়ার না হওয়ার সিদ্ধান্ত নেওয়ার একটি প্রধান কারণ হ'ল আপনি যদি আপনার বেশিরভাগ সময় একটি বিদ্যমান উদ্ভাবনের 10% উন্নতি ডিজাইন করার জন্য ব্যয় করেন, যখন একই সময়টি কোনও সামাজিক নেটওয়ার্কের মতো আরও দৃশ্যমান কিছু প্রোগ্রাম করার জন্য ব্যবহৃত হতে পারে ।

ইঞ্জিনিয়ারিংয়ে অনেক নতুন ডিজাইন নেই; অত্যন্ত দক্ষ প্রকৌশলী এমন কেউ হলেন যে কোনও বিদ্যমান ডিজাইনে নতুন কোনও কিছুর পরিবর্তন করতে পারে বা এর উন্নতি করতে পারে। তবে প্রায় প্রতিটি প্রোগ্রামারই ডিজাইন পরিবর্তন করতে, সেগুলি হ্যাক করতে বা নতুন কিছু তৈরি করার প্রত্যাশা করে।

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

সফ্টওয়্যারটিতে প্রকল্প পরিচালনা কুখ্যাতভাবে কঠিন । সময়ের অনুমানগুলি কাজটি করে লোকেদের দ্বারা সর্বোত্তমভাবে কাজ করা হয় তবে তারা যখন অনুমান তৈরিতে ব্যস্ত থাকে তখন তারা কোড লেখেন না । এটি লোকেদের কোনও প্রকল্প পরিচালন এড়াতে প্ররোচিত করে।

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

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

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

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

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

Answer 28

অন্যান্য কারণগুলিতে সত্যিকার অর্থে আবৃত হয়নি এমন একটি কারণ হ'ল সফটওয়্যার ক্ষেত্রটি এমন গতিতে উদ্ভাবিত হয় যা বৈষয়িক ভিত্তিক বিশ্বে খুব কমই ঘটে।

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

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

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

Comments

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

— আর্সেনী মোরজেনকো

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

— পিটার এ স্নাইডার

Answer 29

আমার কাছে সফটওয়্যার ইঞ্জিনিয়ারিংয়ের প্রধান সমস্যাটি হ'ল কেস, ব্যবহারকারী এবং ক্রস প্ল্যাটফর্ম ব্যবহার।

ব্যবহারের ক্ষেত্রে

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

ব্যবহারকারী

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

ক্রস প্ল্যাটফর্ম

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

Answer 30

আপনি যদি ভাবেন যে অন্য শিল্পগুলি কোনও ঘটনা ছাড়াই প্রকল্পগুলি সম্পূর্ণ করে আপনার 1977 সালে নির্মিত সিটিগ্রুপ সেন্টার বিল্ডিংয়ের গল্পটি পড়া উচিত Even প্রায় 7 বছর পর পরিকল্পনা এবং নির্মাণের পরেও ভবনটি একটি গুরুতর নকশার ত্রুটি সম্পন্ন হয়েছিল যা একটি ধসে পড়েছিল collapse ঝড় ঘটনা প্রতি 16 বছর প্রত্যাশিত।

অন্য কথায়, প্রতি বছর সিটিকর্প সেন্টার দাঁড়িয়ে ছিল, প্রায় 1-ইন -16 সম্ভাবনা ছিল এটি ধসে পড়বে।

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

লেমেসুরিয়ার যেমনটি বলেছে ততক্ষণ পর্যন্ত সবকিছু ঠিকঠাক মনে হয়েছিল, তিনি একটি ফোন কল পেয়েছিলেন। লেমেসুরিয়ারের মতে, ১৯ 197৮ সালে একজন স্নাতক আর্কিটেকচারের ছাত্র তার সাথে লে-ম্যাসুরিয়ারের বিল্ডিং সম্পর্কে সাহসের সাথে দাবি করেছিলেন: যে সিটি করর্প সেন্টার বাতাসে উড়ে যেতে পারে।

নকশার ত্রুটির গোপনীয়তা বজায় রাখতে ন্যূনতম পরিমাণে জড়িত রাতের আড়ালে আক্ষরিক মেরামত করা হয়েছিল।

ভবনের চারপাশে 10-ব্লকের ব্যাসার্ধের জন্য জরুরি সরিয়ে নেওয়ার পরিকল্পনা প্রস্তুত করা হয়েছিল।

তারা সারা রাত ldালাই করত এবং দিনের বেলা থেকে বিরতি দেয়, ঠিক যেমন বিল্ডিং দখলকারীরা কাজে ফিরে আসে।

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

যা প্রশ্ন উত্থাপন করে; প্রকল্পগুলির মধ্যে আরও কতগুলি মারাত্মক নকশার ত্রুটিগুলি জনসাধারণের স্বীকৃতি ছাড়াই গোপনে মেরামত বা উপেক্ষা করা হয়েছিল।

• ডিজাইনের ত্রুটি যা প্রায় একটি এনওয়াইসি আকাশচুম্বী মুছে ফেলেছিল (স্লেট.কম)
• সিটি গ্রুপ গ্রুপ (উইকিপিডিয়া ডটকম)