سلام ، آیا این بازدید اول شماست ؟ یا
تبلیغات در این انجمن سفارش تبلیغات
نمایش نتایج: از 1 به 1 از 1

موضوع: ساخت نرم افزار به مدلv

  1. #1
    ✦ کاربر آسمونی ✦
    تاریخ عضویت
    Jan 2013
    محل سکونت
    مازندران-متل قو - قشقايي
    نوشته ها
    266
    پسندیده
    6
    مورد پسند : 223 بار در 156 پست

    Tavajoh ساخت نرم افزار به مدلv

    مدل وی نماد یک روش فرآیند تولید نرم افزار است (که قابل تطبیق برای تولید سخت افزار هم میباشد)و


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


    محورهای افقی و عمودی (از چپ به راست ) میزان زمان یا تکمیل پروژه و سطح تکمیل مراحل که با عناوین انتزاعی تعریف شده اند(بالاترین سطح مفاهیم اصلی ) را بترتیب نشان می دهد .


    ساخت نرم افزار به مدلv






    مدل وی در مقابل مدل آبشاری برای رسیدگی به توازن تولید نرم افزار و تایید پروژه استفاده می شود.


    ساخت نرم افزار به مدلv


    اهداف


    مدل وی راهنمایی برای برنامه ریزی و تحقق پروژه فراهم می کند. اهداف زیر در هنگام اجرای پروژه توسط این مدل مد نظر است :


    ۱- به حداقل رساندن میزان ریسک.


    ۲-بهبودی و تضمین کیفیت پروژه.


    ۳-کاهش زیاد هزینه در کل چرخه حیات پروژه


    ۴-بهبود ارتباط بین همه اعضای پروژه


    موارد استفاده


    سیستم های مهندسی و تایید
    مشخصات جریان


    این مدل در تنظیم فرآیند تولید نرم افزار در داخل دولت آلمان فدرال استفاده شده است. و کماکان به عنوان استاندارد برای فرآیند تولید نرم افزار در دولت و اماکن نظامی آلمان و در منطقه اروپاست مفهوم مدل وی در اواخر ۱۹۸۰ بصورت مستقل توسط دولت های آلمان و آمریکا توسعه و ارتقاء پیدا کرده است .


    مزایا و معایب


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


    ۱- کاربران در این مدل در تمام مراحل تولید، توسعه و نگهداری سیستم همراه هستند.و فرم وضعیت تغییرات و نگهداری سیستم بصورت عمومی در انظار عمومی است.فرم وضعیت تمام درخواستها و تغییرات در طول سال را نشان می دهد.


    ۲- در ابتدای هر پروژه این امکان وجود دارد که، آن پروژه را بصورت یک مدل خاصی از وی مدل متناسب با آن پروژه طراحی کرد . چون مدل وی یک مدل سازمانی و مستقلی است .


    ۳-مدل وی کمک های قدرتمندی را در مورد چگونگی نحوه پیاده سازی فعالیت ها و مراحل زیر مجموعه هریک از کار، تعریف اتفاقات مورد نیاز جهت تکمیل کار را تشرح کرده است.


    معایب
    ۱- برای کل پروژه با مدل وی نمی توان قرار دادی مشخص و شفاف مطرح کرد، و فقط برای زیر مجموعه های شفاف شده قرار داد معین نمود.


    ۲- در طول روال و مدت زمان مقدمه و نگهدارسیستم یک سازمان خاص فرقی بین عرضه کننده محصول و درخواست کننده نیست .


    ۳-سازماندهی و اجرای عملیاتها و تعمیر و نگهداری سیستم توسط این مدل پوشش داده نمی شود. با این حال برای برنامه ریزی و آماده سازی مستندات یک سیستم از این مدل استفاده می شود.


    فاز (شناخت و) تایید


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


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


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






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


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


    طراحی مستندات یا برنامه های سطح پایین بصورت ویژه شامل جزئیات فعالیت های منطقی زیر خواهند بود :


    جداول پایگاه داده همراه با فیلدهای آن شامل نوع و اندازه هر کدام .
    تمام جزئیات ظاهر برنامه (UI)به همراه تمام توابع و روالهای به کار رفته .
    تمام مسائل مربوط به وابستگی الزامی در سیستم .
    فهرست تمام پیغامهای خطا و اخطار مورد نیاز در سیستم.
    تمام ورودی ها و خروجی های مورد نیاز ماژولها.
    تست هر یک از واحد ها در این مرحله طراحی می شود.
    ساخت نرم افزار به مدلv


    مرحله اعتبار سنجی


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


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


    تست سیستم
    این تست، مشخصات سیستم را در مقایسه با سیستم واقعی مقایسه می کند . بعد از اینکه تست مرحله یکپارچه سازی تمام شد، مرحله بعد تست سیستم خواهد بود.تست سیستم نشان می دهد که آیا محصول یکپارچه سازی شده تمام مشخصات نیازمندیها را برآورده کرده است یا نه !. چرا پس از تست اجزا برنامه و برنامه یکپارچه شده هنوز نیازمند تست مجدد هستیم؟ جواب های این سوال بشرح ذیل هستند:


    دلایل تست سیستم
    ۱- در تست های سطح پایین برای مسائل فنی برنامه صورت میگیرد.بطور مثال : از نظر فنی ممکن است یک فرم بصورت کامل انجام شده باشد.اما در تست سیستم این فرم از منظر و دیدگاه کاربر دیده می شود و مشخص می کند که آیا هدف و نیاز کاربر را برآورده کرده است یا خیر.تست کننده، این آزمون را انجام می دهد که آیا از نگاه کاربر ورودی و خروجی ها معتبر هستند یا خیر. برای مثال : مشتری ( که سفارش و خرید این سیستم را انجام داده است ) و کاربر( که برنامه را استفاده می کند)ممکن است دو گروه مختلفی از پرسنل یک سازمان از نظر جایگاه و مسئولیت باشند که هر کدام تعریف و منظور خاصی از نیاز در سیستم داشته باشند.


    ۲- خیلی از نتایج و رفتارهای توابع و روالهای سیستم فقط هنگام ورود اطلاعات و به کارگیری سیستم خود را نشان می دهند و قابل آزمایش خواهند بود.


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


    آزمون یا تست پذیرش کمک می کند که :


    مشخص شود که آیا معیارهای مشخص شده سیستم انجام شده یا نه .
    بطور کلی نیازهای مشتری در سیستم برآورده شده یا خیر.
    برنامه در دنیای واقعی بوسیله ورود اطلاعات واقعی آزمایش شود.
    اهداف آزمون یا تست پذیرش : تغییرات انجام شده مطابق با نیازهای اصلی سیستم انجام شده یا خیر.


    روش
    ۱- تعیین معیارهای سنجش صحت پذیرش :


    نیازهای اصلی.
    کارایی رفع نیازها.
    کیفیت ظاهر برنامه مورد نیاز.
    کیفیت کلی نرم افزار.
    ۲- (مراحل )تولید یک طرح پذیریش :


    شرح پروژه.
    (مشخص کردن) مسئولیت های کاربر.
    (مشخص نمودن)توضیحات پذیرش.
    اجرای طرح پذیرش آزمون.
    کاربر مقابل پست پوريا 2013 عزیز را پسندیده است: bOs3000 (03-03-2013)

اطلاعات موضوع

کاربرانی که در حال مشاهده این موضوع هستند

در حال حاضر 1 کاربر در حال مشاهده این موضوع است. (0 کاربران و 1 مهمان ها)

کلمات کلیدی این موضوع

مجوز های ارسال و ویرایش

  • شما نمیتوانید موضوع جدیدی ارسال کنید
  • شما امکان ارسال پاسخ را ندارید
  • شما نمیتوانید فایل پیوست کنید.
  • شما نمیتوانید پست های خود را ویرایش کنید
  •