একটি বড় সফ্টওয়্যার প্রকল্পের জন্য প্রয়োজনীয় সময় অনুমান করা কঠিন যে কীভাবে ব্যাখ্যা করবেন?

37

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

সফটওয়্যার বিকাশকারী নয় এমন ব্যক্তিকে আমি কীভাবে এটি ব্যাখ্যা করব ?

project-management  estimation  project 
— জোনাস
সূত্র
5
কৌতূহল: জুনিয়র বিকাশকারী হিসাবে এটি আপনার কাজটি কেন নন-সফ্টওয়্যার বিকাশকারীদের কাছে এটি ব্যাখ্যা করে? আপনার ওয়ার্ক গ্রুপ বা ম্যানেজমেন্ট চেইনে এমন কেউ আছেন যিনি আপনাকে বোঝানোর প্রয়োজন এমন কাউকে বোঝানোর প্রক্রিয়ায় আপনাকে সহায়তা করতে পারে?
— অ্যালেক্স ফেনম্যান
@ অ্যালেক্স: না, এটি একই সংস্থার কোনও ব্যক্তি নয়। একটি স্টার্টআপ করার জন্য আইডিয়া সহ কেবল একজন। এবং আমি একমাত্র বিকাশকারী যার সাথে তার যোগাযোগ রয়েছে।
— জোনাস
1
2
— gnat
— gnat

উত্তর:

48

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

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

— পেটার টার্ক
সূত্র
আরও অজানা মানে আরও অনিশ্চয়তা।
— surfasb
9
দূরে ভুলে যাও তাদেরকে অনুমান করতে বলুন - মিনিটে - কখন তারা সন্ধ্যাবেলা কাজ থেকে বাড়ি আসবে। ট্র্যাফিক যদি আলাদা হয় তবে কী হতে পারে, যদি বৃষ্টি শুরু হয় তবে কী হবে, গাড়ি চালানোর সময় আপনি যদি কোনও ফোন কল পান, ইত্যাদি কী .. যদি এমন কিছু জাগ্রত হয়, এবং নিজের ড্রাইভ হোম হিসাবে প্রায়শই সঞ্চালিত হয়, তবে কোনও পরিমাণে নির্ভুলতা পরিমাপ করা যায় না - তবে কীভাবে কিছু জটিল সফ্টওয়্যার বাস্তবায়নের জন্য প্রয়োজনীয় সময়টি অনুমান করার জন্য আমরা কী আরও ভাল আশা করতে পারি, যার কাজ থেকে কাজকর্মের তুলনায় একটি ড্রাইভ হোমের চেয়ে এটিতে আরও বেশি এবং আরও উল্লেখযোগ্য পরিবর্তনশীল রয়েছে।
— কোয়ান্টিন-স্টারিন
8
@qes, আমি পাবলিক পরিবহন ব্যবহার, তাই আমি 10 সম্পর্কে% সঠিকতা সঙ্গে বলতে পারেন আমি বাড়িতে এসে পৌঁছলে হবে - আমি মনে করি সবচেয়ে দঃপঃ প্রকল্প পরিচালকদের acccuracy এর ;-) এই স্তরের সাথে খুশি হবে
— পিটার Török
1
সফ্টওয়্যার প্রকল্পের লক্ষ্যগুলিও পরিবর্তিত হয়, সুতরাং ওপির প্রয়োজনীয় সময়টি অনুমান করার পরে তারা যদি জিজ্ঞাসা করতে পারে যে তারা যখন প্রথম দিকের অর্ধগতিতে পৌঁছেছে তখন তাদের কেউ শিখরে স্যুইচ করতে বলার পরেও তারা সময়মতো রয়েছেন?
— পল
18

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

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

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

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

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

— টমাস ওভেনস
সূত্র
7

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

পড়তে হবে: http://en.wikedia.org/wiki/The_Mythical_Man-Month

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

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

— জর্জেন স্ট্রোবেল
সূত্র
2

এই অনুমানের সাথে তারা কী পরিকল্পনা করছে তা সন্ধান করুন। তাদের মনে তারা জানতে চায় এটি কয়েক মাস বা বছর সময় নেয় কিনা এবং আপনি সঠিক ঘন্টা (সাধারণ প্রকৌশলী) পাওয়ার চেষ্টা করছেন।

আপনি যদি প্রকল্পের কোনও অংশে কাজ করতে পারেন এবং প্রয়োজনে আরও ভাল অনুমান একসাথে রাখতে পারেন তা দেখুন।

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

— JeffO
সূত্র
1

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

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

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

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

মাইক্রোসফ্টের মতো একটি বড় সংস্থা যদি নিজের পণ্য উত্পাদন করতে গিয়ে সময় নির্ণয় করতে পারে তবে কীভাবে করব?

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

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

পুরো প্রকল্পের সময়ের অনুমানটি সাধারণত প্রোগ্রামার না হয়ে প্রকল্প পরিচালক দ্বারা সম্পাদিত হয় is

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

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

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

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

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

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

— মাইক ক্রফোর্ড
সূত্র
1
সফটওয়্যার ইঞ্জিনিয়ারিং 42 বছর বয়সের অন্যান্য ইঞ্জিনিয়ারিং শাখার চেয়ে এখনও বেশি (আরও বেশি) is তবে অনেকগুলি পরিপক্ক অনুমানের কৌশল এবং সরঞ্জাম রয়েছে are ওয়াইডব্যান্ড ডেলফি (১৯৮০ সালে ব্যারি বোহেমের সফটওয়্যার ইঞ্জিনিয়ারিং ইকোনমিক্স দ্বারা জনপ্রিয়), ফাংশন পয়েন্ট (1979), এসইআর-এসইএম (1960 এর দশক), প্রক্সি ভিত্তিক অনুমান (পিএসপিতে ব্যবহৃত, 1994 সালে বিকাশিত) SEI), এবং COCOMO (1981) এবং COCOMO II (1997)। যে ক্ষেত্রটি কেবলমাত্র 42 বছর, সেখানে ইতিমধ্যে প্রকল্পগুলির প্রাক্কলন হিসাবে প্রায় 40 বছর কাজ হয়েছে।
— টমাস ওয়েন্স
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.