متدولوژی های توسعه نرم افزار

متدولوژی های توسعه نرم افزار – ایران ترجمه – Irantarjomeh

مقالات ترجمه شده آماده گروه کامپیوتر

مقالات ترجمه شده آماده کل گروه های دانشگاهی

مقالات

چگونگی سفارش مقاله

الف – پرداخت وجه بحساب وب سایت ایران ترجمه(شماره حساب)ب- اطلاع جزئیات به ایمیل irantarjomeh@gmail.comشامل: مبلغ پرداختی – شماره فیش / ارجاع و تاریخ پرداخت – مقاله مورد نظر --مقالات آماده سفارش داده شده پس از تایید به ایمیل شما ارسال خواهند شد.

مقایسه متدولوژی های توسعه نرم افزار

هدف و حیطه مقاله

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

اصطلاحات فنی

به منظور تحت پوشش قرار دادن اهداف این مبحث، جدول شماره ۱ مدل ها و تکنیکهای توسعه نرم افزار را دسته بندی کرده است.

یک متدولوژی متشکل از یکی از مدل های توسعه نرم افزار می‌باشد که با یک یا چند تکنیک همراه است، بدین معنی که  متدولوژی = مدل + تکنیک (ها). تکنیک های نمونه سازی اولیه، اتاق تمیز، و شیء گرا روش هایی برای اجرای مدل های آبشاری، افزایشی و مارپیچی هستند. ممکن است این تکنیک ها با هم ترکیب شده و در یک پروژه ساده به کار برده شوند. همچنین ممکن است بخش هایی از یک تکنیک بدون استفاده از تمام جنبه‌های آن تکنیک به کار رود. یعنی یک پروژه با مدل مارپیچی، ممکن است نمونه سازی را با طراحی و تحلیل شیء گرایی ترکیب کند و از تکنیک های آزمایش کننده اتاق تمیز هم استفاده نماید. با استفاده از تعریف متدولوژی = مدل + تکنیک (ها)، تعداد متدولوژیهای قابل استفاده آنقدر زیاد است که برای تعریف آنها وقت کم خواهیم آورد. بنابراین، ادامه این مبحث به مدل ها و تکنیک ها می‌پردازد.

متدولوژی های توسعه نرم افزار

مدل آبشاری

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

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

هر مستطیل در شکل ۱ یک مرحله یا فاز را نشان می‌دهد. خروجی هر مرحله شامل مستند سازی است. فازهای پایین‌تر از مرحله طراحی به همراه جزئیات آن، نرم افزار را به عنوان بخشی از خروجی خود بحساب می‌آورند. انتقال از یک مرحله به مرحله بعدی با یک مرور رسمی‌بوسیله پیمانکار یا آژانسهای دولتی مربوطه انجام می‌پذیرد. این مرور و بازبینی دولت را در جریان پیشرفت مورد پیمانکاری قرار می‌دهد. در نقاط بحرانی در مدل آبشاری، خطوط مبنایی قرار می‌گیرند که آخرین خط، خط مبنای محصول می‌باشد. خط مبنای نهایی با ممیزی (بازرسی) همراه است. مرور و ممیزی مذکور درMILSTD-973  و DOD-STD-1521B تعریف شده اند ( جدول ۶ را ببینید).

متدولوژی های توسعه نرم افزار

مقایسه مدل آبشاری

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

• یک مدل رسمی

• نوعی از توسعه بالا به پایین

• متشکل از مراحل مستقل که به ترتیب انجام می‌شوند

• به شیوه های گوناگون مورد استفاده قرار می‌گیرند:

  • مراحل ترکیب می‌شوند

  • نقاط شروع و پایان متفاوتی وجود دارند

 کجا از مدل آبشاری استفاده کنیم

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

” به طور مثال، اگر شرکتی در ساخت سیستم های حسابداری، کنترل کننده های I/O، یا کامپایلرها تجربه دارد، آنگاه ساخت محصول دیگری مشابه آن بر مبنای طرح های موجود با مدل آبشاری به بهترین شیوه مدیریت می‌شوند… .”

متدولوژی های توسعه نرم افزار

مدل افزایشی

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

به چه هنگام از مدل افزایشی استفاده کنیم

” اگر توسعه یکباره سیستم توام با خطر باشد، باید توسعه افزایشی را در نظر بگیریم”.

مدل مارپیچی

توصیف. مدل افزایشی را می‌توان به عنوان یک مدل مارپیچی در نظر گرفت. روال مارپیچی یکی از مدل افزایشی قوی را نشان می‌دهد: منابع را می‌توان ثابت نگه داشت، اما اندازه سیستم رشد می‌کند. اندازه مارپیچی با اندازه سیستم برابر است، درحالیکه فاصله بین حلقه های مدل مارپیچی معرف منابع می‌باشد. در شکل ۳، فاصله بین حلقه ها تغییر نمی‌کند و نشان می‌دهد که مقدار منابع استفاده شده تغییری نمی‌کند.

چه زمان ازمدل مارپیچی  بوهم استفاده شود

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

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

متدولوژی های توسعه نرم افزار

ساخت نمونه اولیه

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

“… شما لیستی از نیازمندی ها را در اختیار دارید. که گاهی کاملا غیر رسمی‌است … . اگر این مورد برای مشتری شما در نظر گرفته شده باشد، این نیازمندی ها می‌توانند به صورت نوعی یادداشت بنظر رسند.”

“بعد از آن، نیازمندی های خود را با تغییر یا عمل (نمونه اولیه ) برای شامل شدن آنها، به یک مدل کاری تغییرشکل دهید. با یک ۴GL ] زبان نسل چهارم[،نیاز مندی ها را به دستورات ماکرو و زبان تغییر دهید.”

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

“… بعد از آن، نتایج را به مشتری نشان داده یا بررسی می‌کنید که آیا کاری که می‌خواهید را انجام می‌دهد یا خیر. اگر نیازمندی های جدیدی ظاهر شدند، روند را تکرار کنید.”

چه زمانی از ساخت نمونه اولیه در مدل آبشاری استفاده می‌شود

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

چه زمان از پروتوتایپ همراه با اشیاء  استفاده می‌شود

توسعه شیءگرا، بر روی اشیاء واقعی تمرکز دارد  و بعدا در مورد آن بحث می‌شود.

کوت و یوردان عقیده دارند که پروتوتایپ همیشه باید با بخشهای تحلیل و طراحی OO استفاده شود.

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

متدولوژی های توسعه نرم افزار

اتاق تمیز

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

اتاق تمیز توسط چندین گروه که اطلاعاتی را برای ارزیابی این روش ارائه نمودند، مورد استفاده قرار گرفت. مایک دایر یک پروژه کوبول را توصیف می‌کند که ۵۲۰۰۰ خط برنامه با ۱۷۹ خطا را تولید کرده، که این مورد ۱۵ تا ۲۰ برابر بهتر از نرم ها یا قواعد صنعتی است.

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

چه موقع از اتاق تمیز استفاده شود

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

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

متدولوژی های توسعه نرم افزار

شیء گرایی

توصیف.  شیوه شیء گرایی بر روی توسعه نرم افزاری بر حسب اشیاء واقعی تمرکز دارد. این مورد بر اساس قضیه ای است بر طبق آن برای مدیریت بیش از هفت شیء یا مفهوم در یک زمان، محدودیت اساسی از نظر نیروی انسانی وجود دارد.گرادی بوچ، پیشنهاد می‌کند که اصول مهندسی نرم افزار می‌تواند برای تجزیه سیستم ها به ما کمک کند به گونه ای که هرگز با بیش از هفت موضوع به طور همزمان درگیر نباشیم. محبوبیت OO با افزایش پیچیدگی سیستم های نرم افزاری در حال افزایش است. OO شامل تحلیل شیء گرا (OOA)، طراحی (OOD)، و برنامه نویسی (OOP) می‌باشد.

کجا از OO استفاده شود

OO را در پروژه هایی که ویژگی های زیر را دارند استفاده کنید:

1. سیستم داده گرا است و پیچیدگی عملی کمتر مورد توجه قرار می‌گیرد.

2. تکنولوژی اجرای خوب OO امکان دارد و سازمان ابزار کافی برای شاغلان خود فراهم می‌کند تا به طور مؤثر از تکنیک های شیء گرا استفاده کنند.

3. سازمان برای تغییر موفقیت آمیز روش های توسعه خود به اندازه کافی مهارت دارد.

4. سیستم ها و برنامه های کاربردی که توسط سازمان توسعه داده می‌شوند از نوعی هستند که به صورت مؤثر از نمونه OO استفاده می‌کنند.

واسطه های کاربر گرافیکی با استفاده از OOA با موفقیت توسعه یافتند.

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

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

متدولوژی های توسعه نرم افزار

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

توسعه نرم افزار سیستم دفاع DOD-STD-2167A (یا به اختصار ۲۱۶۷A) برای استفاده توسط تمامی ‌ادارات و نمایندگی های وزارت دفاع که نرم افزار را توسعه می‌دهند تصویب شده است. از آنجاییکه ۲۱۶۷A اغلب با دسته‌ای از نرم افزارها که به عنوان سیستمهای نرم افزاری “محاط‌شده” به آن اشاره می‌شود، رابطه بسیار نزدیکی دارد، برای توسعه دسته دیگری از نرم افزار هم قابل استفاده است – سیستم های اطلاعات اتوماتیک (AIS)، گاهی به عنوان سیستم های اطلاعات مدیریت مورد استفاده قرار می‌گیرند. استاندارد های مستند سازی سیستم های اطلاعات اتوماتیک وزارت دفاع DOD-STD-7935A، مستنداتی که به طور ویژه توسعه AIS را پشتیبانی می‌نماید را تعیین نموده است. DOD-STD-2167A از نظر گستردگی از ۷۹۳۵A  وسیع تر است زیرا فرآیند ها (۴) و فعالیت های نرم افزار را توصیف می‌کند و همچنین مستندسازی توسعه را هدایت می‌کند.

متدولوژی های توسعه نرم افزار

خلاصه

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