معیارهای طراحی ماژولار نرم افزار

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

 معیارهای طراحی ماژولار نرم افزار عبارتنداز:      

• استقلال عملکردی

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

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

♦ همبستگی

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

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

♦ جفت شدن

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

• روشهای نوآوریی برای طراحی ماژولار نرم افزار موثر:

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

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

    سعی شود محدوده تاثیر یک ماژول در محدوده کنترلی آن ماژول قرار داشته باشد.

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

    ماژولها باید به نحوی تعریف شوند که عملیات آنها قابل پیش بینی باشند.

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

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

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

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

روشهای تست نرم افزار:

♦ تست جعبه سفید (White-Box test)

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

    تمامی مسیرهای کنترلی مستقل در کد یک قطعه حداقل یکبار تست شده باشند.

    تمامی تصمیم گیری های منطقی (if) براساس درست یا نادرست بودن شرط آن تست شده باشند.

    تمامی حلقه های تکرار (loop) در محدوده تکرار و ابتدا و انتهای شرط حلقه تست شده باشند.

    تمامی ساختارهای داده ای داخلی از جهت اعتبارسنجی وارسی شده باشند.

♦ تست مسیرهای بنیادی (Basic Path Testing)

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

♦ تست ساختارهای کنترلی

این روش شرطهای منطقی (if) موجود در برنامه را تست می کند. شرطها می توانند به انواع مختلفی باشند:

    شرط ساده، یک متغیر بولی.

    عبارات رابطه ای، عباراتی با عملگرهای رابطه ای < و  =<و = و =<  و<.

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

♦ تست حلقه

حلقه ها عناصر مهم وسازنده اغلب الگوریتم هایی هستند که در نرم افزار بکار میروند. برای یک حلقه ساده که حداکثر n مرتبه باید انجام شود تستهای زیر را میتوان انجام داد:

    بطور کلی از روی حلقه بگذریم.

    حلقه تنها یک مرتبه انجام گردد.

    حلقه دو مرتبه انجام گیرد.

    حلقه m مرتبه انجام گیرد (n>m).

    حلقه n-1 و n+1 مرتبه انجام شود.

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

♦ تست جعبه سیاه (Black-Box Testing)

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

    عملیات اشتباه و یا از قلم افتاده.

    خطاهای موجود در واسطها.

    خطاهای موجود در ساختارهای داده ای و دسترسی به پایگاه داده ای خارجی.

    خطاهای رفتاری یا اشتباهات از نظر کارایی.

    اشتباه در مقداردهی اولیه و یا کارهای اختتامی.

♦ تقسیم بندی به گروههای هم ارز

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

♦ تحلیل مقادیر مرزی

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

♦ تست تشابه

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

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

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

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

مفاهیم نگهداری نرم افزار:

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

♦ نگهداری تصحیحی

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

♦ نگهداری تطبیقی

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

♦ نگهداری تکمیلی

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

♦ نگهداری پیشگیری کننده

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

در نگهداری نرم افزار مسائل مختلفی از جمله روش انجام، هزینه ها، مسائل و مشکلات، قابلیت نگهداری نرم افزار و تاثیرات جانبی مطرح میگردند:

♦ ساخت یافتگی نگهداری

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

♦ هزینه های نگهداری

معمولا 60 درصد از تلاشهای سازمانی نرم افزار صرف نگهداری می شود. یعنی هزینه بسیار زیادی را باید صرف نگهداری نمود.گاهی این فعالیتها به دلیل راضی نشدن مشتری است که می توانند منجر به از دست دادن شانسهای جدید برای توسعه نرم افزار گردند.

♦ مشکلات نگهداری

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

♦ قابلیت نگهداری نرم افزار

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

♦ تاثیرات جانبی نگهداری

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

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

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

طیف مدیریت

بصورت خلاصه، در هر کدام از چهار بعد فوق، اعمال زیر انجام میگیرد:

► افراد : استخدام، انتخاب، مدیریت کارایی، آموزش، پاداش، توسعه شغلی، سازمان، طراحی کار، توسعه تیمی – فرهنگی.

► محصول : اهداف محصول، حوزه، راه حل های جایگزین، سبک سنگین کردن محدودیتها.

► فرآیند : فعالیت های چارچوبی مملو از وظایف، نقاط مهم، محصولات کاری، نقاط تضمین کیفیت.

► پروژه : طرح ریزی، پایش، کنترل.

افراد

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

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

محصول

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

حوزه پروژه (Scope) : اولین فعالیت مدیریتی پروژه نرم افزاری، تعیین حوزه نرم افزاری است. حوزه را میتوان با پاسخ به سوالات زیر تعریف کرد:

► زمینه : نرم افزار چگونه در سیستم بزرگتری قرار میگیرد؟

► اهداف اطلاعات ورودی – خروجی : چه داده های قابل مشاهده ای بعنوان ورودی برای نرم افزار نیاز است و چه داده های قابل مشاهده ای را به بعنوان خروجی برای مشتری تولید می کند؟

► عملیات و کارایی : چه عملیاتی و با چه میزانی کارایی نیازمندیم تا ورودی به خروجی تبدیل شود؟

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

► عملیاتی که باید تحویل شود.

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

فرآیند

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

پروژه

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

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

► حفظ یکپارچگی و پیشرفت : پروژه نباید به عدم یکپارچگی منتهی شود. مدیر پروژه باید گردش پرسنل را به حداقل کاهش دهد. تیم باید در هر کاری به کیفیت تمرکز کند و مدیریت ارشد باید هر کاری را که ممکن است انجام دهد تا از سر راه تیم کنار برود.

► پیگیری پیشرفت : برای یک پروژه نرم افزاری پیشرفت رهگیری می شود بدین صوت که محصولات کاری که تولید و تایید میگردد مورد شمارش و ارزیابی قرار میگیرد.

► اتخاذ تصمیم هوشمندانه : هر موقع که نیاز شد از نرم افزارها یا قطعات نرم افزاری تجاری آماده استفاده گردد.

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