نمونه چارچوب زکمن در مثال دانشگاهی

در شکل زیر می توانید نمونه چارچوب زکمن از منظر دانشگاهی را مشاهده و بررسی کنید.

 

مثال چارچوب زکمن در دانشگاه
مثال چارچوب زکمن در دانشگاه

 

دانلود اصل سند با کیفیت بالا زکمن

دید ۱ + ۴ در نگارش سند معماری نرم افزار Software Architecture Document Based on 4 + 1 View Model

این مدل سازماندهی تفصیلی معماری نرم افزار را در پنج دید مجزا ولی با همبستگی توصیف می کند. به جهت اینکه پیدایش هر امری در نتیجه یک فلسفه  بوده است چرایی پیدایش این مدل را بررسی می کنیم ! علت یک چیز است : درمان مشکل دید طراحی و مدل سازی نرم افزار. پنج بعد دیداری این مدل به صورت همروند می باشند . هر یک از ۵ دید به یک گروه از ذینفعان پروژه مربوط می شود.

دید 1 + 4 در معماری نرم افزار
دید ۱ + ۴ در معماری نرم افزار

۱ ) دید منطقی : نحوه نمایش این مدل را می توان در قالب ERD نمایش داد. نیازمندی های وظیفه مندی ، طراح دید انتزاعی دارد و این انتزاع ها در قالب Object بروز میکند. عملیات اصلی در این دید فرآیند Decomposition است که در نتیجه انتزاع و تجرید رخ می دهد.

مهم : تحلیل گر و طراح اینجا هستند و سرویس ها به کاربر نهایی ارائه می شوند.

۲ ) دید فرآیندی : به تفصیل، جنبه های طراحی همروند و قابلیت انطباق نرم افزار را بررسی می کند. نیازمندی های غیر وظیفه مندی مانند دسترسی پذیری سیستم.

مهم : یکپارچه سازی سیستم در اینجا رخ می دهد + قابلیت تحمل خطا + همروندی فرآیندها

۳ ) دید توسعه : نرم افزار در قالب چند زیرسیستم پکیچ می شود به صورتی که بتوان آنرا توسط دیگر توسعه دهندگان توسعه داد. زیر سیستم هم بصورت سلسله مراتبی چند لایه می باشد و هر لایه دارای یک اینترفیس خوش تعریف ۴ می باشد که با لایه بالایی در ارتباط است.

مهم : برنامه نویسان در اینجا حضور دارند و مدیریت نرم افزاری در این دید صورت میگیرد.

۴ ) دید فیزیکی : تحویل و نصب نرم افزار را شاهد هستیم و شروع ارتباط اینجا رخ می دهد. نیازمندی های غیر وظیفه مندی هم در اینجا حاضر هستند مثل مقیاس پذیری .

مهم : مهندسی سیستم اینجا رخ می دهد. کَف و توپولوژی سیستم تعیین می شود.

طرح مدیریت ریسک – Risk Management Plan

ما می توانیم به منظور طرح مدیریت ریسک – Risk Management Plan از طرح RMMM به منظور کاهش ریسک، اجتناب از ریسک و نظارت  و کنترل ریسک استفاده کنیم. در واقع RMMM طرح تسکین پایش و مدیریت ریسک هست که بایستی از قبل آماده باشه. اینو رو هم یادتون باشه ما دو نوع ریسک داریم : الف. غیر فعال ب. فعال

حالا این تحلیل و مدیریت ریسک چه کمکی به تیم میکنه ؟ باعث میشه که تیم در طول پروژه بتونه عدم قطعیت رو درک کنه و اونو مدیریت کنه.

این قطعه کد رو هم نگاه کنیم خالی از لطف نیست (نیست که من قبلنا PHP کد میزدم 🙂 ضمنا این کد در سطح وب موجود است.

<code>

if (Risk is available) then {Risk Managment || Risk Monitoring} Else

{Risk Monitoring}

 

</code>

بطور کلی مدیریت ریسک شامل ۶ مرحله هست :

  • شناسایی ریسک
  • تحلیل ریسک
  • ارزیابی ریسک
  • برنامه ریزی به منظور جلوگیری ریسک
  • طرح مهاجرت از وقایع ریسک
  • کنترل ریسک (مدیریت رخدادهای احتمالی که اگر رخ بده فاجعه به بار میاد و کار بیخ پیدا میکنه )

ضمنا ما ۳ نوع ریسک داریم :

  • ریسک پروژه
  • ریسک محصول
  • ریسک کاری

بطور خلاصه RMMM شامل سه مرحله میشه :

  • کاهش ریسک : مدیر سعی می کند مشکلات بر سر راه پروژه رو برطرف کنه تا ریسک رخ نده و به قولی جلوی بروز ریسک رو بگیره. (Risk Reduction)
  • اجتناب : برای جلوگیری از ریسک اقداماتی رو مطرح میکنه.
  • مدیریت : ریسک اتفاق افتاده و حالا مشخص میکنه باید چه کاری انجام بدیم تا کار بیشتر از این بیخ پیدا نکنه.

اجازه بدید با یک مثال کار رو پیش ببریم : ” در طول پروژه استخراج وضع موجود سازمان جهاد دانشگاهی امکان دارد برخی کارمندان از تیم جدا بشن و به قسمت های دیگه پروژه منتقل بشن ”  خوب این شد بخش پالایش ریسک. حالا باید اجتناب از ریسک داشته باشیم، پس باید چه کار کنیم ؟ مشخصه باید وظایف و تسک های هر کدوم از اعضای تیم رو مشخص کنیم و پروژه ای که قراره بهش نیل پیدا کنیم رو روشن کنیم. حالا اگر ریسک اتفاق افتاد و جدایی رخ داد چی کنیم ؟ باید مدیریت انجام بدیم، اینجاست که Management ورود میکنه و ما میایم نیروهای جدید و ماهر و متخصص رو به جای نیروهای قبلی جایگزین می کنیم. (Replacement) پس جواب یک سوال اینجا مشخص میشه و اون اینکه مدیریت پروژه توسط مدیر پروژه (Project Manager) صورت میگیره.

شناسایی، ارزیابی و کاهش ریسک ها پیش از فاز گذار در معماری غیر قابل اجتناب و ضروری است. ما دو سطح ریسک داریم :

  • ریسک ابتدایی
  • ریسک های باقیمانده پس از انجام اقدامات به منظور کاهش ریسک

طبقه بندی ریسک : 

  • ریسک ها در کلیه فازهای متدولوژی ADM حاضرند.
  • اما چرا ریسک ها را طبقه بندی کنیم ؟ به منظور کاهش ریسک ها طبقه بندی بسیار موثر است.
  • یکی از راه های طبقه بندی ریسک، اندازه گیری تاثیری است که بر سازمان می گذارد.

شناسایی ریسک : 

چطور شناسایی کنیم ؟

  • ارزیابی بلوغ سازمان در فاز گذار
  • ارزیابی آمادگی سازمان در فاز گذار
  • مستند سازی ریسک (Risk Documentation)

ارزیابی های سه گانه فوق بسیاری از ریسک ها را شناسایی می کند. اما ارزیابی ابتدایی ریسک به چه صورتی می باشد ؟

  • طبقه بندی ریسک با توجه به دو عامل :
    • تاثیر ریسک در سازمان
    • فرکانس تکرار در سازمان
  • ارزیابی میزان تاثیر با توحه به معیارها (ستون جدول) و نرخ تکرار (سطر جدول)
  • معیار + نرخ تکرار :
    • ریسک بسیار جدی (Extremely High Risk)
    • ریسک جدی (High Risk)
    • ریسک قابل کنترل (Moderate Risk)
    • ریسک پایین (Low Risk)
  • که به ترتیب با E , H , M , L شناخته می شوند.

رویکرد عمودی و رویکرد افقی در توسعه فناوری اطلاعات سازمان

قبل از بحث و بررسی دو رویکرد عمودی و رویکرد افقی در توسعه فناوری اطلاعات سازمان باید این نکته را ذکر کنیم که معماری سازمانی (Enterprise Architecture) یک رویکرد افقی و مبتنی بر فرآیند است و همین باعث شده است که انعطاف پذیری (Flexibility) در سازمان به حد اعلای خود برسد.

در رویکرد عمودی موارد ذیل لحاظ می شود :

  • سیستم اطلاعاتی بخش از دارای های سازمان است.
  • به خدمت گرفتن فناوری متاثر از تغییرات کسب و کار است اما عکس آن خیر، یعنی استخدام عناصر کسب و کار متاثر از تغییرات فناوری اطلاعات نیست.
  • به جهت عدم وجود یک برنامه ریزی مدوّن برای تولید و توسعه سیستم ها برای هر سیستم اطلاعاتی بصورت مقطعی تصمیم گیری می شود. (نه به صورت جامع و منظم از ابتدای کار)
  • تحلیل نیازمندی ها نیز بر اساس فرآیندهای سازمانی نیست بلکه بر اساس وظایف واحدهای مشتری است و همین مساله باعث تکه تکه شدن سیستم خواهد شد. (Fragmentation)

اما رویکرد عمودی دچار مشکلاتی نیز هست که با هم بررسی می کنیم :

  • افزونگی اطلاعات (مشکل حیاتی)
  • ذینفعان و کارمندان و مشتریان از سیستم های اطلاعاتی ایجاد شده راضی نیستند.
  • ایجاد سیستم های اطلاعاتی اما بصورت تکه تکه ای (جزیره ای)
  • عدم انعطاف پذیری در برابر تغییرات (No Flexibility toward Changes)
    • چرا که کسب و کار از محدویت های فناوری اطلاعات تاثیر می پذیرد.
  • افزایش هزینه نگهداری سیستم ها (Cost Increase)
  • افزایش زمان نگهداری سیستم ها (Time Increase)
  • عدم وجود قدرت برای برقراری رقابت به دلیل وجود سیستم های اطلاعاتی منفرد بدون قابلیت تعامل با هم (Lack of Interaction)

در رویکرد افقی موارد ذیل لحاظ می شود :

  • تولید و توسعه فناوری اطلاعات بر اساس برنامه ای جامع و مدون می بایست صورت گیرد.
  • سازمان برای به خدمت گرفتن فناوری اطلاعات باید راهبردهای مشخص در تطبیق با راهبردهای سازمانی داشته باشد.
  • تاثیر تغییر فناوری بر کسب و کار و کسب و کار بر فناوری می بایست از قبل پیش بینی شده باشد. (Predict)
  • سیستم های اطلاعاتی (Information Systems) باید در حمایت و پشتیبانی از فرآیند های کسب و کار (Business Process) ایجاد شوند و نه حمایت از وظایف واحدهای سازمانی

اما روش های توسعه افقی در سازمان جیست ؟ 

  • روش های مهندسی نرم افزار : این روش های در تولید و توسعه نرم افزار استفاده می شوند. بعنوان مثال استفاده از متدولوژی RUP یا XP به منظور ساخت نرم افزار
  • برنامه جامع فناوری اطلاعات به منظور تولید و نگهداری و پشتیبانی سیستم های اطلاعاتی که مبتنی بر راهبردها و ماموریت سازمان است و شامل عناصر ذیل است :
    • طرح جامع ارتباطات سیستم ها
    • فهرست سیستم ها و ساب سیستم ها
    • فهرست پروژه ها و RFP ها
    • برنامه اولویت زمان بندی اجرای پروژه ها
  • و معماری سازمانی

مدل ۵ لایه ای NIST

این مدل معماری از ۵ لایه تشکیل شده که اجزی مختلف معماری سازمان رو نمایش میده.

  • لایه معماری کسب و کار
  • لایه معماری اطلاعاتی
  • لایه معماری سیستم های اطلاعاتی
  • لایه معماری دیتا
  • لایه معماری فناوری (سخت افزاری نرم افزاری و ارتباطاتی)

NIST یه ابزار مدیریتی هست که ارتباطات درونی محیط کسب و کار، اطلاعات و فناوری سازمان رو نمایش میده. در هرم NIST هر لایه در خدمت لایه بالاتر هست و ملزومات لایه پایینی خودش رو تعیین می کند.

NIST
NIST

لایه معماری کسب و کار :  فرآیند های کسب و کار بنیادین سازمان رو توصیف می کند که از ماموریت ها و چشم اندازهای سازمانی حمایت می کنند. این لایه تحلیلی سطح بالا از فعالیت های سازمان برای حمایت از ماموریت ها اهداف و چشم انداز سازمان ارایه می کند. این لایه اساسی ترین و پایه ای ترین لایه معماری سازمان هست چونکه به ندرت بر اساس تحولات اجتماعی امکان تغییر دارن. این معماری توسط مدیریت ارشد سازمان تعیین میشه.

لایه معماری کاری دو تا نقشه داره :

  • نقشه وضع موجود سازمان
  • نقشه وضع مطلوب سازمان

لایه معماری کسب و کار شامل مستندات جامعی از موارد ذیل هست :

  • ساختار سازمان
  • ماموریت های سازمان
  • اهداف کاری سازمان
  • وظایف کاری سازمان
  • فرآیندهای سازمان
  • فعالیت های سازمان
  •  اطلاعات سازمان

که مرنباط با نیازهای فعلی و آتی سازمان هست و در نقشه های بالا (وضع موجود سازمان و وضع مطلوب سازمان) تهیه میشه. این معماری مرکز شبکه اطلاعاتی سازمان محسوب میشه و دیگر لایه های معماری سازمان رو هدایت و توانمند (Enable) می کنه.

لایه معماری اطلاعات : این لایه اطلاعات مورد استفاده بوسیله سازمان در فرآیندهای کسب و کار رو تحلیل و آنالیز میکنه. در این لایه اطلاعات و نحوه گردش اطلاعات در سازمان تعیین و مشخص میشه. علاوه بر این ارتباط میان جریان های مختلف اطلاعاتی در همین مولفه توصیف و تشریح میشه. موحودیت های اطلاعاتی در این لایه از نوع موجودیت های سازمانی هستند و نه موحودیت های منطقی و یا فیزیکی.

این لایه به این سوالات پاسخ می دهد :

  • چه اطلاعاتی در سازمان تولید می شود ؟
  • چه کسانی به این اطلاعات Access دارند ؟
  • چگونه این اطلاعات برای تصمیم گیری و انجام برنامه ها و فعالیت های کاری روزمره استفاده میشه ؟

چه افرادی در این لایه درگیر هستند ؟

  • مدیریت ارشد
  • مدیریت میانی (مدیران میانی)
  • همه تصمیم گیرندگان سازمانی

لایه معماری سیستم های اطلاعاتی (برنامه های اطلاعاتی) : در واقع تو این لایه دیتای ما به اطلاعات تبدیل میشه و دریافت، تغییر و مدیریت اطلاعات کسب و کار سازماندهی میشه و با برخی دیاگرام ها نحوه استقرار Component ها مشخص میشه.

لایه دیتا : این لایه مشخص میکنه که دیتاهای سازمانی چطور باید نگهداری بشن چطور بهشون Access داشته باشیم و چطور مورد استفاده قرار بگیرن. در واقع محتوا ، شماتیک پایگاه داده های سازمانی رو مشخص میکنه و الگوی ذخیره سازی دیتا توی سیستم رو تعیین میکنه. همینطور میاد مشخص میکنه که دیتاها و ارتباطات بین دیتاها تو سیستم اطلاعاتی به چه شکل هست. مساله دیگه اینکه تغییر و تحول تو این لایه بیشتر از لایه اطلاعات هست.

لایه فیزیکی (فناوری) :  پایین ترین لایه معماری سازمان هستش که به توصیف زیرساخت های سطح بالا برای حال و آینده سازمان می پردازه که شامل موارد ذیل میشه :

  • سخت افزار سیستمی
  • نرم افزار سیستمی
  • شبکه
  • فناوری اطلاعات
  • پایگاه های داده

برای دریافت اطلاعات بیشتر به این مقاله خوب از مهندس حمید صاحب خرد مراجعه کنید.

این مقاله هم برای کسب اطلاعات بیشتر مناسب هست که در هسته پژوهشی سیستم های اطلاعاتی منتشر شده است.

 

چارچوب ارزیابی OMB

چارچوب ارزیابی OMB ابتدا به منظور پایه گذاری وضعیت معماری سازمانی در فدرال آمریکا طراحی شد. رسالت و هدف بنیادین چارچوب ارزیابی OMB کمک به سازمانها در جهت فهم هرچه بهتر وضعیت موجود و معماری فعلی سازمان است. در واقع مباحثه و گفتگو با سازمانها را در جهت یکپارچگی و بهبود مداوم فرآیندهای تصمیم گیریشان را دنبال می کند. در واقع OMB یک برنامه ریزی استراتژیک و مکانیزم کنترلی است که از هم ترازی فعالیت های کسب و کار سازمان با اهداف و ماموریت سازمان اطمینان حاصل می کند)

چارچوب OMB چهار  شاخص دارد گه با هم بررسی می کنیم :

  • تغییر (میزان بهینه بودن مدیریت تغییرات سازمان)
  • یکپارچگی (ضمانت استاندارد بودن اینترفیس ها، عملیات درونی، اطلاعات و پیوستگی ایجاد شده توسط معماری سازمانی)
  • هم گرایی (میزان یکپارچگی فناوری اطلاعات بصورتی که در مدل مرجع فنی Technical Reference Model – TRM) تعریف شده است.
  • همراستایی کسب و کار (میزان همسویی و هم ترازی کسب و کار سازمان با ماموریت و و اهداف راهبردی سازمانی)

ضمنا ۶ سطح بلوغ را طی می کند که با هم دنبال می کنیم : (سطح ها از ۰ شروع می شوند یعنی سطح ۰ تا سطح ۵)

  • سطح صفر : هیچ فرآیند آی تی موجود نیست این یعنی هیچ مدرکی دال بر حضور معماری سازمانی نداریم.
    • (No EA Evidence : it’s Such a Disaster, isn’t it ?)
  • سطح یک : فرآیندهای آی تی ابتدایی هستند و حالت مقدماتی دارند.
    • (It process are in Pre-Intermediate Range)
  • سطح دو : از بهترین تجربیات استفاده می کنیم (Best Practice) این یعنی فرآیندهای آی تی رسمی هستند و تکراری
    • (IT Process are Formal and Iterative)
  • سطح سه : عملیاتی شدن معماری سازمانی در سازمان شروع شده است.
    • (It’s Just the Begin Phase, Seat and See What do We Got)
  • سطح چهار : عملیاتی شدن معماری سازمانی در سازمان را شاهد هستیم، این یعنی فرآیندهای آی تی مدیریت شده اند.
    • (We Did it, Didn’t we, just see the result)
  • سطح پنچ : برنامه ریزی فناوری اطلاعات یعنی ITSP در سازمان بهینه شده است.
    • (Improvement is Tangible, just take it and free your self)

اما بلوغ معماری سازمانی چه مواردی را در بر می گیرد ؟

  • توسعه محصولات معماری سازمانی EA Product Development
  • توانایی برنامه معماری سازمانی در فراهم نمودن پیشنهادهای سرمایه گذاری مشخص به عنوان بخشی از فرآیند برنامه ریزی مالی
  • کنترل سرمایه گذاری (Investment Control)

چارچوب توگف – TOGAF

توگف در واقع روشی برای طراحی و رسیدن به حالت مطلوب سازمان هست و شامل مجموعه ای از استانداردها هست که با همراهی مجموعه ای از ابزارها و سازه بلوک ها با تکیه بر واژگانی مشترک سعی در این مهم دارد. در توگف راهبردهای کسب و کار به عنوان ورودی فاز دیدگاه معماری در نظر گرفته شده است و دارای معماری بنیادین در قالب مدل مرجع فناوری (Technical Reference Model) هست و دارای یک متدولوژی عملی پیاده سازی به نام ADM هست که در واقع قلب تپنده این چارچوب هست.

نسخه جدید توگف در ۲۰۰۹ با پشتیبانی کامل از Service Orientation ارائه شد و این تحولی بزرگ و مزیتی رقابتی برای این چارچوب شمرده می شود. از جمله مفاهیم اصلی در توگف پیوستار سازمان، مخزن معماری و قابلیت معماری هست که بعدا مفصل باید بحث بشن.

توگف شامل ۴ دیدگاه هست :

  • معماری کسب و کار : راهبردی های کسب وکار، حاکمیت، سازماندهی، فرآیندهای مهم کسب و کار
  • معماری برنامه های کاربردی :
  • معماری دیتا : ساختار منطقی وفیزیکی دارایی های دیتا، مدیریت دیتا
  • معماری تکنولوژی : قابلیت های سخت افزاری و نرم افزاری (شبکه و …)

ضرورت معماری سازمانی

در باب ضرورت معماری سازمانی سخن بسیار است. اینکه در صورت فقدان معماری سازمانی چه مشکلاتی برایمان پدیدار می شود را در گزینه های ذیل به سرعت وارسی می کنیم :

  • از وجود یک استراتژی بلند مدت محروم می شویم
  • از وجود یک Technical map محروم می شویم
  • به نیازمندی های پروژه بی توجهی می کنیم
  • زمان زیادی صرف پیاده سازی پروژه خواهد شد که از خوصله خارج است
  • هزینه زیادی صرف پروژه خواهد شد که مقرون به صرفه نخواهد بود
  • نسل های مختلفی از استایل ها و سیستم ها در پروژه حضور خواهند داشت
    • البته این مورد گاها مزیت محسوب می شود و از ان بعنوان جامعیت یاد می شود Comprehensive
  • عدم قابلیت توسعه پروژه در فازهای مختلف Lack of development

اما چه جاهایی معماری ضرورت دارد ؟

  • زمان که پروژه ما دارای ابعاد گسترده ای باشد
  • زمانی که دچار High Complexity در پروژه باشیم
  • زمانی که نیازمندی های غیر معمول (استثنایی) در پروژه داشته باشیم.
  • زمانی که پروژه طول عمر داشته باشد و برای مدت طولانی استقرار داشته باشد.
  • زمانی که بخواهیم در برابر تغییرات پروژه Flexibility داشته باشیم و از خشکی خارج شویم.

مهمترین دلایل حضور فرآیند معماری سازمانی را می توان موارد ذیل بر شمرد :

  • ایجاد دیدگاهی تازه و سر زنده نسبت به IT در ارگان ها
  • پیشرفت تکنولوژی و نیاز ارگان ها به زنده ماندن در عصر اطلاعات با سیستم های پویا
  • E-Government

اما چه کسی این فرآیند مهم را مستقیما رهبری خواهد کرد ؟

Chief Information Officer یا همان بقول خودمانی CIO

ایده نگارش مطالب کلیدی فوق برگرفته از اسلایدهای کلاسی درس معماری سازمانی دکتر فریدون شمس (پدر معماری سازمانی ایران) در دانشکده مهندسی کامپیوتر دانشگاه شهید بهشتی است.

چارچوب C4ISR

چارچوب C4ISR بصورت کاملا مستقل از چارچوب زکمن در ابتدای کار در وزارت دفاع آمریکا برای معماری سیستم های اطلاعاتی نظامی تهیه شد بود اما پس از مدتی در دیگر عرصه های معماری سامانه های اطلاعاتی خود را مطرح کرد.

چارچوب مبتنی بر سه دیدگاه :

  • دیدگاه عملیاتی : برطرف کننده نیازهای اطلاعاتی و ارتباطی است.
  • دیدگاه سیستمی : امکانات و خصوصیات را با نیازهای عملیاتی مرتبط می سازد.
  • دیدگاه تکنیکی : بیان کننده استانداردها و قوانین است.

در ادامه این چارچوب به DoDAF تغییر پیدا کرد و در پایان قابلیت پشتیبانی از سرویس گرایی به آن افزوده شد.

البته باید گفت C4ISR بر مبنای DoD بوده با رویکرد System Engineering و پیاده سازی خوبی از DoD بوده است.

عمده تفاوت چارچوب زکمن با C4ISR در این بوده است که در زکمن فرآیند انجام عمل را در دستور کار خود ندارد بر خلاف C4ISR که تمرکز بر انجام کار دارد.

محصولات C4ISR به دو بخش تقسیم می شوند :

  • ضروری
    • برای ارایه معماری فاینال به مدیران پروژه ارایه می شود. آنهایی که به حسب احتمال اطلاعات فنی زیادی ندارند.
  • پشتیبان

این چارچوب دارای ۶ رهنمون است که با هم آنها را می بینیم :

  • محصولات ضروری حتما می بایست موجود باشند.
  • محصولات پشیتبان استاندارد زمانی استفاده شوند که حکم کمکی را داشته باشند یا مورد نیاز باشند.
  • از واژگان و اصطلاحات عامه استفاده کنید
  • روابط International و Shared را بصورت Standard توضیح دهید.
  • نیازمندی های تعامل پذیر را بصورت Standard توضیح دهید.
چارچوب DoD C4ISR
چارچوب DoD C4ISR
شمایتک DoDAF نسخه 1.5
شمایتک DoDAF نسخه ۱٫۵
شماتیک DoDAF نسخه 2
شماتیک DoDAF نسخه ۲

برای دریافت اطلاعات بیشتر به این صفحه نگاهی بیاندازید.