راهنمای پلتفرم یکپارچه Visual Paradigm
شکل، پلتفرم یکپارچه Visual Paradigm را به عنوان یک محیط یکپارچه برای مدیریت چرخه حیات کامل نرمافزار و تحلیل کسبوکار معرفی میکند؛ از نیاز اولیه کسبوکار تا الزامات، مدلسازی، طراحی، پیادهسازی و مستندسازی.
به جای استفاده از ابزارهای جداگانه برای هر فعالیت، این پلتفرم اطلاعات پروژه را در یک فضای کاری مشترک به هم پیوند میدهد. این امر برای تحلیلگران، طراحان، توسعهدهندگان، معماران، مدیران پروژه و ذینفعان کار را آسانتر میکند تا از یک منبع اطلاعاتی واحد کار کنند.

۱. درک مفهوم پلتفرم یکپارچه
یک پلتفرم یکپارچهمواد مرتبط پروژه را در یک محیط متصل به هم گرد هم میآورد. این مواد ممکن است شامل موارد زیر باشند:
-
اهداف و نیازهای کسبوکار
-
الزامات
-
موارد استفاده و داستانهای کاربر
-
مدلهای بصری UML و سایر مدلها
-
نمودارهای فرآیند
-
طرحهای پایگاه داده
-
طرحهای رابط کاربری
-
نقشههای کد منبع
-
مستندات پروژه
-
گزارشها و مشخصات فنی
ایده مهم تنها در این نیست که همه این ابزارها در یک برنامه در دسترس هستند. سودمندی بزرگتر این است که مواد میتوانند به یکدیگر مرتبط باشند.
برای مثال:
یک هدف کسبوکار میتواند به یک الزام، الزام به یک مورد استفاده، مورد استفاده به یک مدل طراحی، و مدل طراحی به مستندات پیادهسازی متصل شود.
این امر ساختاری منسجمتر برای پروژه ایجاد کرده و خطر از دست رفتن اطلاعات را در طول پیشرفت پروژه کاهش میدهد.
۲. پیروی از چرخه حیات کامل پروژه
شکل، چرخه حیقی را نشان میدهد که از شش مرحله متصل تشکیل شده است:
-
نیاز کسبوکار
-
الزامات
-
مدلها
-
طراحی
-
پیادهسازی
-
مستندسازی
این مراحل نباید به عنوان فازهای جداگانه در نظر گرفته شوند. اطلاعات باید بهطور مداوم بین آنها جریان داشته باشد.
مرحله ۱: نیاز کسبوکار
با مستندسازی مسئله، فرصت یا هدف کسبوکار آغاز کنید.
شامل موارد زیر است:
-
کاهش زمان پردازش دستی
-
بهبود خدمات خودخدمتدهی به مشتریان
-
جایگزینی یک سیستم منسوخ
-
پشتیبانی از یک فرآیند کسبوکار جدید
-
برآورده کردن الزامات قانونی یا عملیاتی
در این مرحله، بر نتیجه مطلوب کسبوکار تمرکز کنید، نه بر پیادهسازی فنی.
خروجیهای مفید ممکن است شامل موارد زیر باشند:
-
اهداف کسبوکار
-
بیانیههای مسئله
-
توصیف ذینفعان
-
اهداف کسبوکار
-
نقشههای توانمندی
-
نمودارهای فرآیند در سطح بالا
-
تعریف محدوده
یک نیاز کسبوکار واضح کمک میکند تا الزامات بعدی و تصمیمات فنی همواره با دلیلی که پروژه وجود دارد، همسو باقی بمانند.
مرحله ۲: الزامات
نیازهای کسبوکار را به الزامات مشخص و قابل آزمون ترجمه کنید.
الزامات ممکن است توصیفکننده موارد زیر باشند:
-
کارهایی که کاربران باید انجام دهند
-
کارهایی که سیستم باید انجام دهد
-
قوانین کسبوکار
-
الزامات دادهای
-
انتظارات عملکردی
-
محدودیتهای امنیتی
-
تعهدات قانونی
-
نیازهای یکپارچهسازی
مستندات رایج نیازمندیها شامل موارد زیر هستند:
-
داستانهای کاربر
-
مورد استفاده
-
نیازمندیهای عملکردی
-
نیازمندیهای غیرعملکردی
-
معیارهای پذیرش
-
سلسلهمراتب نیازمندیها
-
پیوندهای ردیابی
هر نیازمندی باید در حالت ایدهآل دارای رابطهای شفاف با یک یا چند هدف کسبوکار باشد. این امر تعیین اینکه آیا پروژه ارزش کسبوکار معناداری را ارائه میدهد یا خیر را آسانتر میکند.
مرحله ۳: مدلها
مدلها نمایهای بصری از سیستم، سازمان، دادهها یا فرآیندها را ارائه میدهند.
بسته به پروژه، مدلها ممکن است شامل موارد زیر باشند:
-
نمودارهای مورد استفاده
-
نمودارهای فعالیت
-
نمودارهای کلاس
-
نمودارهای توالی
-
نمودارهای ماشین حالت
-
مدلهای فرآیند کسبوکار
-
نمودارهای موجودیت-رابطه
-
نمودارهای معماری
-
نمودارهای جریان داده
-
نقشههای سفر مشتری
مدلها به تیمها کمک میکنند تا پیچیدگی را آسانتر از متن به تنهایی درک کنند. آنها همچنین یک زبان مشترک برای ذینفعان فنی و غیرفنی فراهم میکنند.
برای مثال:
-
یک ذینفع کسبوکار ممکن است یک مدل فرآیند را درک کند.
-
یک توسعهدهنده ممکن است از روی یک نمودار کلاس یا نمودار توالی کار کند.
-
یک طراح پایگاه داده ممکن است از یک مدل موجودیت-رابطه استفاده کند.
-
یک معمار ممکن است از نمودار استقرار یا نمودار مؤلفه استفاده کند.
پلتفرم یکپارچه اجازه میدهد این دیدگاههای مختلف به عنوان بخشهایی از همان پروژه نگهداری شوند.
مرحله ۴: طراحی
طراحی، الزامات و مدلها را به ساختار راهحلی دقیقتر تبدیل میکند.
فعالیتهای طراحی ممکن است شامل موارد زیر باشند:
-
معماری سیستم
-
مؤلفههای برنامه
-
طرحهای پایگاه داده
-
رابطهای کاربری
-
APIها و یکپارچهسازیها
-
محیطهای استقرار
-
معماری امنیت
-
مرزهای سرویس
-
رویههای دقیق
یک طراحی قوی باید قابل ردیابی تا الزاماتی باشد که برآورده میکند. اگر یک عنصر طراحی را نمیتوان به یک الزام متصل کرد، تیم باید تعیین کند که آیا آن الزام ضروری است، در الزامات گم شده است، یا خارج از محدوده است.
مرحله ۵: پیادهسازی
پیادهسازی جایی است که طراحی به نرمافزار قابل اجرا، فرآیندهای پیکربندیشده، ساختارهای پایگاه داده یا سایر تحویلها ترجمه میشود.
پلتفرم میتواند از طریق روابط بین موارد زیر، پل ارتباطی بین طراحی و پیادهسازی ایجاد کند:
-
مدلها و کد منبع
-
طرحهای پایگاه داده و اسکریپتهای پایگاه داده
-
الزامات و وظایف توسعه
-
مؤلفهها و سرویسها
-
APIها و جزئیات پیادهسازی
-
نمودارها و مستندات فنی
این ارتباط به کاهش شکاف بین آنچه طراحی شده و آنچه واقعاً ساخته شده است، کمک میکند.
مرحله ۶: مستندسازی
مستندسازی دانش مهم پروژه را در قالبی ثبت میکند که قابل اشتراکگذاری، بازبینی، نگهداری و استفاده مجدد باشد.
مستندات احتمالی شامل موارد زیر هستند:
-
مشخصات الزامات
-
توصیفهای طراحی نرمافزار
-
مستندات معماری
-
راهنمای کاربران
-
مستندات API
-
مشخصات آزمون
-
گزارشهای پروژه
-
سوابق انطباق
-
رویههای عملیاتی
وقتی مستندات از طریق ابزارهای متصل و با استفاده از آثار پروژه تولید یا گردآوری میشوند، احتمال ناسازگاری آنها با مدلها و الزامات پایه کمتر است.
۳. فایده اول: استفاده از محیط کار متصل پروژه
اولین فایده در شکل، یکمحیط کار متصل پروژه.
یک محیط کار متصل امکان مدیریت اطلاعات پروژه را در یک محیط واحد فراهم میکند، به جای پراکنده شدن آن در ابزارها، فایلها و مخازن نامرتبط.
چرا این موضوع مهم است
ابزارهای غیرمتصل اغلب مشکلاتی از جمله ایجاد میکنند:
-
چندین نسخه از یک الزام
-
نمودارهایی که دیگر با پیادهسازی مطابقت ندارند
-
ورود دادههای تکراری
-
عدم وجود پیوندها بین آثار کسبوکار و فنی
-
مشکل در یافتن آخرین اطلاعات پروژه
-
تناقض در اصطلاحات
-
تلاش دستی هنگام تهیه گزارشها
یک محیط کار متصل، یافتن و نگهداری اطلاعات پروژه را آسانتر میکند.
روش توصیهشده
یک ساختار پروژه یکپارچه ایجاد کنید که شامل بخشهای زیر باشد:
-
تحلیل کسبوکار
-
الزامات
-
مدلها
-
معماری و طراحی
-
دادهها
-
ارجاعهای پیادهسازی
-
مستندات
-
بازبینیها و تأییدیهها
از قراردادهای نامگذاری مشترک استفاده کنید و آثار مرتبط را به هم پیوند دهید، به جای کپی کردن همان اطلاعات در مکانهای متعدد.
۴. مزیت دوم: دسترسی سریعتر به ابزار مناسب
مزیت دوم، دسترسی سریعتر به ابزار مناسب برای هر وظیفه است.
یک پروژه ممکن است به انواع مختلفی از کارها نیاز داشته باشد، از جمله:
-
مدیریت الزامات
-
مدلسازی فرآیند
-
مدلسازی UML
-
طراحی پایگاه داده
-
پروتوتایپسازی رابط کاربری
-
مدلسازی معماری
-
برنامهریزی چابک
-
تولید مستندات
-
مهندسی کد یا پایگاه داده
وقتی این قابلیتها از یک محیط یکپارچه در دسترس باشند، اعضای تیم زمان کمتری را صرف جابجایی بین برنامهها یا بازسازی اطلاعات به فرمت دیگری میکنند.
اثر عملی
یک تحلیلگر کسبوکار میتواند از یک مدل فرآیند به الزامات مرتبط آن برود. یک معمار میتواند از یک الزام به طراحی سیستم مربوطه برود. یک توسعهدهنده میتواند مدل و مستندات فنی مرتبط را بدون جستجو در پوشههای نامرتبط بررسی کند.
هدف، در دسترس قرار دادن اثر بعدی مرتبط در زمینه است.
5. مزیت سه: بهبود ردیابیپذیری
ردیابیپذیری است توانایی توانایی برای پیگیری مورد روابط بین پروژه محصولات در طول مورد توسعه چرخه حیات. این کمک میکند تیمها درک کنند چگونه نیازهای کسبوکار نیازهای کسبوکار به تبدیل میشوند به نیازمندیها، طرحها، پیادهسازیها، و نتایج مستند نتایج.
یک معمولی ردیابی زنجیره ممکن است به نظر برسد مانند این:
نیاز کسبوکار→نیازمندی→مورد استفاده→عنصر طراحی→پیادهسازی→مستندسازی
ردیابی میتواند همچنین گسترش یابد به آزمون:
نیازمندی→معیار پذیرش→مورد آزمون→نتیجه آزمون
این متصل ساختار کمک میکند تیمها:
- درک کردن مورد خاستگاه و هدف هر هر طراحی تصمیم
- شناسایی کردن کدام سیستم عناصر هستند تأثیر میگیرند وقتی نیازمندیها تغییر میکنند
- تأیید کردن که هر نیازمندی دارد شده است اجرا شده
- بررسی کنید که نیازمندیها هستند پوشش داده شدهاند توسط پذیرش معیارها و آزمون مورد
- کاهش دهید تکراری یا ناهماهنگ پروژه اطلاعات
- پشتیبانی کنید بازرسیها، بازبینیها، نگهداری، و تأثیر تحلیل
با پلتفرم بصری پارادایم یکپارچه پلتفرم، تیمها میتوانند ارتباط برقرار کنند نیازمندیها، مدلها، طرحها، پیادهسازی محصولات، آزمونها، و مستندات در یک بیشتر ساختاریافته و شفاف فرآیند کار.
چرا ردیابی مهم است
ردیابی به پاسخگویی به پرسشهایی از این دست کمک میکند:
-
این ویژگی از کدام هدف کسبوکار پشتیبانی میکند؟
-
کدام نیازمندیها تحت تأثیر یک تغییر پیشنهادی قرار میگیرند؟
-
آیا هر نیازمندی طراحی و پیادهسازی شده است؟
-
کدام اجزا به این نیازمندی وابسته هستند؟
-
کدام مستندات نیاز به بهروزرسانی دارند؟
-
چه شواهدی از انطباق پشتیبانی میکنند؟
-
چه آزمونهایی تأیید میکنند که الزام برآورده شده است؟
تحلیل تأثیر تغییر
فرض کنید یک الزام تغییر کند. با روابط متصل، تیم میتواند مواردی را که احتمالاً تحت تأثیر قرار گرفتهاند، شناسایی کند:
-
مورد استفاده
-
نمودارهای فرآیند
-
مدلهای داده
-
طراحیهای رابط
-
اجزای معماری
-
وظایف پیادهسازی
-
موارد آزمون
-
مستندات
این روش بسیار ایمنتر از تکیه بر حافظه یا جستجوی دستی در فایلهای پروژه است.
۶. فایده چهارم: بهبود ارتباطات
فایده چهارم، بهبود ارتباطات بین شرکتکنندگان در پروژه است.
ذینفعان مختلف، روشهای متفاوتی را برای درک اطلاعات ترجیح میدهند. یک پلتفرم یکپارچه از نمایشهای چندگانه همان پروژه پشتیبانی میکند، از جمله:
-
الزامات به زبان ساده
-
نمودارهای بصری
-
جدولها و ماتریسها
-
نمونههای اولیه
-
نمای معماری
-
جریانهای فرآیند
-
گزارشهای تولیدشده
ارتباط با ذینفعان کسبوکار
ذینفعان کسبوکار ممکن است نیازی به مشاهده کد منبع یا مدلهای فنی دقیق نداشته باشند. آنها ممکن است از موارد زیر سود بیشتری ببرند:
-
اهداف
-
نمودارهای فرآیند
-
سفر کاربر
-
مورد استفاده
-
نمونههای اولیه
-
قوانین کسبوکار
-
گزارشهای خلاصه
ارتباط با تیمهای فنی
توسعهدهندگان، معماران و متخصصان پایگاه داده ممکن است نیاز داشته باشند:
-
نیازمندیهای دقیق
-
نمودارهای کلاس
-
نمودارهای توالی
-
نمودارهای مؤلفه
-
مدلهای داده
-
تعاریف API
-
نمای استقرار
-
نقشههای پیادهسازی
همین پروژه متصل میتواند از هر دو مخاطب پشتیبانی کند بدون اینکه تیم مجبور باشد اطلاعات را بهصورت دستی بازآفرینی کند.
روشهای توصیهشده ارتباطی
-
از نمودارها برای توضیح روابط پیچیده استفاده کنید.
-
در سراسر پروژه از اصطلاحات یکسان استفاده کنید.
-
مدلها را با مشارکتکنندگان فنی و کسبوکار بازبینی کنید.
-
تصمیمات را به نیازمندیها یا مشکلاتی که به آنها میپردازند پیوند دهید.
-
در موارد مناسب، مستندات ویژه مخاطب تولید کنید.
-
با تغییرات پروژه، نمودارها را بهروز نگه دارید.
۷. فایده پنجم: تقویت همکاری
فایده پنجم، همکاری قویتر بین تیمهای کسبوکار و فنی است.
پروژهها اغلب زمانی شکست میخورند که انتظارات کسبوکار و پیادهسازی فنی بهصورت جداگانه پیشرفت کنند. یک پلتفرم یکپارچه هر دو گروه را ترغیب میکند تا با اطلاعات مرتبط کار کنند.
همکاری در سراسر نقشها
یک پروژه معمولی ممکن است شامل موارد زیر باشد:
-
تحلیلگران کسبوکار
-
مالکان محصول
-
مدیران پروژه
-
متخصصان موضوعی
-
طراحان تجربه کاربری
-
معماران راهحل
-
توسعهدهندگان نرمافزار
-
طراحان پایگاه داده
-
مهندسان تست
-
نویسندگان فنی
-
تیمهای عملیات
هر نقش دیدگاهی متفاوت ارائه میدهد. ارتباط دادن کارهای آنها به تیم کمک میکند تا درک مشترکی از راهحل پیدا کند.
چرخه بازبینی مشارکتی
یک چرخه همکاری عملی عبارت است از:
-
هدف کسبوکار را ثبت کنید.
-
نیازمندیها را تعریف و بازبینی کنید.
-
فرآیندها و رفتارهای مرتبط را مدلسازی کنید.
-
راهحل پیشنهادی را طراحی کنید.
-
طراحی را با ذینفعان بازبینی کنید.
-
راهحل تأییدشده را پیادهسازی کنید.
-
مدلها و مستندات را بهروزرسانی کنید.
-
تأیید کنید که نتیجه تحویلشده نیاز اولیه را برآورده میکند.
این چرخه احتمال اینکه تصمیمات مهم در جلسات، ایمیلها یا اسناد فردی منزوی بمانند را کاهش میدهد.
۸. فایده ششم: پل زدن بین طراحی و پیادهسازی
فایده ششم، پل زدن شکاف بین طراحی و پیادهسازی است.
یک مشکل رایج در پروژههای نرمافزاری این است که مستندات طراحی در اوایل ایجاد میشوند، اما هنگام تغییر سیستم بهروزرسانی نمیشوند. با گذشت زمان، مستندات از پیادهسازی واقعی جدا میشوند.
یک پل بین طراحی و پیادهسازی به تیمها کمک میکند تا از مدلها بهعنوان داراییهای مهندسی عملیاتی بهجای نمودارهای صرفاً تزئینی استفاده کنند.
نمونههایی از ارتباطات طراحی به پیادهسازی
-
یک مدل داده میتواند تولید پایگاه داده را پشتیبانی کند.
-
یک مدل کلاس میتواند پیادهسازی شیگرا را هدایت کند.
-
یک مدل سرویس میتواند مرزهای API را شفاف کند.
-
یک نمودار مؤلفه میتواند ساختار برنامه را توصیف کند.
-
یک مدل فرآیند میتواند پیکربندی گردش کار را هدایت کند.
-
یک مدل رابط کاربری میتواند توسعه صفحه را پشتیبانی کند.
-
یک مدل استقرار میتواند محیط هدف را توصیف کند.
انضباط خوب در پیادهسازی
برای حفظ همسویی:
-
عناصر پیادهسازی را به مدلهایی که محقق میکنند، پیوند دهید.
-
تصمیمات طراحی و فرضیات را ثبت کنید.
-
مدلها را هنگام وقوع تغییرات قابل توجه در پیادهسازی بهروزرسانی کنید.
-
بررسی کنید که آیا آثار تولیدشده یا مشتقشده همچنان دقیق هستند.
-
از برخورد با نمودارها بهعنوان تحویلهای یکباره خودداری کنید.
-
از بازبینی مدلها بهعنوان بخشی از حاکمیت توسعه استفاده کنید.
هدف این نیست که هر خط کد را مجبور به نمایش در یک نمودار کنیم. هدف، حفظ سطح مناسبی از انتزاع برای ارتباطات، طراحی، تحلیل و نگهداری است.
۹. فایده هفتم: ایجاد مستندات سازگارتر
فایده هفتم، مستندات سازگارتر است.
مستندات ناسازگار میشوند وقتی چندین تیم بهصورت دستی توصیفهای همپوشانیدار از همان سیستم را نگهداری میکنند. برای مثال، یک نیازمندی ممکن است در یک مشخصه به یک شیوه نوشته شود، در یک نمودار به شیوهای دیگر توصیف شود و در نرمافزار تحت نام دیگری پیادهسازی شود.
یک پلتفرم یکپارچه میتواند با استفاده از آثار متصل بهعنوان مبنای گزارشها و تحویلها، این تکرار را کاهش دهد.
مزایای مستندات سازگار
-
کاهش اطلاعات متناقض
-
ورود دادههای تکراری کمتر
-
تهیه سریعتر مستندات
-
بازبینی و تأیید آسانتر
-
بهتر شدن فرآیند جذب برای اعضای جدید تیم
-
پشتیبانی بهتر از حسابرسی و انطباق
-
مستندات نگهداری قابلاعتمادتر
مستندات باید مالکیت واضحی داشته باشند.
برای هر اثر مهم، تعریف کنید:
-
چه کسی آن را ایجاد میکند
-
چه کسی آن را بازبینی میکند
-
چه کسی آن را تأیید میکند
-
تغییرات چگونه مدیریت میشوند
-
چند بار بهروزرسانی میشود
-
چه آثار دیگری را تحت تأثیر قرار میدهد
مستندات تولیدشده تنها زمانی مفید هستند که اطلاعات زیربنایی آنها بهدرستی نگهداری شوند. خودکارسازی میتواند ثبات را بهبود بخشد، اما جایگزین حاکمیت و بازبینی نمیشود.
۱۰. ایجاد یک روش کاری ردیابپذیر
راهی عملی برای استفاده از پلتفرم، تعریف روابط در طول پیشرفت پروژه است.
برای هر هدف اصلی کسبوکار، موارد زیر را شناسایی کنید:
-
نیازمندیهایی که از آن پشتیبانی میکنند
-
فرآیندها و موارد استفاده مرتبط
-
مدلهایی که رفتار را توصیف میکنند
-
عناصر طراحی که آن را پیادهسازی میکنند
-
آزمونهایی که آن را تأیید میکنند
-
مستنداتی که آن را توضیح میدهند
یک ماتریس ردیابی ساده میتواند بهعنوان یک مکانیزم کنترل استفاده شود:
| هدف کسبوکار | نیازمندی | طراحی یا مدل | ارجاع پیادهسازی | تأیید |
|---|---|---|---|---|
| کاهش زمان پردازش | خودکارسازی گردش کار تأیید | مدلهای فعالیت و فرآیند | خدمت گردش کار | آزمونهای عملکرد و پذیرش |
| بهبود دسترسی مشتریان | ارائه پورتال خودخدمت | موارد استفاده و طراحی رابط کاربری | کاربرد پورتال | آزمونهای کارایی و عملکردی |
| محافظت از دادههای حساس | اجرای دسترسی مبتنی بر نقش | مدلهای امنیت و استقرار | خدمت مجوزدهی | آزمونهای امنیتی |
مستندات دقیق بسته به پروژه متفاوت خواهد بود، اما اصل آن ثابت میماند: هر تحویلدهنده مهم باید هدف و رابطهای واضح با کارهای اطراف خود داشته باشد.
۱۱. گردش کار پیشنهادی پروژه
گردش کار زیر ایدههای شکل را در عمل به کار میگیرد.
گام ۱: تعریف زمینه کسبوکار
مسئله، فرصت، اهداف، ذینفعان و مرزهای پروژه را مستند کنید.
گام ۲: ثبت الزامات
الزامات عملکردی، ویژگیهای کیفیت، قوانین کسبوکار، محدودیتها و معیارهای پذیرش را ثبت کنید.
گام ۳: ایجاد مدلهای مناسب
مدلهایی را انتخاب کنید که مسئله و راهحل را شفاف میکنند. از تولید نمودارهایی که از تصمیمگیری واقعی، توضیح یا فعالیت مهندسی پشتیبانی نمیکنند، خودداری کنید.
گام ۴: پیوند دادن مستندات مرتبط
اهداف کسبوکار را به الزامات، الزامات را به مدلها، مدلها را به عناصر طراحی، و عناصر طراحی را به ارجاعات پیادهسازی یا آزمون متصل کنید.
گام ۵: بازبینی مشارکتی
ذینفعان کسبوکار و فنی را دعوت کنید تا اطلاعات یکسان پروژه را از دیدگاههای متناسب با نقشهای خود بازبینی کنند.
گام ۶: توسعه راهحل
از الزامات و طراحیهای تأییدشده برای هدایت پیادهسازی استفاده کنید.
گام ۷: پایش تغییرات
هنگامی که الزامات، طراحیها یا جزئیات پیادهسازی تغییر میکنند، تأثیرات downstream را ارزیابی کرده و مستندات متأثر را بهروزرسانی کنید.
گام ۸: تولید و نگهداری مستندات
در صورت امکان، مشخصات، گزارشها، نمودارها و مستندات فنی را از اطلاعات فعلی پروژه تولید کنید.
گام ۹: اعتبارسنجی تکمیل
قبل از انتشار، تأیید کنید که:
-
اهداف کسبوکار مورد توجه قرار گرفتهاند.
-
الزامات برآورده شدهاند.
-
الزامات مهم ردیابیپذیر هستند.
-
طراحی و پیادهسازی همسو هستند.
-
آزمونها رفتار مورد نظر را پوشش میدهند.
-
مستندات سیستم تحویلدادهشده را منعکس میکنند.
۱۲. شیوههای حکمرانی که پلتفرم را مؤثر میکنند
یک پلتفرم یکپارچه محیط را فراهم میکند، اما تیمها همچنان به شیوههای کاری شفاف نیاز دارند.
از قراردادهای نامگذاری استفاده کنید
نامهای یکسان را برای موارد زیر تعریف کنید:
-
نیازمندیها
-
فرآیندها
-
بازیگران
-
سیستمها
-
اجزا
-
موجودیتهای داده
-
خدمات
-
اسناد
مالکیت آثار را تعریف کنید
مسئولیت نگهداری هر نوع اصلی از اطلاعات را به کسی واگذار کنید.
نسخهها و تغییرات را کنترل کنید
تغییرات مهم را ثبت کنید و تأثیر آنها بر آثار مرتبط را ارزیابی کنید.
از تکرار غیرضروری پرهیز کنید
به جای کپی کردن همان اطلاعات در چندین سند، ترجیحاً به یک اثر مشترک پیوند دهید.
از جزئیات مدلسازی مناسب استفاده کنید
مدلهایی ایجاد کنید که به اندازه کافی جزئیات داشته باشند تا ارتباط و مهندسی را پشتیبانی کنند، اما نه آنقدر جزئی که نگهداری آنها دشوار شود.
بهطور منظم بازبینی کنید
بازبینیها را در نقاط عطف معنادار برنامهریزی کنید، از جمله:
-
تأیید نیازمندیها
-
تأیید معماری
-
تکمیل طراحی
-
اعتبارسنجی پیش از انتشار
-
درخواستهای تغییر عمده
کیفیت پروژه را اندازهگیری کنید
اندازهگیریهای مفید ممکن است شامل موارد زیر باشند:
-
درصد نیازمندیهایی که دارای پیوندهای ردیابی هستند
-
تعداد عناصر طراحی بدون پیوند
-
تعداد یافتههای بررسینشده
-
زمان بهروزرسانی مستندات
-
زمان ارزیابی تأثیر تغییرات
-
پوشش نیازمندیها تا تست
-
تعداد آثار تکراری یا متعارض
۱۳. اشتباهات رایجی که باید از آنها پرهیز کرد
یکپلتفرم یکپارچهبهطور خودکار یک فرآیند یکپارچه تولید نمیکند. از این مشکلات رایج پرهیز کنید:
-
مورد توجه قرار دادن پلتفرم بهعنوان یک ابزار ترسیم نمودار
-
ایجاد مدلها بدون پیوند دادن آنها به نیازمندیها
-
نگهداری چندین نسخه غیررسمی از یک اثر یکسان
-
بهروز نکردن طراحیها پس از تغییرات پیادهسازی
-
تولید مستندات از اطلاعات منسوخ
-
مشارکت دادن ذینفعان کسبوکار فقط در ابتدای کار
-
مدلسازی بیشازحد جزئیاتی که ارزش کمی دارند
-
فرض وجود ردیابی بدون بررسی پیوندها
-
استفاده از اصطلاحات ناسازگار در بین تیمها
-
مورد توجه قرار دادن مستندات بهعنوان یک فعالیت فقط در مرحله پایانی
۱۴. ارزش کلی
پیام مرکزی شکل این است که کارهای پروژه زمانی مؤثرتر میشوند که کسبوکار، نیازمندیها، مدلسازی، طراحی، پیادهسازی و مستندات به هم متصل باشند.
رویکرد یکپارچه میتواند به سازمانها کمک کند:
-
نگاه شفافتری نسبت به اهداف پروژه حفظ کنند
-
کاهش سیلوهای اطلاعاتی
-
بهبود ارتباطات
-
تقویت همکاری
-
شناسایی زودتر تأثیرات تغییرات
-
اتصال تصمیمات طراحی به پیادهسازی
-
تولید مستندات قابلاعتمادتر
-
حفظ دانش در طول چرخه عمر پروژه
به طور خلاصه، این پلتفرم یک زنجیره پیوسته را از چرا پروژه مورد نیاز است تا چه چیزی باید ساخته شود, چگونه باید طراحی شود, چگونه پیادهسازی میشود و چگونه نتیجه توضیح داده و نگهداری میشود.





