স্থাপত্য সংক্রান্ত সমস্যাগুলি কোথায় বর্ণনা করবেন?

Question

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

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

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

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

তাহলে, আমি কোথায় এই সমস্যাগুলি বর্ণনা করব? বাগ ট্র্যাকিং সফটওয়্যার? অথবা সিস্টেমের আর্কিটেকচার বর্ণনা করে নথিতে আমি কি আর্কিটেকচার থেকে বাস্তবায়নের বিচ্যুতিগুলি বর্ণনা করব?

Comments

আমি পাই না। আপনি বাস্তবায়নের উপর ভিত্তি করে আর্কিটেকচারটি বর্ণনা করেছেন, তারপরে আবিষ্কার করুন যে প্রয়োগটি বর্ণনার সাথে খাপ খায় না। তাহলে কি আপনার বর্ণনাটি ত্রুটিযুক্ত নয়?

— back2dos

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

— থমাস ওভেনস

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

— ডক ব্রাউন

Answer 1

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

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

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

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

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

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

Comments

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

— জিমি হোফা

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

— BЈовић

আইইক ... $ 90>_<

— রবার্ট হার্ভে

Answer 2

সিস্টেমের আর্কিটেকচারকে আনুষ্ঠানিক করার সময় এটি গুরুত্বপূর্ণ যে আপনি কেবল আর্কিটেকচারটি টেবিলটিতে কী আনবেন তার পিছনে যে মূল্য রয়েছে তা নয়, এটি বুঝতে হবে এবং এটি কী হওয়া উচিত তাও উপলব্ধি করা উচিত।

সফ্টওয়্যার বা কারিগরী স্থাপত্য প্রাথমিক গোল চিহ্নিত হয় অ ক্রিয়ামূলক প্রয়োজনীয়তা যে দ্বারা নিরূপিত হয় গুণমান বৈশিষ্ট্যাবলী যে তাড়িয়ে দেবেন সিস্টেম আর্কিটেকচার ।

অ-কার্যকরী প্রয়োজনীয়তার উপর:

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

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

গ্রীনফিল্ড প্রকল্পে যখন বাস্তবে গুরুত্বপূর্ণ তাত্পর্যপূর্ণ প্রয়োজনীয়তাগুলি সনাক্ত করা বোধগম্য হয় তবে বিদ্যমান সফ্টওয়্যার নিয়ে কাজ করার সময় যতটা সম্ভব শৃঙ্খলাবদ্ধ হওয়া ভাল। আপনি চাইবেন না যে আপনার সফ্টওয়্যার আর্কিটেকচারটি বিদ্যমান সিস্টেমের দ্বারা প্রভাবিত হোক।

সফ্টওয়্যার আর্কিটেকচারের অনুমোদনযোগ্য হওয়ার জন্য 3 টি জিনিস থাকা দরকার।

ঘোষণামূলক

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

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

যুক্তিসহ ব্যাখ্যা

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

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

ঝুঁকি

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

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

আপনার ঝুঁকিগুলি ডায়াগ্রামেও করতে পারে যেখানে বর্তমান অবস্থা বর্তমানে আর্কিটেকচার থেকে বিচ্যুত হয়। এই ঝুঁকিগুলি এখন তাদের উন্নয়ন প্রকল্পের মাধ্যমে বা তাদের প্রকল্প পরিকল্পনার মাধ্যমে বা ব্যাকলগে যুক্ত করার মাধ্যমে সমাধান করা যেতে পারে।

Answer 3

আপনার প্রকল্পটির বর্তমান কাঠামো, বা প্রকল্পের পছন্দসই কাঠামো, বা উভয়ই নথিবদ্ধ করার কথা আপনার সত্যই দরকার নেই ।

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

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

Answer 4

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

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

Answer 5

আমি main টি প্রধান বিভাগে আয়োজিত একটি স্থাপত্য নথি লিখতে আগ্রহী হব।

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

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

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

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