Dependency graph هوشمند چه چیزهایی را نمی‌بیند؟

Dependency graph چه چیزی را خوب نشان می‌دهد؟

در معماری نرم‌افزار، graph معمولاً nodeهایی مثل package، library، service، repository، database یا deployment را به edgeهایی مثل import، call، publish، consume یا deploy وصل می‌کند. این مدل برای فهمیدن مسیر تغییر، پیدا کردن coupling، تحلیل impact و شناسایی بعضی ریسک‌های supply chain بسیار مفید است.

مستندات رسمی GitHub، dependency graph را خلاصه‌ای از manifest و lock fileهای repository و داده‌ای می‌داند که از طریق dependency submission API ارسال شده است. این graph می‌تواند package، ecosystem، version، license، فایل manifest و vulnerability شناخته‌شده را نشان دهد و برای dependencyهای transitive مسیر رسیدن را نمایش دهد. این یک قابلیت مهم است؛ اما از تعریف آن هم روشن است که دامنهٔ اصلی‌اش dependencyهای نرم‌افزاری و قابل‌استخراج از artifactهای مشخص است.

پس اگر graph در codebase رابطه‌ای نشان نمی‌دهد، فقط می‌توانیم بگوییم در دادهٔ موجود edgeای پیدا نشده است. نمی‌توانیم نتیجه بگیریم هیچ dependency دیگری در پروژه وجود ندارد. این فرق، پایهٔ استفادهٔ درست از graph و AI است.

• Dependency فنی: package، library، API، service، database و زیرساخت.
• Dependency قابل‌مشاهده: رابطه‌ای که در کد، manifest، lock file، config یا event ثبت شده است.
• Dependency transitive: رابطه‌ای که از مسیر یک dependency دیگر وارد می‌شود.
• Dependency پنهان: رابطه‌ای که برای اجرای outcome لازم است اما در artifact فنی نیامده است.

هفت چیزی که graph معمولاً نمی‌بیند

نقطهٔ کور اول، owner و ظرفیت انسانی است. یک سرویس ممکن است از نظر فنی available باشد اما فقط یک نفر توان تغییر آن را داشته باشد یا آن فرد در تعطیلات، پروژهٔ دیگری یا صف review باشد. edge «A به B وابسته است» زمان انتظار، مهارت و ظرفیت صاحب B را توضیح نمی‌دهد.

نقطهٔ کور دوم، dependency تصمیمی است. ممکن است implementation آماده باشد اما دربارهٔ privacy، pricing، quality bar، scope یا approval هنوز تصمیمی گرفته نشده باشد. این رابطه در code graph ظاهر نمی‌شود، ولی می‌تواند release را بیشتر از یک API down متوقف کند.

نقطهٔ کور سوم، dependency سازمانی و قراردادی است: procurement، دسترسی vendor، approval امنیت، قرارداد SLA، بودجه، دادهٔ مجاز یا هماهنگی تیم دیگر. این‌ها گاهی در ticket یا ایمیل پراکنده‌اند و گاهی فقط در حافظهٔ افراد.

نقطهٔ کور چهارم، dependency معنایی داده است. graph ممکن است جریان schema را نشان دهد، اما نمی‌گوید معنای فیلد تغییر کرده، labelها با تعریف قبلی یکسان نیستند یا خروجی یک تیم برای تصمیم تیم دیگر دیگر قابل‌اعتماد نیست.

نقطهٔ کور پنجم، dependency عملیاتی است: quota، rate limit، latency budget، on-call، مسیر escalation، هزینهٔ inference، backup، data residency و ظرفیت واقعی. سرویس از نظر topology متصل است، اما ممکن است در load واقعی یا هنگام خطا usable نباشد.

نقطهٔ کور ششم، dependency کیفیت و اعتماد است. یک feature ممکن است همهٔ edgeهای فنی را داشته باشد، اما dataset ارزیابی ناکافی، review انسانی نامشخص، failure mode ثبت‌نشده یا تجربهٔ کاربری گیج‌کننده داشته باشد. این‌ها روی outcome اثر دارند، نه لزوماً روی compile یا deployment.

نقطهٔ کور هفتم، dependency تغییر است. graph snapshot می‌تواند وضعیت امروز را نشان دهد، اما نمی‌گوید کدام edge stale است، کدام تصمیم با تغییر مدل شکسته و کدام assumption هنوز validate نشده است. برای پروژهٔ AI این نقطهٔ کور جدی‌تر است، چون مدل و provider و رفتار کاربر می‌توانند سریع‌تر تغییر کنند.

• انسان و ظرفیت review یا تصمیم‌گیری؛
• تصمیم‌های باز و approvalهای لازم؛
• وابستگی بین تیم‌ها، سازمان‌ها و قراردادها؛
• تغییر معنای داده و ownership دانش؛
• ظرفیت، هزینه، quota، SLA و عملیات؛
• کیفیت، evaluation، اعتماد و تجربهٔ کاربر؛
• تازگی edgeها و assumptionهای شکسته.

AI چگونه graph را بهتر و هم‌زمان خطرناک‌تر می‌کند؟

AI می‌تواند چند منبع را کنار هم بگذارد: repository، issue، pull request، runbook، مستندات، تصمیم‌ها و status updateها. سپس می‌تواند nodeهای احتمالی، مسیر impact، edgeهای تکراری، ownerهای محتمل یا سؤال‌های باز را پیشنهاد دهد. این augmentation برای شروع discovery و آماده‌سازی planning ارزشمند است.

اما AI معمولاً رابطهٔ ضمنی را با confidence ظاهری کامل می‌کند. اگر یک تصمیم در گفت‌وگو ثبت نشده باشد، مدل ممکن است owner را از روی آخرین activity حدس بزند. اگر service فقط در شرایطی خاص مصرف می‌شود، مدل ممکن است edge را بیش‌ازحد عمومی یا بیش‌ازحد قطعی نشان دهد. نبودن evidence با نبودن dependency یکی نیست.

قاعدهٔ عملی من این است: هر edge تولیدشده با AI باید source، timestamp، نوع رابطه، confidence و owner تأیید داشته باشد. اگر edge فقط inference است، آن را به‌عنوان hypothesis نمایش دهید و با برچسب «نیازمند تأیید» وارد تصمیم کنید. graph زیبا اما بی‌منبع می‌تواند از نبودن graph خطرناک‌تر باشد، چون به تیم اعتماد کاذب می‌دهد.

• AI graph را از چند منبع بسازد، اما منبع هر edge را نگه دارد.
• رابطهٔ مشاهده‌شده را از رابطهٔ استنباط‌شده جدا کنید.
• confidence و تازگی edge را در کنار خود edge نمایش دهید.
• owner انسانی edgeهای پرریسک را تأیید یا رد کند.
• unknown را به‌عنوان unknown نگه دارید؛ نبود داده را به نبود dependency تبدیل نکنید.

گراف socio-technical برای delivery چه تغییری می‌دهد؟

اگر هدف ما فقط supply chain code است، graph فنی کافی‌تر است. اما اگر می‌خواهیم ریسک delivery یا اثر scope change را بسنجیم، باید graph را socio-technical ببینیم. در این مدل node فقط package نیست؛ می‌تواند تیم، role، تصمیم، داده، policy، vendor، محیط، metric یا stakeholder هم باشد.

edgeها هم باید فقط «depends on» نباشند. رابطه‌هایی مثل owns، approves، waits for، informs، validates، escalates، pays for، is constrained by و is monitored by اطلاعات متفاوتی می‌دهند. این نام‌گذاری به تیم کمک می‌کند بفهمد یک blocker فنی است یا approval، یک dependency واقعی است یا فقط همکاری، و تغییر کدام node احتمالاً چند مسیر را تحت‌تأثیر قرار می‌دهد.

این گراف قرار نیست سازمان را به نمودار پیچیده‌ای از همه‌چیز تبدیل کند. باید با سؤال شروع شود: برای رسیدن به این outcome کدام رابطه اگر قطع شود، چه چیزی متوقف می‌شود؟ تنها nodeها و edgeهایی را ثبت کنیم که به یک تصمیم، ریسک یا اقدام وصل می‌شوند.

• Nodeهای فنی: code، service، data و infrastructure؛
• Nodeهای انسانی: team، owner، reviewer و stakeholder؛
• Nodeهای تصمیمی: policy، approval، assumption و quality bar؛
• Nodeهای عملیاتی: quota، SLA، alert، runbook و fallback؛
• Edgeهای قابل‌اقدام: owner، approval، انتظار، validation، escalation و monitoring.

برای هر dependency چه metadataای لازم است؟

یک graph زمانی به ابزار مدیریت پروژه تبدیل می‌شود که edge قابل‌بررسی و قابل‌اقدام باشد. برای هر dependency حداقل این اطلاعات را نگه دارید: from، to، نوع رابطه، outcome تحت‌تأثیر، owner، منبع evidence، آخرین زمان تأیید، confidence، حالت failure، زمان مورد انتظار پاسخ و action بعدی.

در پروژهٔ AI، metadata مربوط به model، prompt، retrieval، dataset، policy و version هم مهم است. اگر خروجی سرویس A به مدل خاصی وابسته است، باید بدانیم تغییر مدل چه چیزهایی را invalidate می‌کند. اگر یک edge فقط در آزمایش دیده شده، با edge production یکی نیست. اگر owner مشخص نیست، این خودش یک risk node است و باید در backlog قرار بگیرد.

بهتر است برای هر edge یک status ساده داشته باشیم: confirmed، inferred، stale، blocked یا retired. این status کمک می‌کند graph به جای تصویری ثابت، به یک سطح inspectable از وضعیت تبدیل شود.

• نوع و جهت رابطه؛
• owner و تیم پاسخ‌گو؛
• منبع و زمان آخرین تأیید؛
• confidence و وضعیت edge؛
• outcome یا scope تحت‌تأثیر؛
• failure mode و fallback؛
• زمان انتظار، SLA یا معیار بازبینی؛
• version مدل، داده، policy یا artifact مرتبط.

گراف را چطور وارد Agile و برنامه‌ریزی کنیم؟

در Sprint Planning، graph نباید جای Product Goal یا تصمیم Developers را بگیرد. می‌تواند پیش از جلسه مسیرهای impact، blockerهای احتمالی و nodeهای بدون owner را آماده کند. تیم باید بررسی کند کدام dependency برای Sprint Goal حیاتی است و آیا ظرفیت رسیدگی به آن در Sprint وجود دارد.

در Daily Scrum، به‌جای دیدن تمام graph، فقط edgeهایی را inspect کنیم که برنامهٔ امروز را تغییر می‌دهند. یک dependency بدون action فقط اطلاعات است؛ dependencyای که owner، next step و زمان بازبینی دارد، به مدیریت جریان کمک می‌کند. اگر graph هر روز صدها alert بسازد، خودش به ceremony جدید و منبع نویز تبدیل شده است.

در Sprint Review، تغییر environment و outcome می‌تواند edgeهای graph را تغییر دهد. در Retrospective هم بررسی کنیم کدام dependency پیش‌بینی نشده بود، کدام edge stale ماند و کدام assumption تیم را گمراه کرد. این استفاده با منطق Scrum هم‌راستاست: artifactها برای transparency و inspect-and-adapt هستند، نه برای ساختن dashboard تزئینی.

• قبل از Planning: graph را برای مسیرهای مهم و ownerهای نامشخص خلاصه کنید.
• داخل Daily Scrum: فقط dependencyهای اثرگذار بر Sprint Goal را بررسی کنید.
• در Review: تغییر environment و outcome را به graph برگردانید.
• در Retrospective: edgeهای از دست‌رفته، stale و misleading را اصلاح کنید.
• هر alert را به action وصل کنید یا آن را حذف و کم‌اهمیت کنید.

یک خبر مهم برای نگاه حاکمیتی به dependencyها

در صفحهٔ رسمی NIST که در ۱۵ سپتامبر ۲۰۲۶ بررسی کردم، AI Risk Management Framework برای مدیریت ریسک‌های AI نسبت به افراد، سازمان‌ها و جامعه و برای design، development، use و evaluation معرفی شده است. همان صفحه اعلام می‌کند NIST در ۷ آوریل ۲۰۲۶ concept note مربوط به پروفایل Trustworthy AI در Critical Infrastructure را منتشر کرده و AI RMF 1.0 نیز در چارچوب White House AI Action Plan در حال بازبینی است.

این خبر یک نتیجهٔ مستقیم برای graph دارد: وقتی AI وارد زیرساخت یا تصمیم‌های حساس می‌شود، dependency map نباید فقط مسیر سرویس و package را نشان دهد. باید معلوم باشد کدام risk control، owner، policy، provider، محیط و مسیر پاسخ‌گویی به outcome وابسته است. من از این منبع نتیجه نمی‌گیرم که NIST یک schema مشخص برای graph پیشنهاد کرده؛ این برداشت، تحلیل کاربرد framework برای معماری و delivery است.

در پروژه‌های معمولی هم همین منطق برقرار است، اما در AI اهمیت بیشتری دارد چون یک edge اشتباه می‌تواند علاوه بر شکست فنی، ریسک حریم خصوصی، امنیت، تبعیض، تصمیم غلط یا قطع سرویس ایجاد کند.

چطور بفهمیم graph واقعاً مفید شده است؟

تعداد node و edge معیار موفقیت نیست. اگر graph بزرگ‌تر شود اما blocker دیرتر کشف شود، review بیشتر صف شود یا تیم تصمیم‌های اشتباه بگیرد، graph ارزش ایجاد نکرده است. قبل از rollout چند شاخص ساده ثبت کنید: زمان کشف dependency مسدودکننده، درصد edgeهای دارای owner، نرخ edgeهای stale، زمان انتظار برای approval، dependency-related rework و تعداد incidentهایی که graph می‌توانست زودتر هشدار دهد.

همچنین quality graph را با sample review بسنجید. یک مجموعهٔ کوچک از dependencyهای واقعی را با افراد صاحب context مقایسه کنید و false positive، false negative و edgeهای بی‌منبع را ثبت کنید. هدف رسیدن به دقت کامل نیست؛ هدف این است که بدانیم graph در کدام نوع رابطه خوب و در کدام نوع رابطه ضعیف است.

اگر AI می‌گوید یک dependency high-risk است، از آن بپرسید: evidence چیست، چه چیزی را نمی‌دانی و برای تأیید چه اقدامی لازم است؟ این سؤال، graph را از ابزار verdict به ابزار یادگیری تبدیل می‌کند.

• زمان کشف dependency مسدودکننده؛
• درصد edgeهای دارای owner و source؛
• نرخ edgeهای stale یا بی‌مصرف؛
• زمان انتظار approval یا پاسخ تیم دیگر؛
• نرخ rework و incident مرتبط با dependency؛
• false positive و false negative در نمونهٔ بررسی‌شده؛
• نسبت alertهایی که به action واقعی منجر شده‌اند.

الگوی اجرای کوچک برای یک تیم محصول AI

برای شروع، کل سازمان را graph نکنید. یک outcome یا workflow مشخص انتخاب کنید؛ مثلاً تولید پاسخ پشتیبانی، انتشار یک feature AI یا pipeline تحلیل داده. ابتدا nodeهای فنی اصلی را از repository و config بگیرید، سپس با یک جلسهٔ کوتاه nodeهای owner، policy، review، داده و provider را اضافه کنید.

برای هر edge خطرناک source و owner تعیین کنید و فقط edgeهایی را alert کنید که اگر تغییر کنند، Sprint Goal یا production را تحت‌تأثیر قرار می‌دهند. AI می‌تواند هر روز خلاصهٔ تغییرها را آماده کند، اما تیم باید هنگام Daily Scrum یا review دربارهٔ action تصمیم بگیرد.

بعد از یک یا دو چرخه، graph را با incident، waiting time و edgeهای stale بازبینی کنید. اگر نمودار فقط به‌روزرسانی دستی بیشتری ساخته، scope آن را کوچک کنید. اگر یک dependency پنهان زودتر دیده شده و action روشن‌تری ایجاد کرده، همان الگو را به مسیر دیگری تعمیم دهید.

• یک outcome و workflow محدود انتخاب کنید.
• graph فنی را با owner، policy، داده و review تکمیل کنید.
• edgeهای پرریسک را با source، confidence و زمان تأیید ثبت کنید.
• AI را برای خلاصه و کشف gap به‌کار ببرید، نه approval خودکار.
• بعد از چند چرخه، اثر graph را با waiting، rework و incident بسنجید.

چک‌لیست استفاده از Dependency graph هوشمند

• می‌دانیم این graph برای چه outcome و چه تصمیمی ساخته شده است.
• dependency فنی را از dependency انسانی، تصمیمی و سازمانی جدا می‌کنیم.
• هر edge مهم source، timestamp، confidence و owner دارد.
• رابطهٔ inferred را با confirmed قاطی نمی‌کنیم.
• edgeهای stale، blocked و retired وضعیت مشخص دارند.
• مدل نبودن داده را به نبودن dependency تعبیر نمی‌کند.
• policy، privacy، provider، quota، SLA و fallback در use caseهای AI دیده شده‌اند.
• graph فقط alertهایی می‌دهد که به action یا تصمیم وصل‌اند.
• تعداد edge را با زمان کشف blocker، rework و incident می‌سنجیم.
• در Retrospective، dependencyهای از دست‌رفته و assumptionهای غلط را بهبود می‌دهیم.

جمع‌بندی

واقعیت عمومی: GitHub dependency graph برای خلاصه‌کردن dependencyهای موجود در manifest، lock file و دادهٔ submission ساخته شده و اطلاعاتی مانند version، license، مسیر transitive و vulnerability شناخته‌شده را ارائه می‌کند. Scrum Guide هم Product Backlog، Sprint Backlog و فرایند inspect و adapt را بر اساس هدف و شفافیت توضیح می‌دهد. NIST AI RMF دامنهٔ مدیریت ریسک AI را به افراد، سازمان‌ها و جامعه و چرخهٔ design تا evaluation وصل می‌کند.

تحلیل من: هیچ‌کدام از این منابع ادعا نمی‌کنند یک graph خودکار همهٔ dependencyهای delivery را می‌بیند. dependencyهای انسانی، تصمیمی، داده‌ای، عملیاتی و حاکمیتی باید با source، owner، confidence و تاریخ بازبینی مدل شوند. AI برای کشف و نگهداری این نقشه کمک بزرگی است؛ اما inference را نباید به fact تبدیل کنیم.

پیشنهاد حکیم: از یک workflow کوچک شروع کنید، یک graph قابل‌اقدام بسازید و هر edge را به outcome، owner و failure mode وصل کنید. اگر graph به تصمیم بهتر، کشف زودتر blocker و rework کمتر منجر نشد، مشکل را با node و edge بیشتر پنهان نکنید؛ سؤال اصلی را دوباره تعریف کنید.

منابع اولیه برای بررسی

Scrum Guide نسخهٔ HTML برای Sprint Goal، inspect و adapt، impediment، Sprint Backlog و Product Backlog: https://scrumguides.org/scrum-guide.html — بررسی‌شده در 2026-09-15.

مستندات رسمی GitHub دربارهٔ Dependency Graph برای manifest و lock file، dependency submission API، dependencyهای transitive، vulnerability و SBOM: https://docs.github.com/en/code-security/concepts/supply-chain-security/dependency-graph — بررسی‌شده در 2026-09-15.

صفحهٔ رسمی NIST دربارهٔ AI Risk Management Framework، دامنهٔ trustworthiness و خبر concept note مربوط به Critical Infrastructure در ۷ آوریل ۲۰۲۶: https://www.nist.gov/itl/ai-risk-management-framework — بررسی‌شده در 2026-09-15.

مرز شواهد و تحلیل

تعریف dependency graph و قابلیت‌های اعلام‌شدهٔ GitHub، اصول Scrum و وضعیت اعلام‌شدهٔ NIST از منابع اولیهٔ بالا گرفته شده‌اند. این منابع تضمین نمی‌کنند که graph یا AI برای هر repository همهٔ dependencyها را کشف کند. تفکیک هفت نقطهٔ کور، مدل socio-technical، metadata پیشنهادی، معیارهای سنجش و تحلیل اثر AI بر Agile، معماری و مدیریت پروژه دیدگاه امین رضا سیدآبادی است و باید با context و دادهٔ واقعی همان تیم تطبیق داده شود.