وب سایت علیرضا صائبی وبلاگ علیرضا صائبی
درخواست تغییرات نرم‌افزار سندی است که شامل درخواست‌های ذینفعان مجاز و معتبر برای ایجاد هر نوع تغییر در سامانه نرم‌افزاری بوده و در صورت تائید کمیته مدیریت تغییرات یا مدیر سامانه نرم‌افزاری، منجر به اعمال تغییرات موردنظر در نرم‌افزار خواهد شد. این سند به RFC که مخفف عبارت Request for change است نیز مشهور است. معمولاً RFC از یکی از ۵ منبع زیر ایجاد می‌شود:
۱٫ گزارش مشکلات سامانه که معمولاً شامل خطاهای نرم‌افزاری یا منطقی است.
۲٫ درخواست ارتقاء در عملکرد نرم‌افزار که معمولاً از طریق کاربران ارشد، خبرگان کسبوکار یا مدیران ارشد سامانه ارائه می‌شود و می‌تواند شامل نیازمندی‌های کارکردی یا غیر کارکردی (Functional / Non-Functional Requirements) در نرم‌افزار باشد.
۳٫ وقایعی که در جریان توسعه سامانه‌های دیگر پیش‌آمده و نیاز به تغییراتی را در عملکرد نرم‌افزار پدید می‌آورند.
۴٫ تغییراتی که در زیرساخت‌ها یا استانداردهای نرم‌افزاری سازمان پدیدمی‌آیند. (مانند مسائل امنیتی یا تغییرات در فنّاوری)
۵٫ نیازمندی‌های مدیر ارشد سیستم به ایجاد تغییرات در سامانه نرم‌افزاری.
تجربه‌های موفّق در مدیریت تغییرات سامانه‌های فنّاوری اطلاعات (بر اساس بهروش ITIL)، اجزای اصلی سند درخواست تغییرات را به شرح زیر برمی‌شمرند:
۱٫ اطلاعات سریال فرم RFC شامل: شماره و تاریخ
۲٫ مشخصات درخواست دهنده شامل: نام و نام خانوادگی، سمت در فرایند/پروژه، محل خدمت، شماره تلفن و آدرس پست الکترونیکی
۳٫ تأثیر درخواست در عملکرد سامانه نرم‌افزاری که با مقادیر کم، متوسط و زیاد مشخص می‌شود و شامل حوزه تأثیر درخواست موردنظر در سامانه نرم‌افزاری است. مثلاً اگر این تغییر برای عده محدودی از کاربران تأثیرگذار است، مقدار کم و اگر برای یک واحد یا معاونت یا ساختمان تأثیرگذار است، مقدار متوسط و اگر در کاربری همه کاربران سامانه نرم‌افزاری تأثیرگذار است، مقدار زیاد را برای آن در نظر می‌گیرند.
۴٫ ضرورت درخواست که برحسب فوریت موردنیاز در اعمال تغییرات موردنظر می‌تواند با یکی از مقادیر کم، متوسط و زیاد مشخص گردد.
۵٫ نوع درخواست که معمولاً با یکی از دو مقدار “درخواست جدید” و “رفع خطا” اعلام می‌شود.
۶٫ عنوان ماژول شامل نام فرم، گزارش یا به‌طورکلی عنوان ماژولی که درخواست تغییر برای آن داده‌شده است.
۷٫ شرح مسئله یا نیازمندی شامل جزئیات و مصادیقی است که مسئله موردنظر درخواست‌کننده را به‌صورتی مشخص، واضح، دقیق و قابل درک برای طراحان و توسعه‌دهندگان نرم‌افزار بیان می‌کند. مثلاً نمونه شرح مسئله را می‌توان به این صورت بیان نمود: همه کاربران باید بتوانند در فرم ورود به نرم‌افزار (login) به راهنمای لازم برای نحوه عضویت در نرم‌افزار دسترسی داشته باشند.
۸٫ دلیل نیاز به تغییرات شامل دلایل منطقی، فنی و پذیرفته‌ای است که برای توجیه نیازمندی ذکرشده در بخش شرح مسئله ارائه می‌شود. عبارت زیر مثال مناسبی از دلیل نیاز به تغییر بیان‌شده در شرح مسئله پیشین است: دلیل نیاز به دسترسی به راهنمای نحوه عضویت در فرم ورود به نرم‌افزار، عدم آشنایی کاربران با رویّه کاری نرم‌افزار جدید و نیاز به عضویت در آن است. به همین دلیل لازم است تا کاربران به فرم ثبت‌نام دسترسی داشته و از طریق راهنمای موردنظر از مراحل مختلف فرایند تائید سطح دسترسی آگاهی یابند.
۹٫ راهکار پیشنهادی برای حل مسئله شامل راه‌حل‌ها و روش‌هایی است که درخواست‌کننده تغییرات برای اعمال تغییر موردنیاز خود در سامانه پیشنهاد می‌دهد. این روش‌ها طبیعتا بایستی به‌صورتی قابل پیاده‌سازی و دربرگیرنده نکات فنی موردنظر تیم طراحی و پیاده‌سازی باشد و بدیهی است که راهکار ارائه شده در این بخش صرفا پیشنهاد درخواست‌دهنده تغییرات به تیم طراحی و توسعه نرم‌افزار است و با توجه به سطوح مختلف تعریف شده برای مسئولیت در ماتریس RACI، تصمیم نهایی برای روش اعمال تغییرات در نرم‌افزار بر عهده تیم طراحی و توسعه سامانه نرم‌افزاری است. برای مثال نسبت به مسئله بیان شده در بند ۷، می‌توان راهکار پیشنهادی زیر را نوشت: پیشنهاد می‌شود لینک راهنمای مورد نیاز در صفحه اول قرارداده شود به‌صورتی که با کلیک بر روی آن راهنما در قالب یک صفحه وب در صفحه جدیدی برای کاربر نمایش داده شود.
۱۰٫ روش آزمون و پذیرش محصول شامل فرایند تست و پذیرش نرم‌افزار پس از اعمال تغییرات است. این فرایند شامل تمام نکاتی است که نیازمندی‌های کارکردی و غیرکارکردی درخواست‌کننده تغییرات را پوشش می‌دهد و معمولاً به‌صورت یک چک‌لیست نوشته می‌شود. چنانچه موارد مندرج در این بخش بر روی نسخه جدید نرم‌افزار تست شوند و مشکلی مشاهده نشود، نسخه ارائه شده قابل پذیرش خواهد بود.
۱۱٫ تأثیرات تغییر بر روی سایر ماژول‌ها شامل تاثیراتی است که تغییرات درخواستی بر روی کارکرد سایر ماژول‌های نرم‌افزار خواهد گذاشت. چنانچه این تأثیرات توسط درخواست‌کننده بررسی نشده و در این بخش درج نشوند، ممکن است باعث ایجاد خطا در عملکرد بخش‌های دیگر نرم‌افزار شوند که به‌مرور باعث کاهش اعتبار سامانه نرم‌افزاری نزد بهره‌برداران خواهد گردید.
کلیشه فرم درخواست تغییرات از اینجا قابل دانلود است. بدیهی است با حذف هریک از بخش‌های فوق در RFC بخشی از رویه اعمال تغییرات با مشکل مواجه شده و نتیجه مناسبی از آن دریافت نمی‌شود. این قالب پس از اعلام از سوی درخواست‌کننده معتبر، در اختیار تیم طراحی و توسعه نرم‌افزار قرارگرفته و پس از تائید ایشان، تغییرات موردنظر در نرم‌افزار اعمال می‌گردد. سپس محصول جدید مطابق رویه پیشنهادی مورد آزمون قرارگرفته و در صورت تائید مورد استفاده قرارمی‌گیرد.
برای آشنایی بیشتر با فرایند مدیریت تغییرات می‌توانید دروس مربوط به این فرایند را از مجموعه‌های آموزش ویدئویی مبانی و مفاهیم مقدماتی ITIL و آموزش مفاهیم و رویه‌های استقرار ITIL مطالعه فرمایید.
برای اجرای موثر فرایند مدیریت تغییرات توجه به نکات زیر الزامی است:
الف) در بخش ۹ (راهکار پیشنهادی برای حل مسئله) بایستی توجه نمود که راهکار پیشنهادی بایستی فقط جنبه کسب‌وکاری داشته باشد و درخواست‌کننده تغییرات اجازه ارائه راهکار فنی یا فنّاورانه (Technological) برای تیم طراحی و توسعه ندارد.
ب) برای درخواست ایجاد یا تغییر در گزارش‌ها، لازم است به کاربرد نهایی اطلاعات درخواستی دقت شود. برای مثال بسیاری از مدیران به‌اشتباه درخواست جداول اطلاعاتی عریض و طویلی را به‌عنوان گزارش نرم‌افزاری دارند که پس از دریافت نیاز به زمان زیادی برای تحلیل انسانی خواهند داشت و صرفاً باعث اتلاف وقت کارشناسان و ایجاد کار اضافه برای ایشان خواهد گردید. البته این گزارش‌ها در سازمان‌هایی که کارشناسان ایشان بیکار هستند و مدیران خود را موظف به مشغول کردن ایشان می‌دانند بسیار مفید است، اما معمولاً این نوع گزارش‌ها و جداول اطلاعاتی عریض و طویل حاصلی برای سازمان یا شرکت نخواهد داشت.
راه‌حل پیشنهادی برای درخواست ایجاد یا تغییر در گزارش‌ها آنستکه مدیران بهره‌بردار ابتدا یک نمونه اولیه از گزارش مورد درخواست خود را با فرمت مطلوب با ابزارهایی نظیر Excel یا Word یا دیگر ابزارهای مشابه بسازند و سپس بررسی کنند که آیا گزارش موردنظر برای مدیران در یک نگاه (at a glance) قابل‌فهم و استفاده است یا نیاز به پردازش و تحلیل بیشتری دارد؟ از سوی دیگر لازم است به این سوال پاسخ دهند که گزارش ساخته‌شده با فرمت و اطلاعات موجود چه مسئله‌ای را از سازمان یا شرکت حل می‌کند؟ حال بررسی کنند ماشین این اطلاعات را چگونه می‌تواند تحلیل کند و نتیجه‌ای خلاصه‌تر و کاربردی‌تر برای مدیران و بهره‌برداران ایجاد نماید. با تکرار این فرایند معمولاً گزارش‌ها به یکسری نمودار یا نمایشگر وضعیت ساده و کاربردی منتج می‌شوند که می‌توانند در یک نگاه اطلاعات بسیاری را به کاربر ارائه دهند. مثال ساده برای این نوع گزارش‌ها داشبورد ماشین است. گزارش‌های نوع اول که بررسی کافی بر روی آن‌ها انجام‌نشده بود، مانند آمپر بنزین رایج در اکثر ماشین‌های قدیمی صرفاً یک عدد حدودی از میزان بنزین باقیمانده در باک ماشین را نمایش می‌دهند که راننده با مشاهده آن بایستی تحلیل‌های زیادی انجام دهد تا به این نتیجه برسد که زمان مناسب برای سوخت‌گیری چه زمانی است؟ اما در نسل بعدی ماشین‌ها یک محاسبه ساده از میزان بنزین موجود در باک و میزان معمول مصرف سوخت ماشین و فاصله محل جاری تا پمپ‌بنزین بعدی، به راننده اعلام می‌کند که بهتر است در جایگاهی که در مسیر بعدی او قرار دارد سوخت‌گیری نماید و اگر به هر دلیلی در آن جایگاه امکان سوخت‌گیری وجود نداشت، بهترین جایگاه جایگزین برای سوخت‌گیری کدام است؟ همان‌طور که مشاهده می‌کنید در این مثال طراح داشبورد اطلاعات همه جایگاه‌های سوخت‌گیری را به راننده نمایش نمی‌دهد (شاید بعداً کاربردی برای آن پیدا کردیم!) و یا راننده را مجبور به محاسبه و تحلیل نمی‌نماید.
• این قابلیت برای سیستم لازم است.
• وجود این قابلیت برای سیستم بدیهی است.
• همه سامانه‌های مشابه این قابلیت را دارند.
• خوب است که سیستم این قابلیت را داشته باشد.
• چون این قابلیت را برای دو بخش دیگر در نرم‌افزار قرارداده‌ایم، اینجا هم اضافه شود.
• تشخیص مدیریتی
• صلاحدید مدیریتی / کارشناسی
• ممکن است در آینده به این قابلیت نیاز پیدا کنیم.
د) اولویت اعمال تغییرات، تابعی از تأثیر و ضرورت درخواست است. به‌این‌ترتیب که اولویت ۱ (بالاترین اولویت) با درخواست‌هایی است که تأثیر زیاد و ضرورت زیاد دارند و به همین ترتیب پایین‌ترین اولویت (اولویت ۵) برای درخواست‌هایی است که تأثیر و ضرورت آن‌ها کم است. برای محاسبه سایر اولویت‌ها می‌توانید از جدول پیش رو کمک بگیرید.
ه) در بخش ۱۱ (تأثیرات تغییر بر روی سایر ماژول‌ها) توجه به جزئیات کارکرد سایر ماژول‌های نرم‌افزار الزامی است. به همین دلیل گفته می‌شود، درخواست تغییرات بایستی از سوی کسانی ارائه شود که تسلط و اشراف کافی به جزئیات نحوه عملکرد تمام بخش‌های نرم‌افزار داشته و در هنگام درخواست تغییرات تأثیرات جانبی پیاده‌سازی رویه‌های پیشنهادی را بر روی سایر ماژول‌های نرم‌افزار موردنظر قرار می‌دهند. یکی از اشتباهات مدیران بهره‌بردار و حتی مدیران توسعه نرم‌افزار آنستکه از کاربران جوان و کم‌تجربه درخواست تغییرات را بدون توجه به تسلط ایشان به کارکرد ماژول‌های مختلف نرم‌افزار می‌پذیرند و لیست تغییرات را به همان صورت به توسعه‌دهندگان نرم‌افزار اعلام می‌نمایند. معمولاً در این حالت تأثیرات جانبی تغییرات موردنظر بر روی سایر ماژول‌ها به‌صورت کامل در نظر گرفته نمی‌شود و باعث ایجاد اختلال در کارکرد دیگر بخش‌های نرم‌افزار می‌شود. تکرار این امر اعتبار سامانه نرم‌افزاری را نزد بهره‌برداران به شدّت کاهش داده و به‌مرور باعث می‌شود تا مدیران کسبوکار به فکر جایگزینی سامانه باشند درحالی‌که با دقت نظر مدیران بهره‌بردار و استفاده از نظرات نیروی متخصص به‌جای نیروهای کم‌تجربه به‌راحتی می‌توان از بروز این اشتباه پیشگیری نمود.
و) اعلام درخواست تغییرات به گروه طراحی و توسعه نرم‌افزار بایستی در دوره‌های زمانی مشخصی انجام پذیرد. مثلاً برگه‌های درخواست تغییرات به‌صورت ماهانه از کاربران جمع‌آوری گردیده و هر سه ماه یک‌بار به گروه طراحی و توسعه نرم‌افزار ارائه شود. از اشتباهات رایج سازمان‌ها و توسعه‌دهندگان نرم‌افزار می‌توان به ارائه نامنظم برگه‌های درخواست تغییرات اشاره نمود که می‌تواند نظم فرایند مدیریت تغییرات و مدیریت نسخ نرم‌افزار را برهم زده و باعث شود گروه توسعه در اعمال تغییرات دچار اشتباهات فراوانی گردیده و درنتیجه اعتبار نرم‌افزار نزد کاربران از بین برود و بهره‌بردار در پی جایگزین کردن نرم‌افزار برآید. به خاطر دارم سازمانی را که سامانه اتوماسیون اداری خود را هر ۲-۳ سال یک‌بار تغییر می‌داد و علت را عدم توانایی شرکت ارائه‌دهنده نرم‌افزار در برآوردن نیازمندی‌های اعلام‌شده می‌دانست و یا سازمان بزرگی را که بیش از ۸ سال بدون نرم‌افزار عملیات را به‌صورت دستی انجام می‌داد چون معتقد بود هیچ شرکتی نمی‌تواند نرم‌افزار موردنیاز ایشان را تأمین نماید. درحالی‌که در صورت اجرای صحیح فرایند مدیریت تغییرات و توجه به نکات ساده فوق فرایند مدیریت تغییرات به صورتی صحیح و کارآمد اجراشده و می‌تواند نیازهای سازمان را برآورده سازد.
امیدوارم با رعایت نکات فوق فرایند مدیریت تغییرات که از فرایندهای اصلی و تأثیرگذار در توسعه و بلوغ سامانه‌های نرم‌افزاری است، به صورتی مؤثر و کاربردی اجرا شود.
بیشتر بخوانید: ITIL چیست؟ :: آموزش مبانی و مفاهیم مقدماتی ITIL :: آموزش مفاهیم و رویه‌های استقرار ITIL
