معرفی و آشنایی با 10 مدل توسعه ی نرم افزار

یکی از کارایی که نوشتن یه پروژه بدون اوون بیشتر شبیه یه بازیه تا نوشتن یه پروژه ی جدی، بحث تحلیل نرم افزار، تعیین نیازمندی ها و ... است. احتمالا هم می دونید که فکر کنم حدود نود درصد برنامه هایی که توی ایران نوشته میشه، اصلا شامل چنین مراحلی نیست.

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

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

این کتاب روشهای توسعه ی نرم افزار رو از روشهای سنتی که بیشتر به درد برنامه های استاتیک می خوردن معرفی کرده بود (روشهایی مثل Waterfall) تا روشهای جدید که برای برنامه های دینامیک استفاده میشه، مثل Adaptive Software Development، Scrum، XP و ... که جمعا ده روش میشد.

روشهای قدیمی و استاتیک که بررسی شده بود شامل موارد زیر میشد:

Code and Fix
Waterfall
V
Spiral
Staged Delivery
Evolutionary Prototyping

روشهای دینامیک هم شامل موارد زیر بود:

Scrum
Adaptive Software Development
Unified Process
Extreme Programming

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

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

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

موفق باشید.

موفق باشید آقای هاشمیان
منتظریم.

خیلی ممنون، !:متفکر:

خوب اول از مدل Code and Fix شروع می کنیم،
فکر کنم این مدل توسط 90 درصد برنامه نویسا توی ایران استفاده میشه، بدون اینکه خودشون هم بدونن که دارن از این مدل استفاده می کنن.


1) مدل Code and Fix:


مشخصه ها:

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

تعریف:

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

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

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

مزایا:

در این روش هیچ فازی برای مدل کردن و تعیین نیازها و طراحی و ... وجود نداره و به همین دلیل معمولا برنامه هاش زود آماده میشن (یا زود معلوم میشه که جواب نمی دن).

معایب:

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

2) مدل Waterfall

مشخصه ها:

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

تعریف:

مدل Waterfall یه متودولوژی ترتیبیه که به مستندات خیلی اهمیت میده. توی این مدل برای اینکه یه مرحله از کار تموم شده اعلام بشه و بریم مرحله ی بعد، باید تیمی که مسئ.ل اوون مرحله بوده کل کار اون مرحله رو مرور کنه و نتیجه رو در قالب یه سند ارائه بده. ارائه داده شدن سند مربوط به توضیحات کارهای انجام شده در هر مرحله، در حقیقت نقطه ی شروع مرحله ی بعد به حساب میاد.

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

http://i4.tinypic.com/106wwzk.jpg

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

1) بخش Concept:
در این مرحله که اولین مرحله هم هست، اهداف و محدودیتهای پروژه بررسی و بحث میشه و مقدار کار لازم برای انجام پروژه به صورت اولیه تخمین زده میشه. این مرحله با نوشته شدن و ارائه ی سند Concept تموم میشه.

2)بخش Requirements:
بعد از اینکه سند Concept خونده شد و درست و کامل بودن اون هم تایید شد، نیازهای نرم افزار، کارشناسی میشه. در این مرحله تیم طراح پروژه باید به صورت کامل و دقیق باید بتونه خود پروژه، تکنولوژی های قابل استفاده، محدودیتهای موجود و ... رو تا این نقطه درک کنه و به این وسیله ی یه مجموعه ی کامل از نیازهای سیستم رو تعیین کنه. وقتی این نیازها تایید شد، سند اوون نوشته میشه و بعد از تایید نهایی پروژه وارد مرحله ی بعد میشه.

3) قسمت طراحی High-Level:
در این مرحله بر اساس نیازهای سیستم، یه طرح کلی و معماری کلی از سیستم ایجاد میشه و همچنین ماژولها و کلاسهای مورد نیاز هم به صورت کلی طراحی میشن. در پایان این مرحله هم مثل همیشه، یه سند که گزارش کار این مرحله به حساب میاد و شامل طرح کلی برای پیاده سازی پروژه هست ارائه میشه و پروژه میره به مرحله ی بعد.

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

متاسفانه الان عجله دارم و نمی رسم این مدل رو کامل کنم، تا آخر هفته هم فکر نکنم بتونم بقیه ی مطالب رو بنویسم:گریه: .

ولی خوب در اسرع وقت سعی می کنم که این مدل رو کامل کنم.

موفق باشید.

5) مرحله ی پیاده سازی کد:
در این مرحله از این نوع طراحی نرم افزار، بر اساس مدلهایی که مستندات آن در قسمتهای قبلی تهیه شده بود برنامه ی اصلی نوشته و پیاده سازی میشه. در اغلب برنامه ها، کارهای مربوط به تست کردن کدها به صورت جزئی هم در این قسمت انجام میشه. یعنی اگر برنامه شامل 10 قسمت مختلف باشه، هر 10 قسمت در این مرحله پساده سازی میشه و آخر هم بررسی میشه که ببینن آیا هر کدام از این قسمت ها به تنهایی درست کار می کنن یا نه (Unit-Testing). پس وقتی این مرحله تموم بشه، برنامه نوشته شده و قسمتهای مختلف اوون هم تست شده تا مشخص بشه که این قسمتها به صورت جداگانه درست کار می کنن.

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

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

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

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

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

3) مدل توسعه نرم افزار V

مشخصه ها:

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

این مدل نیز مثل مدل Waterfall ترتیبیه و بر اساس مستندات شکل می گیره. یعنی برای اینکه از یه فاز در این مدل به فاز بعدی بریم باید مستندات مربوط به کارهای انجام شده در این فاز تهیه و تایید بشه.

در مورد rup هم مطلبی دارین؟
مگه rup از مدل های توسعه نرم افزار نیست؟

اگر پست اول رو نگاه کنید می بینید UP نهمین مدلیه که توضیح داده خواهد شد. الان من هنوز دارم مدل سوم رو از لیست توضیح می دم.

شکل زیر یه طرح کلی از طراحی و پیاده سازی یک نرم افزار به روش V رو نشون میده.

http://i4.tinypic.com/106wzrq.gif

یه پروژه توی این مدل، فازهای زیر رو طی می کنه:

1) فاز نیازمندی ها:
در این مرحله، مثل مدل قبل مشتری با کمک اعضای تیم پروژه، نسازهای مورد نظرشون رو کارشناسی می کنن. در پایان این فاز یک سند حاوی نیازهای مشخص شده برای پروژه منتشر میشه و همچنین مقدار کار لازم برای پروژه نیز تخمین زده میشه.

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

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

4) پیاده سازی:
خوب، این فاز هم مشخصه. در این بخش بر اساس مستندات فاز قبلی پروژه پیاده سازی میشه.

5) فاز تست جز به جز برنامه:
توی این فاز، قسمتهای مختلف برنامه به صورت مجزا تست میشن تا مشخص بشه که هر کدوم از اونها به تنهایی درست کار می کنن یا نه. توی این فاز در حقیقت مشخص میشه که آیا ما به خواسته هایی که توی فاز 3 مشخص شده بود رسیدیم یا نه؟ برای اتمام این فاز باید تمام قسمتهای برنامه با موفقیت از تست خارج بشن

6) فاز تست کلی برنامه:
توی این فاز هم همه ی قسمتهای برنامه در کنار هم قرار می گیرن و به صورت کلی و مجتمع تست می شن. یعنی توی این قسمت بررسی میشه که آیا مواردی که توی طراحی در فاز 2 مشخص شده بود بدست آمده اند یا نه؟

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

دیدید که روند کار توی این مدل تقریبا مشابه روند کار توی مدل waterfall هست. یعنی این مدل از مدل Waterfall مشتق شده.

مزایا:

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

معایب:

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

نوع های مشتق شده از این مدل:

مدل دیگه ای به اسم مدل W وجود داره که یه قسمت V دیگه مخصوص تست بخشهای مختلف برنامه به این مدل اضافه می کنه (و میشه W). این V اضافی باعث میشه که مراحل تست برنامه از همون ابتدای کار انجام بشن و از ابتدا بدونیم که تمام قسمتهای برنامه با حداقل خطای ممکن طراحی شدن (البته مدل به صورت /V\ در میاد اما خوب بهش می گن W). برای اطلاعات بیشتر در مورد این مدل می تونید از سایت http://www.stickyminds.com استفاده کنید.

4) مدل توسعه ی نرم افزار Spiral

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

تعریف:

شکل زیر مدل Spiral رو با مراحل مختلف اون نشون میده.


http://i4.tinypic.com/10emu6b.jpg

قسمتهای عمده ای که در مدل Spiral وجود دارن و باعث میشن که ریسک اجرای یه پروژه کمتر بشه شمال موارد زیر میشن:

1) تعریف اهداف، روشهای دستیابی به آنها و محدودیتهای موجود: در مرحله ی اول، اهداف اون مرحله، روشهای موجود برای دستیابی به اون اهداف و نیز محدودیتهای موجود به دقت بررسی شده و تشریح میشن.

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

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

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

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

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

:تشویق:

نقل قول:

---

نوشته شده توسط omid_Ahmadi

یکی از کارایی که نوشتن یه پروژه بدون اوون بیشتر شبیه یه بازیه تا نوشتن یه پروژه ی جدی، بحث تحلیل نرم افزار، تعیین نیازمندی ها و ... است. احتمالا هم می دونید که فکر کنم حدود نود درصد برنامه هایی که توی ایران نوشته میشه، اصلا شامل چنین مراحلی نیست.

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

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

این کتاب روشهای توسعه ی نرم افزار رو از روشهای سنتی که بیشتر به درد برنامه های استاتیک می خوردن معرفی کرده بود (روشهایی مثل Waterfall) تا روشهای جدید که برای برنامه های دینامیک استفاده میشه، مثل Adaptive Software Development، Scrum، XP و ... که جمعا ده روش میشد.

روشهای قدیمی و استاتیک که بررسی شده بود شامل موارد زیر میشد:

Code and Fix
Waterfall
V
Spiral
Staged Delivery
Evolutionary Prototyping

روشهای دینامیک هم شامل موارد زیر بود:

Scrum
Adaptive Software Development
Unified Process
Extreme Programming

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

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

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

موفق باشید.

---

:تشویق:

نقل قول:

---

نوشته شده توسط leila_safa

در مورد rup هم مطلبی دارین؟
مگه rup از مدل های توسعه نرم افزار نیست؟

---

لطفا اگه میشه در موردrup هم توضیحاتی بدین.

اقا تاپیک بسیارعالی و قابل استفاده ای است به این امید کعه با زحمت شما این کار کامل بشه

کاش مطالبتون رو کاملتر قرار میدادین...