باید‌ها و نبایدها‌ی به‌کارگیری مدل V در ارتباط با توسعه نرم‌افزارها

این مطلب یکی از مقالات پرونده ویژه«متدولوژی‌ها، الگوها و معماری نرم‌افزار» شماره 207 ماهنامه شبکه است. علاقه‌مندان می‌توانند کل این پرونده ویژه را از روی سایت شبکه دانلود کنند.

در مدل V به ازای هر مرحله توسعه یک مرحله آزمایش قرار دارد که به شکل موازی اجرا می‌شود؛ بنابراین، مراحل تایید در یک‌طرف مدل V و مراحل اعتبارسنجی در طرف دیگر این مدل قرار می‌گیرند. فاز مربوط به کدنویسی این دو سمت مدل را به یکدیگر متصل می‌کند. شکل (1)

رابطه‌ای را که میان هر یک از فازهای موجود در مدل V وجود دارد، نشان می‌دهد. متناظر با هر مرحله تحلیل و طراحی یک‌فاز آزمایش در نظر گرفته‌شده است. (شکل 2)

مراحل تایید فازها در مدل V

در مدل V چند مرحله تایید وجود دارد که جزئیات مربوط به هر یک از این فازهای اعتبارسنجی به شرحی که در ادامه مشاهده خواهید کرد انجام می‌شوند. 

تجزیه‌وتحلیل نیازمندی‌ها

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

طراحی سیستم

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

فاز طراحی معماری

در این فاز که جزء فازهای سطح بالای مدل V به شمار رفته و به نام فاز طراحی سطح بالا HLD (سرنامHigh Level Design) از آن نام‌برده می‌شود، معماری انتخاب می‌شود. تیم یا به عبارت دقیق‌تر مدیر پروژه سعی می‌کند معماری را انتخاب کند که عناوینی همچون فهرست ماژول‌ها، خلاصه قابلیت‌های هر ماژول، ارتباط ظاهری رابط‌ها، وابستگی‌ها، جدول‌های بانک اطلاعاتی، دیاگرام‌های مربوط به معماری و جزئیات فنی را به‌خوبی و به شکل روشنی بیان کند. در این فاز چیزی فراتر از یک راهکار فنی پیشنهاد می‌شود. به عبارت دقیق‌تر، بر مبنای میزان نقدینگی و امکان‌سنجی فنی از سوی تیم معماری مربوط پیشنهاد می‌شود. در این طرح سیستم به ماژول‌های مختلفی شکسته می‌شود. در این مرحله مشخص می‌شود که فرآیند انتقال داده‌ها و ارتباط میان ماژول‌های داخلی با جهان خارج (سامانه‌های دیگر) چگونه خواهد بود. بر اساس اطلاعات مشخص‌شده در این مرحله فازهای مربوط به آزمایش، طراحی و ادغام‌شده و در نهایت مستندسازی می‌شوند.

طراحی ماژول‌ها

فاز طراحی ماژول‌ها یک طراحی سطح پایین LLD (سرنام Low Level Design) است. در این فاز سیستم به واحدها یا ماژول‌های کوچک‌تری شکسته می‌شود. نکته مهم و قابل توجه در این فاز تعریف روشن و دقیق ماژول‌هایی است که ساخته خواهند شد. با توجه به این‌که مستندات و معماری به شکل دقیق و روشنی در فازهای قبلی آماده‌شده‌اند، در نتیجه برنامه‌نویس دغدغه خاصی در ارتباط با کدنویسی نخواهد داشت. اما توجه داشته باشید که ماژول‌ها باید در بالاترین سطح از سازگاری با سایر ماژول‌های موجود در معماری سیستم و سامانه‌های خارجی نوشته شوند. در همان زمانی که فرآیند طراحی ماژول‌ها انجام می‌شود، تست واحد
(Unit Testing) نیز ساخته می‌شود. تست واحد، فرآیند توسعه را به شکل قابل‌توجهی دقیق و هدفمند کرده و سعی می‌کند هرگونه شکاف و خطایی که ممکن است در مراحل اولیه به وجود آید، حذف ‌کند. (اما اصطلاح «تست واحد»: واحد یکی از کوچک‌ترین بخش‌های قابل‌آزمایش در یک نرم‌افزار است. واحد در برنامه‌نویسی شی‌گرا به یک متد اشاره دارد، درحالی‌که در برنامه‌نویسی رویه‌ای کل برنامه یا یک تابع را شامل می‌شود. فرض کنید در آزمایشگاه معماری کامپیوتر در نظر دارید یک مدار را پیاده‌سازی کنید. در نخستین گام باید مدارهای مجتمع (IC) را تک‌به‌تک آزمایش کرده تا از درستی عملکرد آن‌ها اطمینان حاصل کنید. عدم انجام این آزمایش باعث می‌شود، پس از پیاده‌سازی یک مدار در صورت عدم کارکرد صحیح ساعت‌ها وقت صرف کنید که علت بروز مشکل را پیدا کنید. در دنیای نرم‌افزار نیز واحد‌هایی که از سوی تیم برنامه‌نویسی نوشته می‌شوند، نقشی همانند مدارهای مجتمع دارند. تست واحد، هر واحد را به شکل جداگانه آزمایش می‌کند. در فرآیند تست واحد تکه کدی نوشته می‌شود تا واحد آن تکه کد را فراخوانی کرده و استفاده کند. اگر واحد بتواند کد را به‌درستی و با عملکرد بالا پردازش کند، به معنای آن است که واحد نوشته‌شده 
بدون عیب است. در مجموع باید بگوییم که هدف و فلسفه به‌کارگیری تست واحد بررسی این موضوع است که آیا واحد طراحی‌شده همان‌کاری را که مدنظر ما بوده به‌درستی می‌تواند انجام دهد یا نیازمند بازبینی است. تیم‌های توسعه می‌توانند تست واحد را منطبق با طراحی داخلی ماژول‌ها پیاده‌سازی کنند.) در فاز طراحی ماژول‌ها جزئیات زیر مشخص می‌شوند:
• جدول‌‌های بانک اطلاعاتی به همراه عناصر داخلی آن‌ها (اندازه و نوع ستون‌ها) تعریف می‌شوند.
• جزئیات همه رابط‌ها (که شامل ارجاع دقیق به واسط‌های برنامه‌نویسی (API‌ها)) مشخص می‌شود.
• همه وابستگی‌ها نشان داده می‌شوند.
• پیغام‌های خطا همگی فهرست می‌شوند.
• تمام ورودی‌ها و خروجی‌های موردنیاز ماژول‌ها مشخص می‌شوند.
• طراحی تست واحد نیز در این مرحله انجام می‌شود.

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

فاز اعتبارسنجی
فاز اعتبارسنجی در مدل V از بخش‌های مختلفی ساخته‌شده که این بخش‌ها به شرح زیر هستند.

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

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

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

مطلب پیشنهادی

مدل‌های توسعه تکرارشونده و افزایشی

متدولوژی‌های افزایشی و تکاملی در طراحی نرم‌افزار

معایب مدل V از دید طرفداران مدل‌های چابک

طرفداران مدل‌های چابک انتقادهایی را به مدل V وارد کرده و آن را یک مدل ناکارآمد برای توسعه نرم‌افزارها می‌دانند. این گروه از منتقدان دلایل زیر را در این زمینه مطرح می‌کنند.
• به دلیل سادگی بیش‌ازحد به مدیران پروژه یک حس امنیت کاذب می‌دهد. مدل V بیشتر نمایی از نحوه مدیریت پروژه در مدت‌زمان توسعه نرم‌افزار را نشان داده و به‌جای آن‌که تمرکزش بر مشتریان یا توسعه‌دهندگان نرم‌افزار باشد بیشتر راحتی کار را برای مدیران، حسابرسان و وکلا به ارمغان می‌آورد.
• افراد تازه‌کار به‌درستی می‌توانند مدل V را درک ‌کنند، اما این درک اولیه برای افراد تازه‌کار تنها زمانی مفید خواهد بود که به درک عمیق‌تری از فرآیند توسعه نرم‌افزار منجر شود.
• یک مدل غیر منعطف بوده که در آن پیشرفت‌ها با کندی همراه بوده و پتانسیل چندان قدرتمندی برای پاسخ‌گویی به تغییرات ندارد.
• مدل V تنها یک تغییر جزیی نسبت به مدل آبشاری دارد و در نتیجه مجموعه مشکلات موجود در مدل آبشاری، در این مدل نیز وجود دارد. مدل V تاکید زیادی روی آزمایش دارد و به آزمایش‌ها در ابتدای برنامه‌ریزی اهمیت زیادی می‌دهد. این آزمایش‌ها یک مشکل بزرگ به وجود می‌آورند، درحالی‌که بازه زمانی که برای پیاده‌سازی پروژه تعیین‌شده، ثابت باقی می‌ماند، آزمایش‌های مکرر این زمان ارزشمند را هدر می‌دهند.
• مدل V از انسجام و دقت بالایی برخوردار نیست و ابهام گسترده‌ای در مورد خود مدل V وجود دارد. اگر یکی از نقاط تکیه‌گاه(Anchor) که مشتریان روی آن توافق کرده‌اند از دست برود، خلأ به وجود آمده بر روند توسعه نرم‌افزار تاثیر منفی خواهد گذاشت. 
• در بیشتر موارد درک مشترکی از مفاهیمی که در این مدل مطرح می‌شود، وجود ندارد.

مزایای مدل V از منظر طرفداران مدل V

حامیان مدل V این‌گونه استدلال می‌کنند که این مدل در طول زمان تکامل‌یافته، انعطاف‌پذیری بالایی داشته و شتاب زیادی به فرآیند توسعه می‌دهد. این گروه بر این باور هستند که انضباط و دقیق بودن مدل V باعث شده، یک طراحی دقیق، توسعه منظم، مستندسازی کافی و آزمایش‌های متعدد یک نرم‌افزار با کیفیت را به وجود آورد. به‌کارگیری مدل V در صنعت ساخت تجهیزات پزشکی یکی از مهم‌ترین دلایلی است که طرفداران مدل V به آن استناد می‌کنند. نمونه تکامل‌یافته‌ای از مدل V در شکل (3) نشان داده شده است