با سلام و درود، در ادامه مجموعه بحث های مهندسی نرم افزار، در این مطلب به فعالیت های فرایند پرداخته شده است. لازم به ذکر است که مطالب از کتاب «مهندسی نرم افزار – سامرویل» توسط خودم ترجمه و گردآوری شده اند. اگر هیچ شناخت اولیه ای در مورد این مطالب ندارید و مشتاق مطالعه در زمینه مهندسی نرم افزار هستید، پیشنهاد می کنم از ابتدا و مقدمه شروع کنید، مطالب قبلی به شرح زیر می باشند:
- مهندسی نرم‌افزار (تکنیک ها و روش ها) – مقدمه – ۱
- مهندسی نرم‌افزار (تکنیک ها و روش ها) – مقدمه – ۲
- مهندسی نرم‌افزار – فرآیند های نرم افزار – ۱ (مدل آبشاری)
- مهندسی نرم‌افزار – فرآیند های نرم افزار – ۲ (مدل افزایشی)
- مهندسی نرم‌افزار – فرآیند های نرم افزار – ۳ (مدل ادغام و پیکربندی)
- مهندسی نرم‌افزار – فعالیت های فرآیند
فعالیت های فرآیند (Process Activities)
فرآیندهای نرم افزار واقعی، دنباله ای در هم تنیده از فعالیت های فنی(technical)، مشارکتی (Collaborative) و مدیریتی هستند که دارای هدف کلی مشخص کردن (Specifying)، طراحی کردن (Designing)، پیاده سازی کردن و تست کردن یک سیستم نرم افزاری می باشد. به طور کلی، فرآیند ها در حال حاضر توسط ابزارها پشتیبانی می شوند. به این معنی که مهندس نرم افزار احتمالا از یک سری نرم افزار و ابزار استفاده می کند که به او کمک می کند، این کمک می تونه در مواردی مانند سیستم های مدیریت نیازمندی ها، ویرایشگر های طراحی مدل، ویرایشگرهای برنامه، ابزارهای تست خودکار و دیباگر ها باشد.
چهار فعالیت پایه فرآیندکه شامل مشخصات (Specification)، توسعه (Develipment)، اعتبارسنجی (Validation) و تکامل (evolution) هستند، در فرآیندهای توسعه مختلف و به طور متفاوت سازمان دهی می شود. در مدل آبشاری، در یک «توالی» سازماندهی می شوند، در حالی که در توسعه افزایشی به صورت «در هم تنیده» سازماندهی می شوند. چگونگی انجام این فعالیت ها بستگی به نوع نرم افزاری که در حال توسعه است، تجربه و شایستگی توسعه دهندگان و نوع سازمانی که نرم افزار را توسعه می دهد، دارد.
مشخصات نرم افزار (۲.۲.۱):
مشخصات نرم افزار یا مهندسی الزامات، فرآیند فهمیدن و تعریف این است که چه خدماتی از سیستم مورد نیاز است و همچنین شناسایی محدودیت ها در عملکرد و توسعه سیستم. مهندسی الزامات مرجله بحرانی و حساسی در فرآیند نرم افزار می باشد، چرا که اگز اشتباهی در این مرحله صورت بگیرد، به ناچار در آبنده منجر به مشکلاتی در طراحی و پیاده سازی سیستم می شود.
قبل از آنکه فرآیند مهندسی الزامات شروع شود، شرکت ممکن است یک نیازسنجی (feasibility) یا یک نطالعه ارزیابی را انجام دهد تا ارزیابی کند که نیازی یا بازاری برای نرم افزار وجود دارد؟ و اینکه از لحاظ حقایق فنی و اقتصادی، نیازی به توسعه نرم افزار هست؟ مطالعات امکان سنجی، مطالعات کوتاه مدت و نسبتا ارزانی هستند که تصمیم برای انجام دادن یا ندادن تجزیه و تحلیل های جزیی تر را اطلاع می دهد.
فرآیند مهندسی الزامات (نیازمندی ها) در شکل زیر نشان داده شده است که هدفش تولید کردن سندی مورد تایید از نیازمندی‌ها می باشد تا سیستمی که نیازهای ذینفعان را بر طرف می کند، مشخص کند. الزامات معمولا در دو سطح از جزییات معرفی می شوند. کاربران نهایی و مشتریان نیاز به یک اظهارنامه سطح بالا از الزامات دارند، توسعه دهندگان سیستم نیاز به مشخصات بسیار جزیی تر از سیستم دارند.
سه فعالیت اصلی در فرآیند مهندسی الزمات وجود دارد:
- استخراج و تجزیه و تحلیل الزامات، این فرآیند استخراج الزامات سیستم از بین مشاهادات سیستم فعلی، مباحثات با کاربران بالقوه و تهیه کنند، آنالیز کار و غیره می باشد. این ممکن است شامل توسعه یک یا چند مدل سیستمی و پروتوتایپ شود. این موارد به فهم سیستم مشخص شده کمک می کند.
- مشخصات نیازمندی ها، مشخصات الزامات فعالیتی است که در آن اطلاعات جمع آوری شده در طی مرحله تجزیه و تحلیل الزامات، داخل سندی ترجمه می شود که مجموعه ای از الزامات را تعریف می کند. این سند احتمالا دو نوع از الزامات را شامل می شود. الزامات کاربر، عبارت های انتزاعی از الزامات سیستم برای مشتری و کاربر نهایی سیستم می باشد؛ الزامات سیستم، تشریحی جزیی تر از عملکرد هایی است که باید ارائه شود.
- اعتبارسنجی الزامات، این فعالیت، الزامالت را از جهت واقع گرایی (Realism)، سازگاری و کامل بودن بررسی می کند. در طی این فرآیند، ارورها در اسناد الزامات به طور اجتناب ناپذیر کشف می شوند. سپس باید جهت رفع این مشکلات، اصلاح شود.
آنالیز الزامات در طی تعریف (definition) و مشخص کردن (specification) ادامه دارد، و الزامات جدید در طول فرآیند مشخص می شوند. در نتیجه فعالیت های آنالیز، تعریف و مشخصات، درهم‌تنیده می باشند.
در روش‌های چابک، مشخص کردن الزامات فعالیتی جدا نمی باشد اما به عنوان قسمتی از توسعه سیستم، دیده شده است. الزامات به طور غیر رسمی برای هر افزایش سیستم درست قبل از اینکه آن افزایش توسعه داده شود در نظر گرفته شده است. الزامات با توجه به اولویت های کاربر مشخص می شوند. استخراج الزامات توسط تیمی صورت می گیرد که قسمتی از کار هستند یا از نزدیک با تیم توسعه دهنده کار می کنند.
طراحی و پیاده سازی نرم افزار (۲.۲.۲)
مرحله پیاده سازی از توسعه نرم‌افزار، فرآیند توسعه دادن یک سیستم قابل اجرا برای تحویل به مشتری می باشد. گاهی اوقات این شامل فعالیت های جداگانه ای از طراحی نرم افزار و برنامه نویسی می باشد. با این حال اگر رویکردی چابک برای توسعه استفاده شده باشد، طراحی و پیاده سازی بدون اینکه اسناد طراحی رسمی در طی فرآیندی تولید شود، درهم تنیده خواهند بود. البته نرم افزار طراحی دشه است، اما طراحی به صورت غیر رسمی روی تخته وایت بورد یا دفترچه یادداشت برنامه نویس ثبت شده است.
یک طراحی نرم افزار، توضیحی از ساختار نرم افزاری که پیاده سازی خواهد شد، مدل های داده و ساختاری که توسط سیستم استفاده می شود، واسط بین اجزای سیستم و گاهی اوقات الگوریتم های مورد استفاده شده، می باشد. طراحان به سرعت به طراحی نهایی نمی رسند، اما طراحی را در چند مرحله توسعه می دهند. آنها جزییات را با ایجاد طراحی پُشته (backtracking)، جهت اصلاح طرح های اولیه، در طول توسعه طراحی اضافه می کنند.
تصویر ۲.۵، مدلی انتزاعی از فرآیند طراحی می باشد که نشان دهنده ورودی های فرآیند طراحی، فعالیت های فرآیند و خروجی های فرآیند می باشد. فعالیت های فرآیند طراحی هم در همتنیده و هم وابسته به هم هستند. اطلاعات جدید درباره طراحی به طور مداوم تولید می شود و این روی تصمیمات قبلی طراحی تاثیر می گذارد. بنابراین دوباره کاری در طراحی اجتناب ناپذیر می باشد.
اکثر نرم افزار ها خط اتصالی با دیگر نرم افزارهای سیستم دارند. این سیستم ها از قبیل سیستم های عامل، پایگاه داده، میان افزارها و دیگر اپلیکیشن های سیستم می باشد. اینها «بستر نرم افزاری – software platform» را تشکیل می دهند، محیطی که نرم افزار در آن اجرا خواهد شد. اطلاعات در مورد این بستر، ورودی ضروری برای فرآیند طراحی می باشد، به طوریکه طراحان باید تصمیم بگیرند چگونه به بهترین شکل آن را با محیط شان یکپارچه کنند. اگر سیستم برای پردازش داده های موجود است، پس توضیحات آن داده ممکن است در مشخصات پلتفرم (بستر) درج شود. در غیر این صورت، توضیحات داده باید به عنوان ورودی برای فرآیند طراحی باشد تا سازماندهی داده سیستم تعریف شود.
بسته به نوع سیستم در حال طراحی، فعالیت ها در فرایند طراحی متنوع می باشند. برای مثال، سیستم های real-time نیازمند به مرحله اضافه ای برای زمان بندی طراحی دارند، اما ممکن است پایگاه داده نداشته باشند و در نتیجه طراحی پایگاه داده نخواهند داشت. شکل ۲.۵ چهار فعالیت را نشان می دهد که ممکن است قسمتی از فرآیند طراحی برای سیستم های اطلاعاتی باشد:
- طراحی معماری، جاییست که شما ساختار کلی سیستم را مشخص می کنید، اجزای اصلی(گاهی اوقات زیرسیستم ها و ماژول ها نیز گفته می شوند)، روابط بین آنها، و اینکه چگونه توزیع می شوند.
- طراحی پایگاه داده ها، جایی که شما ساختار داده های سیستم را طراحی می کنید و اینکه چگونه در پایگاه داده ارائه شوند. مجدد کار در اینجا وابسته به این است که پایگاه داده ای که از قبل وجود داشته را استفاده می کنید یا پایگاه داده جدید در نظر دارید ساخته شود.
- طراحی واسط، جایی که در آن واسط های بین اجزای سیستم تعریف می شود. این مشخصات واسط باید کاملا واضح باشد. با یک واسط دقیق، یک جزء (component) از سیستم ممکن است با دیگر اجزای سیستم ارتباط داشته باشد بدون اینکه بداند دگری چگونه پیاده شده است. پس از توافق مشخصات واسط ها، اجزا می توانند جداگانه طراحی و توسعه داده شوند.
- انتخاب اجزا و طراحی، زمانی که شما برای اجزای با قابلیت استفاده مجدد جستجو انجام می دهید، اگر جزء(کامپوننت) مناسب در دسترس نباشد، یک جزء نرم افزاری جدید را طراحی می کنید. طراحی در این مرحله ممکن است توضیخ ساده ای از کامپوننت با جزییات پیاده سازی در اختیار توسعه دهنده باشد. از طرف دیگرممکن است لیستی از تغییرات که باید روی کامپوننت قابل استفاده مجدد انجام شود باشد یا یک مدل طراحی با جزییات تشریح شده در UMLباشد. سپس ممکن است مدل طراحی (design model) به صورت خودکار جهت ایجاد یک پیاده سازی استفاده شود.
این طراحی ها منجر به خروجی های طراحی می شوند، که در شکل ۲.۵ نیز نشان داده شده است. برای سیستم های بحرانی، خروجی فرآیند طراحی، اسناد و تنظیمات جزیی و دقیق طراحی هستند که توصیف دقیق، صحیح و واضحی را از سیستم ارائه می دهند. اگر از رویکر model-driven استفاده شده است (بعدا توضیح داده خواهد شد – فصل ۵ کتاب). خروجی های طراجی دیاگرام های طراحی هستند. اگر روش چابک استفاده شده باشد، خروپجی های فرآیند طراحی اسناد توصیفی جدا از هم نیستند اما ممکن است توسط کُدی از برنامه ارائه شوند.
توسعه یک برنامه (program) جهت پیاده سازی یک سیستم طبیعتا از طراحی سیستم پیروی می کند. گرچه بعضی از کلاسهای برنامه، همانند سیستم های ایمنی-بحرانی (safety-critical systems)، معمولا قبل از شروع پیاده سازی، با جزییات تعریف می شوند، این برای طراحی و توسعه program خیلی رایج تر می باشد. ممکن است از ابزارهای توسعه نرم افزار برای تولید یک برنامه skeleton از روی طراحی، استفاده شوند. این شامل کُد جهت تعریف و پیاده سازی واسط ها (interface) می شود، و در خیلی از موارد، توسعه دهنده فقط نیاز دارد که جزییات عملکرد هر کامپوننتی از برنامه را اضافه کند.
برنامه نویسی یک فعالیت فردی است، و فرآیند جامعی که به طور معمول دنبال شود نیز وجود ندارد. بعضی از برنامه نویس ها با کامپوننت هایی که ان را درک کرده اند شروع می کنند، اینها را توسعه می دهند و سپس به کامپوننت هایی که درک کمتری از آنها دارند می پردازند. باقی، رویکرد برعکس را پیش می گیرند، کامپوننت هایی که به آنها آشنایی دارند را کنار می گذارند، زیرا که می دانند که چطور آنها را توسعه دهند. بعضی از توسعه دهنده ها علاقه دارند که داده ها را در مراحل اولیه تعریف کنند و سپس از آنها برای هدایت توسعه برنامه استفاده کنند. باقی تا جایی که ممکن باشد تعریف داده ها را به عقب می اندازند.
به طور معمول برنامه نویس ها تعدادی تست از کدهایی که توسعه داده اند انجام می دهند. این اغلب باگ های برنامه که باید از برنامه حذف شوند را نشان می دهد. پیدا کردن و تعمیر کردن مشکلات برنامه را دیباگینگ (دیباگ کردن – debugging) می گویند. تست کردن مشکلات و دیباگ گیری دو فرآیند متفاوتی هستند. تست کردن وجود مشکل/نقص را نشان می دهد. دغدغه دیباگینگ پیدا کردن و اصلاح این نواقص می باشد.
زمانی که دیباگ گیری می کنید، شما باید فرضیه هایی را برای رفتار قابل مشاهده برنامه ایجاد کنید و سپس به امید پیدا کردن نقص هایی که منجر به ناهنجاری خروجی می وشند، این فرضیه ها را تست کنید. تست کردن فرضیه ها ممکن است شامل trace کردن به صورت دستی برنامه باشد. ممکن است برای متمرکز کردن مشکل به نمونه های آزمایشی بیشتری نیاز داشته باشد. ابزارهای دیباگ گیری تعاملی، که مقادیر متوسط از متغیرهای برنامه و یک trace از اظهارات اجرا شده را نشان می دهد، معمولا برای پشتیبانی از دیباگ کردن به کار گرفته می شوند.
اعتبار سنجی نرم افزار (۲.۲.۳)
اعتبار سنجی نرم افزار یا به طور رایج تر، تایید Verification و اعتبارسنجی Validation یا (V & V) قصد دارد تا نشان دهد که یک سیستم هم با مشخصات خودش مطابقت دارد و هم انتظارات مشتری سیستم را برآورده می کند. تست کردن برنامه (Program) (دلیل استفاده چندین باره از معادلات انگلیسی به دلیل رایج بودن بیش از حد عبارات لاتین در بین برنامه نویسان و نا آشنایی آنها با معادل فارسی می باشد). تست برنامه، زمانی که سیستم با استفاده از داده های تست شبیه سازی شده اجرا می شود، تکنیک اصلی اعتبارسنجی می باشد. اعتبار سنجی همچنین ممکن است شامل فرآیند های بررسی شود، مانند بازرسی ها و مرورها در هر مرحله از فرآیند نرم افزار از تعریف نیازمندی های کاربر گرفته تا توسعه برنامه. گرچه بیشتر وقت و تلاش V & V روی تست کردن برنامه مصرف می شود.
به جز برنامه های کوچک، سیستم ها نباید به عنوان یک واحد مجرد و یک پارچه تست شوند. تصویر ۲.۶ فرآیند تست کردن سه مرحله ای را نشان می دهد که کامپوننت های سیستم به صورت جداگانه تست می شود، سپس سیستم به صورت یکپارچه تست می شود. برای نرم افزار های سفارشی، تست کردن مشتری شامل تست کردن سیستم با داده های حقیقی مشتری می شود. برای محصولاتی که به عنوان اپلیکیشن فروخته می شوند، تست مشتری گاهی تست بتا نامیده می شود که کاربران مشخص نرم افزار را تست می کنند و در مورد آن اظهار نظر می کنند.
مراحل در فرآیند تست عبارتند از :
- تست کردن کامپوننت ها، اجزای سازنده ی سیستم توسط خود افرادی که سیستم را توسعه داده اند تست می شود. هر کامپوننت به طور مستقل، بدون سایر اجزای سیستم تست می شود. کامپوننت ها ممکن است موجودیت های ساده ای چون توابع(Function) یا اشیاء کلاس ها و یا گروه بندی منسجمی از این موجودیت ها باشد. ابزارهای تست خودکار همچونJunit برای جاوا، که می توانند برای هر ورژن جدیدی از کامپوننت ها دوباره تست شوند، به صورت خیلی رایج استفاده می شوند (Koskela 2013).
- تست کردن سیستم، کامپوننت های سیستم جهت ایجاد یک سیستم پیچیده یکپارچه شده اند. این فرآیند دغدغه اش پیدا کردن ارورهایی است که از تقابل غیر منتظره بین کامپوننت ها و مشکلات واسط های کامپوننت منجر می شوند. همچنین نگرانی ای با نشان دادن اینکه سیستم به الزامات کارکردی و غیر کارکردی اش عمل می کند و تست ویژگی های نوظهور سیستم، دارد.
- تست کردن مشتری، این آخرین مرحله در فرآیند تس قبل از اینکه سیستم برای استفاده عملیاتی تایید شود، می باشد. سیستم به جای تست شدن با داده های تست شبیه سازی شده، توسط مشتریان سیستم تست می شود (یا مشتریان بالقوه). برای نرم افزار های سفارشی (به سفارش مشتری)، تست ممکن است خطاها و اشکالات موجود در تعریف الزامات سیستم را نشان دهد، زیرا داده های واقعی، سیستم را به روش متفاوتی از داده های تست، آزمایش می کنند. تست مشتری ممکن است همچنین مشکلات الزامات را نشان دهد که امکانات فعلی سیستم، واقعا نیازهای کاربران را رفع نمی کند یا کارایی سیستم قابل پذیرش نباشد. برای محصولات، تست مشتری نشان می دهد که چگونه محوصل نرم افزاری نیازهای مشتری را برآورده می کند.
به طور معمول تست کردن کامپوننت ها قسمتی ساده از فرآیند توسعه نرم افزار می باشد. برنامه نویس ها تست های خودشون رو آماده می کنند و به صورت افزایشی همانطور که توسعه انجام می شود، تست ها را انجام می دهند. برنامه نویسان کامپوننت ها را می شناسند و در نتیجه بهترین شخص برای تولید test case برای آنها هستند.
اگر از رویکرد افزایشی برای توسعه استفاده شود، هر افزایش (increment) به محض توسعه داده شدن باید تست شود، بر مبنای نیازمندی های آن increment باید تست شوند. در توسعه تست-محور (test-driven) که قسمتی معمول از فرآیندهای چابک می باشد، تست در کنار الزامات قبل از شروع توسعه انجام می شود. این به توسعه دهنده ها و. تست کننده ها کمک می کند تا الزامات را درک کنند و تضمین می کند که با ایجاد test case ها تاخیری ایجاد نمی شود.
زمانی که فرآیند نرم افزار برنامه-محور (plan-driven) استفاده می شود (به عنوان مثال برای توسعه سیستم های بحرانی)، تست با مجموعه ای از برنامه های تست انجام می شود. تیم مستقلی از تست کننده ها روی برنامه تست، فعالیت می کنند. تصویر ۲.۷ نشان می دهد که چگونه «برنامه های تست» ارتباط بین تست کردن و فعالیت های توسعه می باشد. این گاهی اوقات مدل توسعه V نامیده می شود (V-model). V-model فعالیت های اعتبارسنجی نرم افزار را نشان می دهد که مطابق با هر مرحله از مدل فرایند آبشاری می باشد.
زمانی که سیستمی به عنوان محصول نرم افزاری به بازار ارائه می شود، فرآیند تست کردن Beta Testingنامیده می شود. «تست کردن بتا» شامل تحویل سیستم به تعدادی از مشتریان بالقوه که موافق استفاده از نرم افزار هستند می باشد. آنها مشکلات را به توسعه دهندگان سیستم گزارش می دهند. این کار منجر می شود ارورهایی که توسط دولوپر ها قابل شناسایی نبودند شناسایی شوند. بعد زا این بازخورد، محصول نرم ازفری ممکن از اصلاح شود و برای «تست کردن بتا»ی بیشتر مجدد منتشر شود.
تکامل نرم افزار (۲.۲.۴)
انعطاف پذیری نرم افزار یکی از دلیل های اصلی این است که چرا نرم افزارهای بیشتری در سیستم‌های بزرگ و پیچیده گنجانده می شوند. هنگامی که تصمیمی برای ساخت سخت افزار گرفته می شود، ایجاد تغییر در طراحی سخت افزار بسیار گران تمام می شود. گرچه تغییر در نرم افزار در هر زمانی بهنگام توسعه یا پس از توسعه نرم افزار امکان پذیر است. حتی تغییرات گسترده خیلی کم هزینه تر از تغییر در سیستم سخت افزاری می باشد.
از نظر تاریخی، همیشه بین روند توسعه نرم افزار و روند تکامل نرم افزار (نگهداری نرم افزار)، شکافی وجود داشته است. مردم فکر می کنند توسعه نرم افزار فعالیت خلاقانه می باشد که در آن نرم افزار از مفاهیم پایه ایجاد و به حالت اجرایی می رسد و از طرفی گاهی اوقات فکر می کنند نگهداری نرم افزار کاری کسل کننده و بدون علاقه می باشد. آنها فکر می کنند نگهداری نرم افزار چالش های کمتری نسبت به توسعه اولیه نرم افزار دارد.
این تمایز بین توسعه و نگهداری به طور فزاینده ای بی ربط می باشد. سیستم های نرم افزاری خیلی کمی سیستم های جدید محسوب می شوند و همینجاست که باید توسعه و نگهداری را به عنوان یک زنجیره نگاه کنیم. به جای آنکه دو فرآیند جدا در نظر بگیریم، واقع بینانه تر است که درمورد مهندسی نرم افزار به عنوان یک فرآیند تکاملی(شکل ۲.۸) فکر کنید که نرم افزار به طور ادامه دار در طول عمر خود با توجه به تغییر الزامات و نیازهای مشتری، تغییر می کند.
خب تا اینجای کار بخش دوم از فصل دوم کتاب سامرویل به پایان رسید، در قسمت بعدی به بخش سوم خواهم پرداخت. فایل PDF فارس و ترجمه شده متاب مهندسی نرم افزار سامرویل در پایان بخش سوم (کپی کردن و تغییر) قرارداده شده است.