با نام خدا وسلام، رسیدیم به قسمت سوم از مجموعه مطالب مهندسی نرم افزار – تکنیک ها و روش ها، دو قسمت قبلی آموزش رو از زیر می توانید پیگیری کنید:
در این قسمت و قسمت بعدی در مورد فرآیندهای نرم افزار صحبت خواهم کرد، همان طور که در قسمت اول هم ذکر کردم، مرجع اصلی مطالب، کتاب مهندسی نرم افزار سامرویل ویرایش دهم می باشد.
اهداف قسمت۳ و ۴ آموزش :
- فهم درک فرآیندهای نرم افزار و مدل های فرآیند نرم افزار
- با سه مدل فرآیند نرم افزار و زمان استفاده از آنها آشنا می شویم
- آشنای با فعالیت های اساسی فرآیند در مهندسی الزامات نرم افزار، توسعه نرم افزار، تست نرم افزار و تحول در نرم افزار
- متوجه می شویم که چرا فرآیندها باید برای مقابله با تغییرات در الزامات و طراحی نرم افزار سازماندهی شوند.
- درک نظریه بهبود فرآیند های نرم افزار و فاکتورهایی که بر کیفیت فرآیند نرم افزار تاثیر می گذارند.
فرآیند های نرم افزار:
یک فرایند نرم افزاری مجموعه ای از فعالیت های مرتبطی است که منجر به تولید یک سیستم نرم افزاری می شود. همانطور که قبلا گفته شد، انواع مختلف سیستم های نرم افزاری وجود دارد و یک روش مهندسی نرم افزار جامع که برای همه قابل استفاده باشد، وجود ندارد. در نتیجه فرآیند نرم افزار جامع نیز وجود خارجی ندارد. فرآیندی که در شرکت های مختلف استفاده می شود، بستگی به موارد پیش رو دارد: نوع نرم افزاری که توسعه د داده میشود، الزامات نرم افزار مشتری و مهارت های افرادی که نرم افزار را می نویسند.
چهار فعالیت اساسی مهندسی نرم افزار که در قسمت های قبلی هم گفته شد، از قرار زیر هستند:
- مشخصات نرم افزار: عملکرد نرم افزار و محدودیت های روی عملیات آن باید مشخص باشند.
- توسعه نرم افزار : نرم افزار برای پاسخگویی به مشخصات، باید پیاده سازی شود.
- اعتبار سنجی نرم افزار : نرم افزار باید اعتبار سنجی شود تا اطمینان حاصل شود همان چیزیست که مشتری می خواسته.
- تحول نرم افزار : نرم افزار در برابر تغییرات مورد نظر مشتری، باید امکان تحول را داشته باشد.
فعالیت های فوق به نوبه ی خود پیچیده می باشند و دارای زیر فعالیت هایی همچون اعتبارسنجی الزامات، طراحی معماری و unit testing می شود. فرآیندها همچنین دارای فعالیت های دیگری مانند مدیریت پیکربندی نرم افزار و برنامه ریزی پروژه که فعالیت های تولید را پشتیبانی کند، است.
وقتی در مورد فرآیندها بحث می کنیم، ما معمولا در مورد فعالیت های داخل این فرآیندها از جمله تعیین کردن Data Model ، طراحی واسط کاربری و چینش این فعالیت ها صحبت می کنیم. زمانی که فرآیندها را تشریح می کنیم، مهم هست که تشریح کنیم چه کسی درگیر است، چه تولید می شود و شرایطی که دنباله فعالیت ها را تحت تاثیر قرار می دهند، بیان کنیم:
- محصولات یا نتایج تحویلی، خروجی های فعالیت فرآیند می باشد. برای مثال، خروجی فعالیت طراحی معماری ممکن است مدلی از معماری نرم افزار باشد.
- نقش ها نشانگر مسئولیت های افراد درگیر در فرآیند می باشد. برای مثال نقش های مدیر پروژه، مدیر پیکربندی و برنامه نویس
- پیش و پس شرطها، شرایطی هستند که باید در قبل و بعد از تصویب فعالیت فرآیند یا تولید نرم افزار منعقد شوند. برای مثال قبل از شروع طراحی معماری، پیش شرط میتونه این باشه که مصرف کننده (مشتری) تمام نیازمندی ها را تایید کرده باشد، بعد از اینکه این فعالیت تمام شد، پس شرط میتونه این باشه که مدل های تشریح کننده معماری باید مرور شده باشند.
فرایند های نرم افزاری پیچیده هستند و شبیه تمام فرآیند های فکری و خلاق، به افرادی که تصمیم گیری و قضاوت می کنند متکی می باشد. همانطور که فرایند جامع ای که رای همه نوع نرمافزار مناسب باشد، وجود ندارد، اکثر شرکت های نرم افزاری فرایندهای توسعه نرم افزار خود را توسعه داده اند. فرایند بر اساس قابلیت های توسعه دهندگان نرم افزار در سازمان و ویژگیهای نرم افزاری که در حال توسعه است، متحول می شود. برای سیستم های دارای اهمیت ایمنی safety-critical یک فرآیند توسعه بسیار ساختاریافته نیاز است که حفظ سوابق تفصیلی صورت گیرد. برای سیستم های بیزینسی ، که الزامات ب سرعت تغییر می کنند، یک فرآیند انعطاف پذیرتر و چابک به نظر بهتر می باشد.
توسعه نرمافزار حرفه ای، یک فعالیت مدیریت شده است، بنابراین برنامه ربزی بخشی ذاتی از کلیه فرایند ها می باشد. فرآیند های برنامه-محور (Plan-driven) فرآیندهایی هستند که تمام فعالیت های فرآیند به صورت پیشرفته برنامه ریزی شده و روند پیشرفت در مقابل این برنامه، اندازه گیری می شود. در فرآیند چابک (agile ) که بعدا تشریح می کنیم، برنامه ریزی به طور افزایشی و مداوم در طول توسعه نرم افزار می‌باشد. بنابراین آسان‌تر هست تا فرآیند را مطابق با تغییر مشتری یا الزامات محصول، تغییر دهیم. همان طور که Boehm و Turner توضیح دادند، هر رویکردی برای انواع مختلف نرم افزار مناسب می باشد. برای سامانه های بزرگ نیاز به بالانسی بین فرآیند های چابک و برنامه-محور دارید.
مدل های فرآیند نرم افزار
یک مدل فرایند نرم افزار (گاهی اوقات آن را سیکل زمانی توسعه نرم افزار می نامند یا مدل SDLC) ارائه ای ساده از فرآیند نرم افزار می باشد. هر مدل فرآیند، فرایند را در چشم انداز مشخصی ارائه می کند و در نتیجه تنها مقداری اطلاعات در مورد فرياند فراهم می کند. برای مثال یک process activity model فعالیت های و ت، اما نقش افراد داخل این activity ها را نشان نمی دهد. در این قسمت، به معرفی تعدادی مدل فرآیند عام (گاهی اوقات process paradigms هم گفته می شوند) پرداخته می شود و از چشم انداز معماری به آنها نگاه می کنیم. چارچوب فرایند را خواهیم دید اما جزییات فعالیت های فرایند را خیر. مدل های فرآیند که در ادامه به آنها می پردازیم از قرار زیر هستند:
- مدل آبشاری (WaterFall Model) : این مدل فعالیت های اساسی فرآیند را از مشخصات، توسعه، اعتبارسنجی و تحول را گرفته و آنها را به عنوان فاز فرایند جداگانه ای همانند مشخصات الزامات و طراحی نرم افزار، ارائه می دهد.
- توسعه افزایشی (Incremental development): این رویکرد، فعالیت های مشخصات، توسعه و اعتبار سنجی را جاگذاری می کند. سیستم به عنوان یک سری از ورژن ها (افزایشی) توسعه داده می شود، که هر ورژن به ورژن قبلی عملکردی را اضافه می کند.
- ادغام و پیکربندی (Integration and configuration)، این رویکرد متکی بر در دسترس بودن اجزا یا سیستم های قابل استفاده مجدد می باشد. فرایند توسعه نرم افزار تمرکز بر پیکربندی این اجزا برای استفاده در تنظیمات جدید و ادغام آنها در سیستم می باشد.
RUP یا Rational Unified Process عناصر تمامی مدل های فرآیند توضیح داده شده در اینجا را گرد هم می آورد و از نمونه سازی و تحویل افزایشی نرم افزار پشتیبانی می کند. RUP معمولا از سه منظر تشریح می شود: چشم انداز پویا که فازهای مدل را در زمان نشان می دهد، چشم انداز ایستا که فعالیت های فرآیند را نشان می دهد و چشم انداز عملی که عمل های خوب را جهت استفاده در فرآیند، پیشنهاد می دهد. فازهای RUP :
- هنگامی شروع می شود که یک پرونده تجاری برای سیستم ایجاد شده باشد.
- و زمانی که الزامات و معماری توسعه داده شده باشد، تشریح می شود.
- و زمانی که نرم افزار اجرا شده باشد، ساخته می شود.
- و زمانی که سیستم مستقر شده باشد، متحول و منتقل می شود.
همانطور که قبلا گفته شد مدل فرآیند جامع ای وجود ندارد که برای همه انواع توسعه نرم افزار جوابگو باشد. فرآیند درست بستگی به مشتری، الزامات تنظیمی و محیطی که نرم افزار در آن استفاده خواهد شد، دارد. برای مثال، نرم افزار safety-critical معمولا برای توسعه به دلیل آنکه قبل از شروع به پیاده سازی به آنالیز و اسناد زیادی نیاز دارد از فرآیند آبشاری استفاده می کند. محصولات نرم افزاری در حال حاضر همیشه از مدل فرآیند افزایشی استفاده می کنند. و سیستم های تجاری بیشترشان بت پیکربندی سیستم موجود توسعه داده می شوند و با یکپارچگی یک سیستم جدید را با عملکری که مورد انتظارشان هست می سازند.
اکثر فرایند های نرم افزار کاربردی، مبتنی بر یک مدل عمومی هستند اما اغلب، ویژگی سایر مدل ها را شامل می شوند. این به ویژه برای مهندسی سیستم های بزرگ صادق است. برای سیستم های بزرگ، ترکیب بعضی از بهترین ویژگی های تمامی فرآیند های رایج احساس می شود. شما برای طراحی یک نرم افزار نیاز دارید که اطلاعاتی درباره الزامات ضروری سیستم داشته باشید. زیرسیستم ها در یک سیستم بزرگ ممکن است با رویکردهای متفاوت توسعه داده شوند. قسمتی از سیستم که به خوبی درک شده است می تواند با فرآیند آبشاری توسعه داده شود یا ممکن است به عنوان سیستم های off-the-shelf (محصول سخت افزار یا نرم افزار با تولید انبوه) برای پیکربندی خریداری شود. دیگر قسمت های سیستم که معلوم کردنشان به صورت پیشرفته سخت می باشد، همیشه باید به صورت رویکرد افزایشی توسعه داده شوند. در هر دو مورد، به احتمال زیاد اجزای نرم افزار استفاده مجدد می شوند.
تلاش های مختلفی برای آنکه یک مدل فرآیند جامع توسعه بدهند تا روی همه این مدل های عام قابل ترسیم باشد، شده است. یکی از بهترین های شناخته شده از این مدل های جامع Rational Unified Process (RUP) می باشد. RUP مدلی انعطاف پذیر است که میتوان از آن به روش های مختلفی نمونه و مثال آورد که متشابه هر کدام از مدل های فرایند عام توضیح داده شده در اینجا باشد. RUP توسط برخی از شرکت های بزرگ نرم افزاری از جمله IBM به تصویب رسیده است، منتهی به طور گسترده از آن استقبال نشده است.
مدل آبشاری:
اولین مدل منتشر شده از فرآیند توسعه نرم افزار، از مدل های فرآیند مهندسی که در مهندسی سیستم های بزرگ جنگی/نظامی استفاده می شده اند، حاصل شده است. این مدل، فرایند توسعه نرم افزار را به عنوان تعدادی مرحله ارائه می دهد که در تصویر ۲.۱ نشان داده شده است. به دلیل پی در پی بودن هر فاز با فاز دیگر، این مدل مدل آبشاری یا سیکل زمانی نرم افزار نامیده شده است. مدل آبشاری مثالی از یک فرایند برنامه ریزی شده (مبتنی بر برنامه) می باشد. در اصل، شما قبل از شروع توسعه نرم افزار باید تمامی فعالیت های فرآیند را برنامه ریزی کرده باشید.
مراحل مدل آبشاری مستقیما فعالیت های اساسی توسعه نرم افزار را منعکس می کند:
- تعیین و تحلیل نیازمندی ها (Requirements analysis and definition)، خدمات، محدودیت ها و اهداف سیستم با مشورت کاربران سیستم معین می شود. آنها سپس به طور جزیی تعریف شده و به عنوان مشخصات سیستم به کار گرفته می شوند.
- طراحی سیستم و نرم افزار (System and software design)، فرایند طراحی نرم افزار الزامات را به سخت افزار یا سیستم های نرم افزاری تخصیص می دهد و یک معماری کلی سیستم را ایجاد می کند. طراحی نرم افزار شامل شناسایی و توصیف انتزاعات اساسی سیستم نرم افزاری و روابط آنها می باشد.
- پیاده سازی و تست واحد (Implementation and unit testing) در طی این مرحله، طراحی نرم افزار به عنوان مجموعه ای از برنامه ها یا واحد های برنامه تحقق می یابد. تست واحد شامل تاییدیه این است که هر واحد مشخصات خود را برآورده کند.
- یکپارچگی و تست سیستم (Integration and system testing) واحد های برنامه فردی یا برنامه ها به عنوان یک سیستم کامل، یکپارچه و تست می شوند تا اطمینان حاصل شود که الزامات نرمافزار برآورده شده است. پس از تست، سیستم نرم افزاری به مشتری تحویل داده می شود.
- بهره برداری و نگهداری (Operation and maintenance) به طور معمول طولانی ترین مرحله چرخه زندگی، این مرحله است. سیستم نصب شده و مورد استفاده عملی قرار می گیرد. نگهداری شامل تصحیح خطاهایی که در مراحل قبلی چرخه زندگی کشف نشده اند می پردازد و عملکرد واحد های سیستم را بهبود می بخشد و خدمات سیستم را به عنوان الزامات تازه کشف شده، ارتقا می دهد.
مدل فرآیند اسپیرال (Spiral) : مدل فرآیند افزایشی است که بر محور ریسک می باشد. فرآیندها به عنوان یک مارپیچ ارائه می شوند نه به صورت دنباله ای از فعالیت ها.
هر حلقه در مارپیچ، مرحله ای از فرآیند نرم افزار را نشان می دهد. بنابراین حلقه درونی احتمالا دغدغه اش با امکان سنجی سیستم می باشد، حلقه بعدی مشغول تعریف الزامات می شود، حلقه بعد طراحی سیستم و همین طور ادامه دارد. مدل اسپیرال اجتناب از تغییر را با تحمل تغییر ترکیب می کند. فرض بر این است که تغییرات، نتیجه ریسک های پروژه است و شامل فعالیت های مدیریت صریح ریسک جهت کاهش این ریسک ها می باشد.
در اصل، نتیجه هر مرحله از مدل آبشاری یک یا تعداد بیشتری سند است که تایید شده اند. مرحله بعد تا زمانی که مرحله قبل تمام نشود، شروع نمی شود. این مورد برای توسعه سخت افزاری، که شامل هزینه ها زیاد تولید می باشد، حساس است. گرچه برای توسعه نرم افزار، این مراحل با هم همپوشانی دارند و اطلاعات را به بکدیگر می دهند. در طی طراحی، مشکلات با الزامات شناسایی می شوند: در طی کد زدن مشکلات طراحی پیدا می شوند و … . فرآیند نرم افزار، در عمل، هرگز یک مدل خطی ساده نمی باشد، اما شامل بازخورد از مرحله ای به مرحله دیگری می باشد.
با ظهور اطلاعات جدید در مرحله فرآیند، اسناد تولید شده در مرحله قبل، باید اصلاح شوند تا تغییرات مورد نیاز سیستم را منعکس کند. برای نمونه، اگرکشف شود که اجرای الزام مشخصی، خیلی هزینه دارد، اسناد الزامات باید تغییر کند تا آن الزام حذف شود. گرچه این کار، نیازمند تایید مشتری می باشد و روند کلی توسعه را تاخیر می اندازد.
به عنوان نتیجه هر جفت توسعه دهنده ها و مشتریان، ممکن است مشخصات سیستم را ثابت کنند (فریز کردن) و در نتیجه هیچ تغییری در آن نتوان ایجاد کرد. متاسفانه این بدان معنی است که مشکلات برای مسائل بعدی، مسائل در نظر گرفته نشده یا مسائل برنامه ریزی شده، همچنان باقی می باشد. ثابت کردن (فریز کردن) الزامات به صورت زودرس، ممکن است به این معنی باشد که سیستم آنچه را که کاربر می خواهد انجام نخواهد داد.
در طی مرحله سیکل زمانی پایانی، (مرحله عملیات و نگهداری)، نرم افزار در حالت استفاده قرار می گیرد. خطا و اشکالات موجود در الزامات نرم افزار اصلی کشف می شوند. خطاهای برنامه و طراحی پدیدار می شوند، و نیاز به قابلیت های جدید تشخیص داده می شود. بنابراین سیستم باید متحول شود تا مفید بماند. انجام این تغییرات (نگهداری نرم افزار) ممکن است شامل تکرار مراحل قبلی فرآیند باشد.
در واقعیت، نرم افزار باید انعطاف پذیر باشد و همانطور که توسعه می بیابد، تغییرات را تطبیق دهد. نیاز به تعهد اولیه و دوباره کاری سیستم بهنگام ایجاد تغییرات به این معنی است که مدل آبشاری فقط برای برخی از انواع سیستم ها مناسب است:
- سیستم های توزیع شده که نرم افزار باید ارتباط با سیستم سخت افزاری داشته باشد. به دلیل انعطاف پذیر نبودن سخت افزار، معمولا ممکن نیست تصمیم گیری در مورد عملکرد نرم افزار را تا زمان اجرای آن، به تاخیر انداخت.
- سیستم های بحرانی از آنجا که به ایمنی و تحلیل امنیت گسترده از طراحی و مشخصات نرم افزار نیاز است. در این سیستم ها، اسناد مرتبط با مشخصات و طراحی باید کامل باشند تا انجام این تحلیل ها ممکن باشد. حل مشکلات مرتبط با ایمنی در مشخصات و طراحی، معمولا در ز مان اجرا بسیار پر هزینه می باشد.
- سیستم های نرم افزاری بزرگ که قسمتی از سیستم های مهندسی گسترده ای هستند که توسط چندین شرکت توسعه یافته اند. سخت افزار موجود در سیستم ممکن است با استفاده از مدل مشابه توسعه داده شده باشد، و شرکت ها دریافته باشند که استفاده از یک مدل مشترک برای سخت افزار و نرم افزار راحت تر است. علاوه بر این، درحالی که چندین شرکت درگیر هستند، مشخصات کاملی ممکن است مورد نیاز باشد تا امکان توسعه مستقل زیر سیستم های مختلف فراهم شود.
مدل آبشاری در شریطی که ارتباط تیمی غیر رسمی ممکن می باشد و الزامات نرم افزار به سرعت تغییر می کند، مدل فرآیند مناسبی نمی باشد. توسعه تکراری (Iterative) و متدهای چابک (agile) برای این سیستم ها بهتر می‌باشد.
یک نوع مهم از مدل آبشاری، توسعه سیستم رسمی می باشد که یک مدل ریاضی از مشخصات سیستم ایجاد می شود. سپس این مدل با استفاده از تحولات ریاضی که قوام (consistency) آن را حفظ می کند، به کد قابل اجرا (executable code) اصلاح می شود. فرآیندهای توسعه رسمی، مانند آنچه مبتنی بر روش B بود (Abrial 2005, 2010)، اکثرا در توسعه سیستم های نرم افزاری ای استفاده می شوند که دارای ایمنی، قابلیت اعتماد و الزامات امنیتی دقیقی هستند. رویکرد رسمی، تولید وضعیت های امنیتی و ایمنی را ساده کرده است. این به مشتری یا تنظیم کننده نشان می دهد که سیستم بالفعل الزامات امنیتی و ایمنی خود را برآورده می کند. گرچه به دلیل هزینه زیاد توسعه مشخصات رسمی ، این مدل توسعه بندرت استفاده می شود بجز برای مهندسی سیستم های بحرانی.