আমি ব্যাখ্যা করতে চাই কেন বিকাশের সময়কালে স্পেসিফিকেশনটি পরিবর্তন করা উচিত নয়

11

আমি ব্যাখ্যা করতে চাই যে উন্নয়ন পরিকল্পনা চলাকালীন কেন নতুন পরিকল্পনা বিভাগের কর্মীর কাছে স্পেসিফিকেশনটি পরিবর্তন করা উচিত নয়।

requirements specifications requirements-management

— সুংগুক লিমি
সূত্র

4

চলমান টার্গেটের বিরুদ্ধে প্রোগ্রামিং করা অর্ধেক মজা!

— অ্যান্টনি পেগ্রাম

1

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

7

"উভয় হিমশীতল হলে জলের উপর দিয়ে হাঁটা এবং একটি নির্দিষ্টকরণ থেকে সফ্টওয়্যার বিকাশ করা সহজ" " - এডওয়ার্ড ভি বেরার্ড

— জেসন হল

1

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

— জনি কোয়েস্ট

1

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

— ব্যবহারকারী16764

18

উন্নয়নের সময়ে একটি স্পেসিফিকেশন প্রায় সর্বদা পরিবর্তিত হয় সবচেয়ে সহজ প্রকল্পগুলির মধ্যে।

কারণগুলি হ'ল:

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

কেন স্পষ্ট পরিবর্তনগুলি বিরূপ প্রভাব ফেলেছে (আপনি "এমনটি ঘটবে না" বলতে পারেন যেহেতু তারা দেখতে পাচ্ছেন যে তারা প্রচুর কারণ দেখায়, প্রায় সমস্ত আপনার নিয়ন্ত্রণের বাইরে এবং অনেকগুলি ভাল কারণে) -

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

এই সমস্ত পরিমাণটি অবশ্যই প্রকল্পের প্রসারণের তারিখটি বর্ধিত (কখনও কখনও উল্লেখযোগ্যভাবে) এবং ত্রুটির সম্ভাব্যতা বৃদ্ধির সম্ভাবনা বৃদ্ধি করে।

অনুমানের একটি ছোটখাটো পরিবর্তন কীভাবে চরম সমস্যা তৈরি করতে পারে তার সর্বোত্তম উদাহরণের জন্য আপনার কাছে আমার কাছে 3 টি চিঠি রয়েছে:

Y2K ।

তারা যা করেছিল তা হ'ল " 2000 সালের পরে অবশ্যই কাজ করা উচিত " এই কথাটি পাল্টেছিল ।

উপরন্তু, কিছু পরিস্থিতিতে এটা সত্যিই ক্ষেত্রে যে স্পেসিফিকেশন হয় আবশ্যক (যেমন "ভালো কারণ ছাড়াই পরিবর্তন করা উচিত" থেকে ভিন্ন) পরিবর্তন করবেন:

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

— DVK
সূত্র

ঠিক আছে; আমি এটা ফিরে আটকে।

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

— w

9

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

গুরুত্বপূর্ণ বিষয়টি হ'ল পরিবর্তনের ফলাফলগুলি স্পষ্টভাবে জানানো যাতে প্রত্যেকের নকশা প্রক্রিয়া সম্পর্কে বাস্তব প্রত্যাশা থাকে।

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

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

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

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

— tylerl
সূত্র

6

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

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

— ল্যারি ওয়াতানাবে
সূত্র

3

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

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

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

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

— কেভিন ক্লিন