فاز انتقال (Transition) چهارمین و در واقع آخرین فاز از چرخه‌ی توسعه‌ی سیستم‌های نرم‌افزاری و آخرین فاز از مرحله‌ی فراوری است. در انتهایِ این فاز، فراورده‌ی نرم‌افزاری به‌طور کامل به محیط مشتری و کاربران اِنتقال‌یافته و تمام کاربران نهاییِ سیستم قادر خواهند بود تمامی خدمات مورد نیازشان را بدون نیاز به حضور مستمر تولید‌کنندگان نرم‌افزار، از سیستم مستقرشده دریافت نمایند؛ پروژه به طور کامل بسته‌شده و سیستم نرم‌افزاری به مرحله‌ی نگهداری و تکامل وارد می‌شود.
پایانِ این فاز، معادلِ آخرین نقطه‌ی تصمیم‌گیری سازمانی در چرخه‌ی توسعه‌ی نرم‌افزار، یعنی انتشار فراورده (Product Release) است.

فازِ قبل، یعنی فازِ ساخت (construction) با ارائه‌ی نسخه‌ی بتای سیستم نرم‌افزاری که دربرگیرنده‌ی تمام قابلیت‌ها، کارکِردها، و وظیفه‌مندی‌های مورد انتظارِ ذینفعان است، پایان می‌یابد. نسخه‌ی مذکور، شامل ابزارهای لازم برای نصب، مستندات تکمیلی و پشتیبان، و مواد و محتوای آموزشی است. امّا می‌دانیم که این نسخه‌ی بِتـا، محصول نهایی نیست و هنوز لازم است که تنظیم‌ها و پیکربندی‌های دقیق‌تری روی وظیفه‌مندی‌ها (کارکردها)، کارایی، و به‌طور کلّی، کیفیتِ آن انجام شود.

تمرکز اصلی فعالیت‌ها در فاز انتقال، بر این موضوع است که اطمینان یابیم، سیستمِ نرم‌افزاری تولید شده، به طورِ کامل نیازهای کاربرانش را برآورده می‌نماید. به‌طور معمول، در این فاز یک یا دو تکرار برنامه‌ریزی می‌شود که عمدتاً شاملِ تست (آزمون) فراورده‌ی نرم‌افزاری به‌منظور آماد‌سازی آن برای تحویل و نیز اِعمال تنظیمات و اصلاحات جزئی بر اساس بازخوردهای دریافت‌شده از کاربران است.

در این نقطه از چرخه‌ی توسعه‌ی سیستم نرم‌افزاری، نباید هیچ‌گونه مسأله یا ریسک عمده‌ای داشته باشیم و بنابراین بیشتر بازخوردهای کاربران باید متوجه مسائلی مانند پیکره‌بندی، ملاحظات مرتبط با نصب، تنظیم دقیق، و مسائل مرتبط با سهولت استفاده، مانند تغییر (سفارشی‌سازی) برخی واسط‌های کاربر ‌باشد.

پروژه‌هایی که با پیچیدگی زیادی مواجه هستند، اغلب ممکن است نیازمند به چندین تکرار در فازِ انتقال باشند. در چنین حالتی، در هر یک از تکرارها، با اِعمال برخی تغییرات و تصحیح‌های مورد نیاز، نسخه‌ای قابل استقرار از سیستم ارائه می‌شود. در اغلبِ موارد، در این فاز مجبور خواهیم شد که برخی از خصیصه‌های سیستم را که پیش از این در فازهای قبل به منظور پایبندی به برخی ضرب‌العجل‌های تعیین‌‌شده در زمانبندی به تعویق افتاده بودند، کامل نماییم.

باید خاطرنشان کنیم که فازِ انتقال به طور اساسی با فاز انتهایی در سایر رویکردهای سنتی (مانند رویکرد آبشاری) متفاوت است، زیرا هنگامی که وارد فازِ نهایی می‌شویم، با نسخه‌ای تست‌شده، مجتمع، و پایدار از سیستم سر و کار داریم. در صورتی‌که در رویکرد سنتی آبشاری، در آخرین فاز که مرتبط با یکپارچه‌سازی می‌باشد، عمدتاً با شکستن و به هم ریختن‌های وسیعِ سیستم مواجه می‌شویم به گونه‌ای که حتی در برخی موارد ممکن است قادر به کامپایل تمام سیستم نباشیم، یا اینکه واسط‌های میان زیرسیستم‌ها با هم سازگاری نداشته باشند، یا اینکه سیستم پی در پی از کار می‌افتد؛ در نتیجه، در فازِ آخرِ رویکرد آبشاری عموماً شاهد انجام دوباره‌کاری‌های زیادی می‌باشیم که تأخیرِ پروژه، نتیجه‌ی منطقی آن خواهد بود. با به وجود آمدن تأخیر، مدیریت باید وقت زیادی را صرف مذاکره‌ی مجدّد با ذینفعان و تنظیم مجدّد انتظارات و خواسته‌های ذینفعانِ کلیدی نماید. تجربه نشان داده است که در چنین مواردی افزودن نیروهای بیشتر برای تکمیل سریع‌تر کار نه تنها موجبات کم‌شدن تأخیر را فراهم نمی‌نماید، بلکه عملاً نتیجه‌ی آن تأخیر بیشتر و آشفتگی بیش از پیشِ پروژه می‌‌باشد.

اهدافِ فازِ انتقال

مهمترین اهدافِ فازِ انتقال عبارتند از:

  1. انجام آزمون‌های بِتـا به منظور تأیید اینکه سیستم پاسخ‌گوی انتظارات کاربران است.
  2. آموزش کاربران و نگهدارندگان سیستم به منظور دستیابی به قابلیت خوداتکایی آنان. این دسته از فعالیت‌ها برای اطمینان از اینکه سازمان یا سازمان‌های پذیرنده‌ی نرم‌افزار، شرایط و قابلیت‌های به‌کارگیری اصولیِ سیستم را داشته باشند، انجام می‌شود.
  3. آماده‌سازی محل استقرار و انتقال و کانورت بانک‌های اطلاعاتیِ عملیاتی. برای اینکه سیستم جدید با موفقیت را‌ه‌اندازی شود. ممکن است که لازم باشد سخت‌افزارهای جدیدی خریداری شود، فضای جدیدی برای سخت‌افزارهای جدید افزوده شده و یا داده‌های موجود در بانک‌های اطلاعاتی فعلی به قالب مناسب برای سیستم جدید تبدیل شود.
  4. در حالتی که محصول به صورت یک بسته‌ی تجاری است، آماده‌شدن برای بسته‌بندی، فرآوری، عرضه برای بازاریابی، توزیع، فروش، و نیز آموزش کارکنان مربوطه، ضروری است.
  5. دستیابی به توافق تمام ذینفعان نسبت به اینکه نسخه‌های تثبیت‌شده در استقرار، کامل بوده و با معیارها و شرایط ارزیابی مورد بحث در چشم‌انداز پروژه، تطابق دارد.
  6. با ثبت درس‌های آموخته‌شده و تجربیات کسب‌شده در طول این چرخه، مقدمات بهبودهای آینده را فراهم نماییم. خصوصاً تجارب به‌دست آمده از بهبود فرایند و به‌کارگیری ابزارها اهمیت بسیاری دارد.

باید توجه داشت که اهدافِ ذکرشده، ماهیّت فعالیت ندارند، بلکه کلیه‌ی فعالیت‌هایی که در هر فاز انجام می‌شود باید حداقل در راستای دستیابی به یکی از این اهداف باشد. هیچ‌گونه ترتیب خاصی میان این اهداف وجود ندارد. همه‌ی اهداف دارای اهمیت‌اند. با وجودی‌که اهدافِ هر یک از فاز دارای اهمیت و حساسیت یکسانی نیستند، ولی توجه داشته باشید که در صورت عدم تحقّق حتی یکی از آنها، فاز به پایان نمی‌رسد.

 فازِ انتقال و تکرارها

فازِ انتقال می‌تواند بر حسب نوعِ محصول، بسیار سر راست و آسان و یا به شدّت پیچیده باشد. فعالیت‌های مرتبط با انتقالِ نسخه‌ی جدیدی از یک محصول دِسک‌تاپ، احتمالاً خیلی ساده بوده و شاید تنها یک تکرار برای رفعِ چند نقص کوچک نیاز خواهیم داشت. در مقابل، جایگزینی یک سیستم یکپارچه‌ی بانکداری (Core Banking) معمولا به‌شدت پیچیده بوده و مستلزم برنامه‌ریزیِ چندین تکرار ‌است که در طی آن‌ها، سیستمِ جدید به تدریج با مجموعه سیستم‌های مختلف تلفیق‌شده و خصیصه‌های لازم به آن افزوده می‌شود. در ضمن، انتقال سیستم جدید و جایگزینی آن با سیستم قبلی، مستلزم فعالیت‌های بسیار پیچیده‌ای در سطح سازمان است. این انتقال ممکن است شامل راه‌اندازی همزمان سیستم‌های قدیم و جدید، انتقال داده‌ها، آموزش کاربران، و تعدیل فرایندهای سازمانی باشد.

بر حسب اهداف یک پروژه‌، فعالیت‌های مختلفی در تکرارهای فازِ انتقال انجام می‌شود. فازِ انتقال در بیشتر پروژه‌ها منطقاً ساده است. بیشتر فعالیت‌ها که عمدتاً پیاده‌سازی و تست می‌باشد، به تصحیح خطاها و مشکلات موجود ارتباط دارد. گه‌گاه ممکن است لازم باشد که تعداد محدودی ویژگی جدید به سیستم اضافه شود که در این صورت تکرار برنامه‌ریزی‌شده در این فاز، همانند تکرارهای فاز ساخت بوده و باید کمی روی نیازمندی‌ها، تحلیل، و طراحی نیز کار شود.

در رابطه با تولید محصولاتِ تجاری و نیز برخی اوقات که سیستم‌هایی برای کاربردِ گسترده‌ی داخلی ایجاد می‌شوند، باید مسائلی مانند بسته‌بندی، فرآوری، بازاریابی، فروش، و پشتیبانی نیز مورد توجه قرار گیرد.

در حالتی که پروژه‌ی شما تولیدِ یک سیستم کاربردی (application) است که نیازمند به تعدادی سخت‌افزار جدید است، مانند یک سیستم پردازش مالی بزرگ، یا مستلزم تبدیل داده‌های سیستم قدیم می‌باشد، باید فعالیت‌هایی را که در هدف سوم فاز انتقال، یعنی آماده‌سازی محل استقرار و تبدیل بانک‌های اطلاعاتی عملیاتی توصیف‌شده، با دقت و جزئیات بیشتری مورد توجه قرار دهید.

پروژه‌های بسیار پیچیده ممکن است نیازمند داشتن یک رویکرد تحویلِ تدریجی باشند که در این صورت در هر استقرار یک نسخه‌ی به تدریج کامل‌تر و با کیفیت بالاتر تولید می‌شود. این رویکرد، خصوصاً در مواردی که تنها راه تنظیمِ دقیقِ سیستم، گرفتنِ بازخورد از استفاده‌ی واقعی سیستم باشد، ضروری است. این روش برای سیستم‌های بزرگ مدیریت اطلاعات یا سیستم‌های فرمان و کنترل با استقرارهای توزیع‌شده و سخت‌افزارهای پیچیده، مستلزم این‌ است که چندین سیستم با هم مجتمع‌شده و تنظیمات دقیقی انجام شود. در چنین پروژه‌هایی، تکرارهای فازِ انتقال، بسیار شبیه تکرارِ آخر یا دو تکرارِ انتهای فازِ ساخت است، که به آن پیچیدگیِ داشتن چندین استقرار نیز افزوده می‌شود.

در پایانِ فازِ انتقال، باید به اهداف پیش‌بینی‌شده، دست‌یافته باشیم و پروژه در موقعیتی باشد که بتوان آن‌را خاتمه داد. در برخی از پروژه‌ها، پایان چرخه‌ی فعلی ممکن است همزمان باشد با شروع یک چرخه‌ی دیگر که منجر به نسل بعدی همان محصول خواهد شد. در دیگر پروژه‌ها، پایان فازِ انتقال ممکن است مصادف باشد با تحویل کامل دستاوردها به شخص ثالثی که مسئولیت عملیاتی کردن، نگهداری، و توسعه‌ی آتی سیستم تحویل‌شده را برعهده خواهد داشت.

توجه داشته باشید که در بسیاری از موارد، فازِ استارتاپ از یک چرخه‌ی تکامل با فازِ انتقال از چرخه‌ی توسعه، همپوشانی دارد. همزمان که در انتهای چرخه‌ی توسعه‌ی جاری، محصول در حال اِنتقال به محیط کاربران است، می‌توان فازِ استارتاپ چرخه‌ی توسعه‌ی جدیدی را شروع کرد و احتمالاً برخی از نیازمندی‌هایی را که به سبب محدودیت‌ها و شرایط فعلی در چرخه‌ی فعلی امکان تحقّق آن‌ها وجود نداشته، در چرخه‌ی توسعه‌ی بعدی و در واقع در نسل بعدی فراورده، پیاده‌سازی نمود.

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

با وجودی‌ که عمدتاً چرخه‌ی تکاملِ‌ یک فراورده، مستلزم تعریف پروژه‌ا‌ی دربرگیرنده‌ی هر چهار فاز استارتاپ، معماری، ساخت، و اِنتقال است، در بسیاری از پروژه‌ها، چرخه‌ی تکامل وارد یک سبک و اسلوب دیگری می‌شود که در آن کارهای عملیاتی، پشتیبانی، و فعالیت‌های عادی و روزمره‌ی نگهداری انجام می‌شود. در چنین حالتی ممکن است نیازی به یک سری فازهای جدید و از پیش‌تعریف‌شده نداشته باشیم؛ ساختِ یک نسخه‌‌ی جدید از نرم‌افزار که در آن خطاها و اشتباهات برطرف‌شده، همانند یک تکرار ساده در فاز انتقال است.

(مایلستون) نقطه‌ی تصمیم‌گیری سازمانی یا گام اصلیِ انتشار محصول

فازِ انتقال با رسیدن به چهارمین گام اصلی پروژه، یعنی گام ترخیص و انتشار محصول (Product Release)، پایان می‌یابد. تصمیم‌گیری کلیدی که در این گام انجام می‌شود به این موضوع اختصاص دارد که آیا تمامی ذینفعان به اهداف تدوین‌شده در چشم‌انداز پروژه دست یافته‌اند و نیز آیا یک شروع یک چرخه‌ی توسعه‌ی دیگر ضرورت دارد یا خیر. ممکن است چندین چرخه‌ی توسعه در فاز استارتاپ و یا در فازهای بعد برنامه‌ریزی شده باشد. در برخی موارد، این گام اصلی، با پایان فاز استارتاپ از چرخه‌ی بعدی توسعه‌ی محصول، همزمان می‌شود.

مهم‌ترین سؤالاتی که در این گام باید پرسیده شوند، عبارتند از:

  • آیا خواسته‌های مورد توافق با کاربران، تحقق یافته است؟ آیا تمامی نیازهای کاربران در چارچوب چشم‌انداز مورد توافق، برآورده شده‌ است؟
  • آیا هزینه‌های مالی و زمانی و نیز منابع اختصاص‌یافته مطابق برنامه‌ریزی‌ها و پیش‌بینی‌های قبلی بوده است؟ اگر خیر، چه کارها و اقداماتی باید در پروژه‌های آینده انجام شود؟

وقتی که در گام انتشار محصول قرار می‌گیریم، محصول در مرحله‌ی فرآوری قرار می‌گیرد و فرآیندهای نگهداری، عملیاتی‌کردن، و پشتیبانی آغاز می‌شود. این مرحله ممکن است خود شامل چرخه‌ی توسعه‌ی جدیدی برای بهبود محصول فعلی باشد.

تماس با ما

در حال ارسال

Log in with your credentials

Forgot your details?