مدل وی
مدل وی نماد یک روش فرایند تولید نرم‌افزار است (که قابل تطبیق برای تولید سخت‌افزار هم می‌باشد) و
ممکن است مدل آبشاری توسعه یافته به حساب آید. در این مدل به جای اینکه مسیر تولید همانند مدل آبشاری، یک مسیر شیب دار مستقیم به سمت پایین باشد، مسیر فرایندها پس از فاز برنامه‌نویسی به سمت بالا به شکل حرف وی انگلیسی خم می شود. مدل وی ارتباط بین فازهای مختلف چرخه حیات تولید نرم‌افزار و مراحل پیوسته فاز تست را مشخص می‌کند.
محورهای افقی و عمودی (از چپ به راست) میزان زمان یا تکمیل پروژه و سطح تکمیل مراحل که با عناوین انتزاعی تعریف شده‌اند (بالاترین سطح مفاهیم اصلی) را به ترتیب نشان می‌دهد.
مدل وی در مقابل مدل آبشاری برای رسیدگی به توازن تولید نرم‌افزار و تأیید پروژه استفاده می‌شود.
اهداف[ویرایش]
مدل وی راهنمایی برای برنامه‌ریزی و تحقق پروژه فراهم می‌کند. اهداف زیر در هنگام اجرای پروژه توسط این مدل مد نظر است:
۱- به حداقل رساندن میزان ریسک.
۲-بهبودی و تضمین کیفیت پروژه.
۳-کاهش زیاد هزینه در کل چرخه حیات پروژه
۴-بهبود ارتباط بین همه اعضای پروژه
موارد استفاده[ویرایش]
سیستم‌های مهندسی و تأیید
مشخصات جریان
این مدل در تنظیم فرایند تولید نرم‌افزار در داخل دولت آلمان فدرال استفاده شده‌است؛ و کماکان به عنوان استاندارد برای فرایند تولید نرم‌افزار در دولت و اماکن نظامی آلمان و در منطقه اروپاست. مفهوم مدل وی در اواخر ۱۹۸۰ به صورت مستقل توسط دولت‌های آلمان و آمریکا توسعه و ارتقاء پیدا کرده‌است.
مزایا و معایب[ویرایش]
مزایا[ویرایش]
مدل وی آنقدر مزایا دارد که معایب آن نادیده گرفته شود. مشخصه خاص مدل وی در ایده‌های بررسی تأیید و اعتبارسنجی آن است.
۱- کاربران در این مدل در تمام مراحل تولید، توسعه و نگهداری سیستم همراه هستند؛ و فرم وضعیت تغییرات و نگهداری سیستم به صورت عمومی در انظار عمومی است. فرم وضعیت تمام درخواستها و تغییرات در طول سال را نشان می‌دهد.
۲- در ابتدای هر پروژه این امکان وجود دارد که، آن پروژه را به صورت یک مدل خاصی از وی مدل متناسب با آن پروژه طراحی کرد. چون مدل وی یک مدل سازمانی و مستقلی است.
۳-مدل وی کمک‌های قدرتمندی را در مورد چگونگی نحوه پیاده‌سازی فعالیت‌ها و مراحل زیر مجموعه هریک از کار، تعریف اتفاقات مورد نیاز جهت تکمیل کار را تشریح کرده‌است.
معایب[ویرایش]
۱- برای کل پروژه با مدل وی نمی‌توان قرار دادی مشخص و شفاف مطرح کرد، و فقط برای زیر مجموعه‌های شفاف شده قرار داد معین نمود.
۲- در طول روال و مدت زمان مقدمه و نگهداری سیستم یک سازمان خاص فرقی بین عرضه‌کننده محصول و درخواست‌کننده نیست.
۳-سازماندهی و اجرای عملیاتها و تعمیر و نگهداری سیستم توسط این مدل پوشش داده نمی‌شود. با این حال برای برنامه‌ریزی و آماده‌سازی مستندات یک سیستم از این مدل استفاده می‌شود.
فاز (شناخت وتایید)[ویرایش]
تجزیه و تحلیل نیازمندیها[ویرایش]
در فاز تجزیه و تحلیل نیازمندی‌های سیستم، نیازمندی‌های مطرح شده سیستم از طریق جمع‌آوری نیازهای کاربران بدست می‌آید. در این فاز چیزی که مهم است چگونگی سازماندهی سیستم ایده‌آل مورد نظر ما است. به هر حال این فاز طراحی یا نحوه پیاده‌سازی را مشخص نمی‌کند. معمولاً با کاربران مصاحبه انجام می‌گردد و مستندات آن با عنوان مستندات نیازمندیها ثبت می‌شود. مستندات کاربران به صورت کلی عملیات اصلی سیستم، ظاهر برنامه، کارایی، اطلاعات، امنیت و سایر نیازهای مورد نظر کاربران را تشریح می‌کنند. سپس آن مستندات توسط تحلیلگران، تحلیل می‌گردد تا میزان درستی درک نیازمندی‌های کاربران مشخص گردد.
مستند تحلیل شده دوباره توسط کاربران سیستم جهت استفاده طراحان، در طراحی سیستم بازبینی می‌شود. در همین فاز فرم‌های تست سیستم، همچنین فرم‌های تأیید و تست نیازهای اصلی سیستم برای کاربران طراحی می‌گردد. این اقدامات به صورت موازی انجام می‌شود. روش‌های مختلفی برای جمع آوی نیازمندیها به شکل: مصاحبه، پرسشنامه، تجزیه و تحلیل سندها و فرمها، مشاهده مستقیم، نمونه‌ها، نمودارهای استفاده کاربران و نمودارهای وضعیت سیستم و کاربران به صورت ثابت و پویا وجود دارد.
طراحی سیستم[ویرایش]
این فازی است که کارشناسان سیستم به وسیلهٔ تجزیه و تحلیل و مطالعه مستندات نیازمندی‌های کاربران عملیات اصلی سیستم پیشنهادی را شناسایی و درک می‌کنند. آن‌ها امکان‌پذیری پیاده‌سازی هریک از نیازمندی‌های کاربران را مشخص می‌کنند. هریک از نیازمندی‌های که در پیاده‌سازی امکان‌پذیر نباشد به کاربر اطلاع داده می‌شود. راهکارهای پیدا شده توسط مستندات براساس مطالب بدست آمده جدید ویرایش می‌شود. بدین ترتیب مستندات ویژه نرم‌افزار جهت فاز پیاده‌سازی با عنوان «چاپ آبی» تولید می‌شود. این مستندات ساختار عمومی سازماندهی سیستم، ساختار منوها، ساختمان داده‌ها و غیره را شامل می‌شود. همچنین امکان دارد نمونه‌هایی از سناریوهای بعضی فراینده‌ها، فرم‌های ظاهری برنامه، و گزارش‌ها را برای درک بهتر در آن گنجانده شود. سایر اسناد ماننده نمودارهای موجودیت‌ها، فرهنگ لغت داده‌ها نیز در این فاز تولید می‌شود. فرم‌های تست سیستم در این مرحله آماده می‌شود.
طراحی معماری[ویرایش]
فاز طراحی معماری کامپیوتر و معماری نرم‌افزار نیز به عنوان طراحی سطح بالا عنوان می‌شود. اصول انتخاب معماری این است که آن معماری بتواند تمام عناوین کلی نیازمندیها را شامل لیست ماژولها، قابلیت‌های خلاصه هر ماژول، ارتباطات ظاهری برنامه، وابستگی‌ها و جداول پایگاه داده، نمودارهای معمالی و جزئیات تکنولوژی مورد نیاز و غیره را تحقق بخشد. طراحی تست مراحله یکپارچه‌سازی در فاز خاص انجام می‌شود.
طراحی ماژولها و روالها[ویرایش]
فاز طراحی می‌تواند به عنوان فاز طراحی سطح پایین مطرح شود. طراحی سیستم، کل سیستم را به ماژولها (تکه برنامه‌های کوچک) تقسیم می‌کند و هرکدام به گونه تشریح و توضیح داده می‌شود تا برنامه‌نویس بتواند به صورت مستقیم شروع به کدنویسی کند.
طراحی مستندات یا برنامه‌های سطح پایین به صورت ویژه شامل جزئیات فعالیت‌های منطقی زیر خواهند بود:
- جداول پایگاه داده همراه با فیلدهای آن شامل نوع و اندازه هر کدام.
- تمام جزئیات ظاهر برنامه (UI)به همراه تمام توابع و روال‌های به کار رفته.
- تمام مسائل مربوط به وابستگی الزامی در سیستم.
- فهرست تمام پیغام‌های خطا و اخطار مورد نیاز در سیستم.
- تمام ورودی‌ها و خروجی‌های مورد نیاز ماژولها.
تست هر یک از واحدها در این مرحله طراحی می‌شود.
مرحله اعتبار سنجی[ویرایش]
تست واحد[ویرایش]
در برنامه‌نویسی کامپیوتر، تست هر واحد منحصر به فرد همان کد تست می‌شود تا مشخص گردد که آیا آن واحد برای استفاده مناسب هست یا نه؟ هر واحد کوچکترین قسمت قابل آزمایش و تست یک برنامه است. در برنامه‌نویسی رویه ای، یک روال یا یک تابع ممکن است یک واحد برای تست باشد. تست و آزمایش واحدها توسط برنامه نویسان یا افراد خاص تست‌کننده طراحی شود. هدف از آزمون واحد، بررسی درستی انجام منطق برنامه برای قسمت‌های مختلف واحد مورد نظر و پوشش عملیات مورد نیاز است. در این روند برای راحتی کار و بررسی معتبر بودن ورودی‌های واحد مورد نظر از ابزارهای تجزیه و تحلیل ایستا استفاده می‌شود.
تست یکپارچه‌سازی[ویرایش]
در تست یکپارچه‌سازی سیستم، ماژول‌های جدا جدا باهمدیگر تست می‌شوند تا ایرادات رابطها (رابطهای تعاملی بین همدیگر) و ایرادات ارتباط آن‌ها مشخص شود. اسناد تست معمولاً به صورت جعبه‌های سیاهی (که ماهیت آن‌ها کدهای برنامه است) هستند که به صورت مستقیم ایرادات برنامه را نشان نمی‌دهند.
تست سیستم[ویرایش]
این تست، مشخصات سیستم را در مقایسه با سیستم واقعی مقایسه می‌کند. بعد از اینکه تست مرحله یکپارچه‌سازی تمام شد، مرحله بعد تست سیستم خواهد بود. تست سیستم نشان می‌دهد که آیا محصول یکپارچه‌سازی شده تمام مشخصات نیازمندیها را برآورده کرده‌است یا نه !. چرا پس از تست اجزا برنامه و برنامه یکپارچه شده هنوز نیازمند تست مجدد هستیم؟ جواب‌های این سؤال بشرح ذیل هستند:
دلایل تست سیستم[ویرایش]
۱- در تست‌های سطح پایین برای مسائل فنی برنامه صورت می‌گیرد. به‌طور مثال: از نظر فنی ممکن است یک فرم به صورت کامل انجام شده باشد. اما در تست سیستم این فرم از منظر و دیدگاه کاربر دیده می‌شود و مشخص می‌کند که آیا هدف و نیاز کاربر را برآورده کرده‌است یا خیر. تست‌کننده، این آزمون را انجام می‌دهد که آیا از نگاه کاربر ورودی و خروجی‌ها معتبر هستند یا خیر. برای مثال: مشتری (که سفارش و خرید این سیستم را انجام داده است) و کاربر (که برنامه را استفاده می‌کند) ممکن است دو گروه مختلفی از پرسنل یک سازمان از نظر جایگاه و مسئولیت باشند که هر کدام تعریف و منظور خاصی از نیاز در سیستم داشته باشند.
۲- خیلی از نتایج و رفتارهای توابع و روال‌های سیستم فقط هنگام ورود اطلاعات و به‌کارگیری سیستم خود را نشان می‌دهند و قابل آزمایش خواهند بود.
آزمون یا تست پذیرش کاربر[ویرایش]
تست پذیرش کاربر مرحله از تست بشماره می‌رود برای نشان دادن اینکه آیا نیازهای مشخص شده هنگام تجزیه و تحلیل نیازهای سیستم انجام شده‌اند یا نه. طراحی تست پذیرش از مستندات نیازمندیها استخراج می‌شوند. فاز تست پذیرش، فازی است که توسط مشتری انجام می‌شود که مشخص شود که آیا نیازمندی‌های مطرح شده از جانب ایشان در سیستم انجام شده‌است یا خیر؟
آزمون یا تست پذیرش کمک می‌کند که:
- مشخص شود که آیا معیارهای مشخص شده سیستم انجام شده یا نه.
- به‌طور کلی نیازهای مشتری در سیستم برآورده شده یا خیر.
- برنامه در دنیای واقعی به وسیلهٔ ورود اطلاعات واقعی آزمایش شود.
اهداف آزمون یا تست پذیرش: تغییرات انجام شده مطابق با نیازهای اصلی سیستم انجام شده یا خیر.
روش[ویرایش]
۱- تعیین معیارهای سنجش صحت پذیرش:
- نیازهای اصلی.
- کارایی رفع نیازها.
- کیفیت ظاهر برنامه مورد نیاز.
- کیفیت کلی نرم‌افزار.
۲- (مراحل) تولید یک طرح پذیریش:
- شرح پروژه.
- (مشخص کردن) مسئولیت‌های کاربر.
- (مشخص نمودن) توضیحات پذیرش.
- اجرای طرح پذیرش آزمون.
منابع[ویرایش]
en:V-Model (software development) مقاله دوم در ویکی‌پدیا
| حوزهها | |||||||
|---|---|---|---|---|---|---|---|
| مفاهیم | |||||||
| گرایشات | |||||||
| مدلها |
| ||||||
مهندسان نرم‌افزار سرشناس | |||||||
| حوزههای مرتبط | |||||||
| زمینه‌ها | |
|---|---|
| فرایندها | |
| مفاهیم | |
| زبان‌ها | |
| ابزارها | |
| افراد | |
| زمینه‌های مرتبط | |
