مدل های فرآیند تولید نرم افزار سنتی (ساخت یافته)

 

 

مدل های فرآیند تولید نرم افزار سنتی بر دو دسته ی کلی غیر تکاملی سنتی و تکاملی سنتی هستند.

 

مدل های غیر تکاملی سنتی

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

 

مدل آبشاری

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

 

مدل توسعه سریع RAD

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

 

مکانیزم نمونه سازی دور انداختنی

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

 

مدل نمونه سازی

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

 

مدل های تکاملی سنتی

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

 

مکانیزم نمونه سازی تکاملی

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

 

مدل افزایشی

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

 

مدل پیچشی (مارپیچی یا حلزونی)

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

 

معایب مدل های تکاملی سنتی

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

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

 

مدل توسعه هم روند

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

 

خصوصیات مدل توسعه هم روند

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

 

مدل های فرایند خاص

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

 

مدل توسعه مبتنی بر مولفه ساخت یافته

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

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

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

 

مدل روش های رسمی

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

 

مدل فرایند تولید نرم افزار مدرن(شیء گرا)

مدل فرایند تولید نرم افزار مدرن، به صورت تکاملی مدرن می باشد.

مدل تکاملی مدرن

این مدل مبتنی بر مولفه شیء گرا نام دارد و بر اساس رویکرد تکرار و تکامل می باشد.

مدل توسعه مبتنی بر مولفه شی گرا

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

کلاس کاربردی: مانند کلاس دانشجو که برنامه نویس آن را می نویسد و به دلیل داشتن شرایط قابل حمل به شکل ذاتی، می تواند به عنوان یک قطعه آماده و قابل استفاده مجدد در پروژه بعدی مورد استفاده دوباره قرار بگیرد.

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

 

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

 

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

 

منبع: سایت آی کن