Grp3se’s Weblog

شرح زیرسیستم

 

ERD زیرسیستم تولید

DFD زیرسیستم تولید

STD زیرسیستم تولید

 

دیاگرام افقی/عمودی زیرسیستم تولید

جلسه ششم : تست و خطا یابی

تست: خروجی این گام مشخصه تست است. در پیاده شازی باید موارد زیر انجام شود تا تست راحت‌تر باشد:

1) کدها عملیاتی باشند

2) هیچ اجرایی آزمایش برنامه را قطع نکند

3)قابلیت مشاهده در هر فرآیند

4) حالت‌های مختلف سیستم قابل نمایش باشد

5) خطاهای داخلی را تشخیص دهد

6) نرم‌افزاری که مرتب نیازهای اولیه آن تغییر کند هزینه تست بیشتری خواهد داشت

ویژگی‌های تست خوب

1) هدف تست خوب یافتن خطاها و اشکالات بیشتر با حداقل هزینه و زمان است

2) تست بیش از حد انجام نشود.

3) آزمایش‌ها هوشمندانه باشد.

4) تست نرم‌افزار به معنی کشف همه خطاها و ارائه یک نرم‌افزار بدون خطاست.

انواع روش‌های تست:

1) جعبه سفید: رویه برنامه یعنی خط به خط کدها  را تست میکند.

2) جعبه سیاه: به داخل ماژول‌ها کار ندارد. ورودی می‌خواهد و خروجی درست می‌خواهد.

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

1) تست مولفه: از جعبه سفید استفاده می‌شود.

2) معماری: کمی از جعبه سیاه و کمی از جعبه سفید استفاده می‌شود.

3) تست اعتبارسنجی: با توجه به نیاز‌ها و محدودیت‌های تعین شده در گام تحلیل, هر یک را تست (از نوع جعبه سیاه) می‌کنیم.

4) تست سیستم: در سطح مهندسی, از جعبه سیاه استفاده می‌شود.

تست جعبه سفید:

1) ساختمان‌داده محلی را بررسی می‌کنیم.

2) همه‌ی شرط‌های موجود در کدها بررسی می‌شوند.

3) حلقه‌ها بررسی می‌شوند ( تعداد تکرار حلقه‌ها )

4)  بررسی مسیرهای کنترل: همه‌ی مسیرهای مستقل که برنامه با طی آن اجرا می‌شود.

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

1) محاسبه پیچیدگی دورانی: تعداد ناحیه‌های گراف جریان را محاسبه می‌کنیم.

2) استفاده از گزاره‌های شرطی: شماره‌های گزاره‌های شرطی و جمع آن‌ها با 1 است.

3) استفاده از فرمول: E تعداد یال‌ها و N تعداد گره‌ها                           E  - N  + 2

4) ایجادماتریس گراف

آزمایش ساختارهای کنترل: در شرط موارد زیر را بررسی می‌کنیم:

پرانتز گزاره‌ها, عبارت محاسباتی, عملگرهای محاسباتی, اولویت‌های عملگرها, عملگرهای رابطه‌ای, نوع متغیرها در عملگرهای رابطه‌ای و نوع داده‌ها

ازمایش جریان داده‌ها: DU (Define Use) تعیین می‌کند که یک متغیر خاص در چه شماره دستوری تعریف و در چه شماره دستوری استفاده شده و در این زمان متغیر باید زنده بماند.

آزمایش حلقه‌ها: حلقه‌ها را در شرایط بررسی می‌کنیم:

اجرا نشدن حلقه, فقط یک گذر در طول حلقه, دو گذر طول حلقه, n-1 گذر, n گذر, n/2گذر, n-1 گذر, n+1 گذر

تست جعبه  سیاه: می‌تواند از روی DFD هم بررسی شود. در تست جعبه سیاه در این گام از بالا به پائین انجام می‌شود. اول main را بررسی می‌کنیم و چون ما هنوز زیر سیستم‌های main را بررسی نکرده‌ایم و می‌خواهیم فقط main را بررسی کنیم از روش stub استفاده می‌کنیم.

Stub : زیر برنامه‌ای است که چردازشی انجام نمی‌دهد و به جای زیر سیستم‌ها stub قرار می‌دهیم.

تست آلفا: تست پیاده‌سازی با مشتری متفاوت است. از کاربر دعوت می‌شود و زیر نظر پیاده‌ساز با سیستم کار می‌کند.

تست بتا: سیستم در یک محیط کنترل نشده زیر نظر مشتری مورد استفاده قرار می‌گیرد. هر سه ماه یکبار خطاها شناسایی شده را ارائه می‌کند.

تست سیستم: مهندس سیستم, سیستم را با سخت‌افزار و رویه‌های کاری Join می‌کند و بعد کل سیستم را بررسی می‌کند.

تست فشار: تعداد ورودی‌هایی که برای سیستم در نظر گرفته شده را خیلی زیاد بالا می‌بریم تا ببینیم سیستم با این فشار چطور برخورد می‌کند.

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

تست حفاظت: امنیت بررسی می‌شود.

تست کارایی: سیستم در زمان تعیین شده باید پاسخگو باشد.

تست رابط گرافیکی:  انواع حالت‌های رابط گرافیکی را چک می‌کنیم.

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

1) تصادفی:  محتویات حافظه را چاپ می‌کنیم و از خود کامپیوتر با صرف هزینه و وقت زیاد استفاده می‌کنیم.

2) عقب‌گرد: حدس می‌زنیم خطا از کجا رخ داده به عقب می‌رویم تا بررسی کنیم در مسیر کار چطور انجام شده.

3) حذف علت: حدس می‌زنیم که دلایل این شکست چیست, هر یک را بررسی می‌کنیم (از روی تجربه)

 

جلسه پنجم

مفاهیم و اصول طراحی

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

1)      طراحی داده براساس مدل ERD و DD.

2)      طراحی معماری براساس مدل‌های DFD  و CFD.

3)      طراحی واسطه‌ها براساس SDT, Pspec و Cspec .

4)      طراحی رویه‌ها براساس Pspec, Cspec.

اصول طراحی:

1)      براساس مدل تحلیل, طراحی صورت می‌گیرد و قابل پیگیری باشد.

2)      در طراحی, چیز جدیدی تولید نشود و از روش جدیدی استفاده نشود. بلکه از روش‌ها و مدل‌های موجود استفاده کنیم.

3)      طراحی فاصله ادراکی میان تحلیل و پیاده‌سازی را تا حد امکان کم می‌کند.

4)      طراحی, کدنویسی نیست.

5)      اصل طراحی کیفیت است و باید توجه اصلی به آن باشد.

کیفیت:

خارجی: آنچه مشتری می‌بیند و ارزیابی می‌کند مثل عملکرد, ظاهر, کارایی و …

داخلی: خود مهندسین نرم‌افزار آن را می‌بینند و براساس مفاهیم دیگری کیفیت نرم‌افزار را می‌سنجند که به آن‌ها “مفاهیم طراحی” می‌گویند.

مفاهیم طراحی:

1)      انتزاع یا مجردسازی: در طراحی سطح انتزاع را گام به گام کاهش می‌دهیم تا رفته رفته به پیاده‌سازی نزدیک شویم.

2)      پالایش: درهرگام جزئیات بیشتری به مسئله اضافه می‌کنیم و دوباره انتزاع و پالایش می‌کنیم. انتزاع و پالایش هردو  مکمل یکدیگرند.

3)      خاصیت پیمانه‌ای: هر طراحی خوب با صرفه‌نظر از روش, باید خاصیت پیمانه‌ای را در نظر بگیرد.پیچیدگی و هزینه لازم برای مسئله بزرگ از پیچیدگی و هزینه‌ی یک مسئله تقسیم شده بیشتر خواهد بود.

4)      معماری: هم‌بندی مولفه‌ها و ساختارکلی نرم‌افزار است. هم‌بندی ماژول‌ها و ارتباط آن‌ها معماری را می‌سازد.

5)      سلسله مراتب کنترل: پیمانه‌های سطح بالا پیمانه‌های کنترلی هستند و پیمانه‌های سطوح زیرین کارهای اصلی و پردازش‌ها و ورودی و خروجی را انجام می‌دهند.

6)      تقسیم‌بندی: شکستن سیستم به زیر سیستم‌ها. دو نوع دارد: افقی و عمودی.

7)      ساختمان داده‌ها: ساختمان داده‌ها رابطه منطقی میان عناصر داده‌ای را نشان می‌دهد.

8)      رویه نرم‌افزار: در رویه جزئیات پردازشی و منطق هریک از پیمانه‌ها و ترتیب اجزای دستورات وشرط‌ها بیان می‌شود.

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

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

1)      وحدت: کارهایی که در یک ماژول قرار می‌گیرد به گونه‌ای در کنار هم باشند که بتوان گفت در کل ماژول چه کاری انجام می‌دهد. انواع وحدت:

1-1)      وحدت تصادفی

1-2)      وحدت زمانی

1-3)      وحدت رویه‌ای

1-4)      وحدت ارتباطی

1-5)      وحدت منطقی

2)      کوپل(ارتباط) : در کوپل به ارتباط میان ماژول‌ها کار داریم و زمانی کوپل خوب است که ارتباط پیمانه‌ها کم باشد. انواع :

2-1) کوپل داده‌ای ( مولفه – ساختمان داده – کنترل )

2-2) کوپل مشترک

2-3) کوپل خارجی

2-4) کوپل محتویات

اعمال اصلی طراحی:

1)      طراحی داده: ساختمان داده‌های سیستم را مشخص می‌کنیم.در سه سطح است:

1-1)            سطح مولفه: تا انتهای گام طراحی عقب می‌اندازیم. مانند تعریف متغیرها و مقادیر اولیه به آن‌ها

1-2)            در سطح کاربرد: پایگاه داده است که از روی مدل ERD جداول را می‌سازیم.

1-3)            در سطح تجاری: طراحی مخزن داده است.

2)      طراحی معماری: از چند الگوی مشخص استفاده می‌کنیم:

2-1) معماری بر پایه داده

2-2) معماری جریان داده

2-3) معماری لایه‌ای

2-4) معماری Call Return

2-5) معماری شی‌گرا

کیفیت طراحی معماری: کمی و کیفی

جریان فرآیند در DFD:

1)      جریان تبدیل: در این جریان داده‌ها مرتب تغییر می‌کنند و فرآیند جلو می‌رود.

2)    جریان تراکنش: قلم داده‌ای در یک ماژول وجود داردکه براساس شرایط آن قلم داده یکی از خروجی‌ها انتخاب می‌شود, به طوریکه انگار در منطق آن ماژول تصمیم‌گیری انجام می‌شود.

3)      طراحی واسطه‌ها: Interface تاثیر زیادی در مشتری دارد و به همین دلیل اهمیت بسیار زیادی در تولید نرم‌افزار خواهد داشت, زیرا بیشتر تعامل کاربر با Interface است.

اصول طراحی واسط:

1) کنترل را به کاربر بدهید

2)بارفکری کاربر را کم کنیم

3) واسط را یکنواخت کنیم

§      در مرحله طراحی واسط Help نرم‌افزار تولید می‌شود و شامل دو نوع است:

1) مجتمع شده: در هنگام ساخت به سیستم اضافه می‌شود و همراه با سیستم جلو می‌رود و در هر وضعیت سیستم, Help مربوط به آن وضعیت را نشان می‌دهد.

2) اضافه شده: پس از تولید و تکمیل نرم‌افزار, Help آن تولید می‌شود.

4) طراحی رویه‌ها:

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

4-1) نشان‌گذاری طراحی گرافیکی: برای نشان دادن منطق ماژول‌ها یا از روش نشانه‌گذاری گرافیکی یا از ابزار گرافیکی دیگری به‌نام نمودار جعبه‌ای استفاده می‌کنیم.

4-2) نشان‌گذاری جدولی طراحی: برای نرم‌افزارهایی که در آن‌ها شرط‌ها خیلی کاربرد دارد استفاده می‌شود. در این جدول تصمیم‌گیری همی شرط‌های ممکن و موجود در مسئله را به همراه اعمالی که در سیستم در نتیجه ترکیب آن‌ها جمع می‌شود را لیست می‌کنیم.

4-3) زبان طراحی برنامه: استفاده از زبا طراحی برنامه یا شبه کد است. این روش از این جهت مناسب‌تر از سایر روش‌هاست زیرا همه‌ی شرط‌ها را نشان می‌دهد و ویرایش آن راحت‌تر است و قابلیت خوانده‌شدن توسط ماشین از جمله توانایی‌های این روش است.

  

جلسه چهارم

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

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

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

اصول و مفاهیم اولیه تحلیل:

چرا تحلیل می‌کنیم؟ چرا به آن نیاز داریم؟ هر عملی نیاز به تفکر دارد, ما باید در مورد عملکرد و مراحل کارفکر کنیم. هرچقدر آشنایی ما کمتر باشد, تحلیل بیشتری انجام می‌شود.

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

فعالیت‌های عمده تحلیل نیاز:

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

1-1)به افراد زیادی ارائه  می‌شود ولی افراد کمی نتایج را تحویل می‌دهند و جلوی جریان ایده‌ها و تفکر را می‌گیرد و نباید جواب معلوم باشد و یا جواب را به مخاطب تلقین کرد.

1-2)کارکردن و حضور در محیط: از نزدیک می‌توان مشکلات را لمس کرد و در جریان کار اپراتورها قرار گرفت.

1-3)مصاحبه: از قبل باید تعییم وقت کرد و اطلاع می‌دهند از کدام فرد خاص و در چه زمینه‌ای سوال می‌پرسند و باید دارای زمانبندی باشد. مدیریت قوی داشته باشد. در اولین ملاقات تحلیلگر و مشتری تلاش می‌کنند اطلاعات زیادی از طرف مقابل کسب کنند. هزینه و زمان زیادی صرف می‌شود. این روش در کنار سایر تکنیک‌ها مناسب است.

1-4)مشاهده, مرور مستندات و رویه‌های کاری: مشابه حضور در محیط است و سبب می‌شود از نحوه عملکرد سیستم قبلی و کارکرد و مشکلات آن مطلع شود.

1-5)روش Fast : در این روش همه اعضا از همه بخش‌های مختلف کل سیستم و در کنار نماینده مشتری جلسه‌ای برگزار می‌کنند و پیش از جلسه مستنداتی در مورد محصول به افراد ارائه می‌شود و آن‌ها باید موجودیت‌های مسئله را شناسایی کنند, سپس در جلسه این موجودیت‌ها و محدودیت‌ها را کامل بررسی می‌کنند و سپس به گروه‌هایی تقسیم می‌شوند که جزئیات بیشتر این موجودیت‌ها را شناسایی می‌کنند و در آخر به کل اعضا اعلام می‌کنند.

1-6)روش QFD : هدف اصلی حداکثر کردن رضایت مشتری است و سعی می‌شود سه نوع نیاز تشخیص داده شود:

§         معمولی: آنچه مشتری خودش تعیین می‌کند.

§         موردانتظار: آنچه که مشتری خودش تعیین نمی‌کند اما بدیهی است باید وجود داشته باشد.

§         غیرمنتظره: مشتری چنین انتظاری نداردو اگر باشد رضایت را بالا می‌برد.

1-7)نمونه‌سازی: روش مناسبی برای جمع‌آوری اطلاعات است و به طور کلی دو نمونه است:

§         انتهای بسته: نمونه دورانداختنی؛ نمونه‌ای را فقط برای جمع‌آوری اطلاعات می‌سازند.

§         انمتهای باز: نمونه افزایشی-تکاملی؛ نمونه‌ای را برای جمع‌آوری اطلاعات می‌سازیم و در گام‌های بعدی آن را در جهت تکمیل پروژه اصلی به کار می‌بریم.

2)      ارزیابی و سنتز راه حل: در بعضی از روش‌های جمع‌آوریاطلاعات مثل Fast, QFD و نمونه‌سازی راه‌حل هم ارائه می‌شود. در این مرحله حالا که مسئله و نیازها و خواسته‌ها روشن و مشخص شده, راه‌حل را باید تعیین کنیم.

3)      مدل‌سازی: راه‌حل تعیین شده را مدل می‌کنیم. یک فلوچارت یا شکل گرافیکی ساده به‌راحتی می‌تواند راه‌حل را نشان دهد و برای نشان دادن از زبان مدل‍سازی که زبان مشترک بین تحلیلگران و طراحان و مهندسین نرم‌افزار است استفاده می‌کنیم.

4)      تعیین و شناسایی مشخصات مسئله: حاصل‌جمع مدل‌های مختلف, مشخصه تحلیل را می‌سازد.

5)      مرور: یک FTR به مشخصه تحلیل اضافه می‌کنیم و این مشخصه تحلیل به مخزن اضافه می‌شود.

اجزای مشخصه تحلیل:

§         محدوده اطلاعات نرم‌افزار: مدل ERD, مدل DFD, مستند Pspec, مدل CFD, مستند Cspec

§         توابع یا عملکرد نرم‌افزار: مدل DFD

§         رفتار نرم‌افزار: مدل STD

§         کارایی

§         محدودیت‌ها

§         DD (Data Dictionary): هر شی تولید شده و به کار رفته در نرم‌افزار با توضیح کامل در DD قرار می‌گیرد. هرجا داده‌ای تولید شود اسم داده, نام مستعار, چه جایی استفاده شده و توضیحات اضافی.

§         Help کاربری

§         معیارهای اعتبارسنجی: پروژه خوب باید چه معیارها و ویژگی‌هایی داشته باشد.

 

مدل‌سازی تحلیل نیازها:

1)      مدل ERD : مراحل تولید این مدل:

1-1)تشخیص انواع موجودیت‌ها در فضای مسئله

1-2)تشخیص ارتباط میان هر زوج موجودیت‌ و اینکه اصلا ارتبتباطی میان آن‌ها وجود دارد یا نه

1-3) تشخیص انواع ارتباط میان هر زوج موجودیت

1-4)تشخیص درجه و الزام ارتباطات

1-5)تشخیص صفات موجودیت‌ها

1-6)مرور

انواع ارتباط میان موجودیت‌ها:

§         سلسله مراتبی: تمام خصوصیات سطح بالاتر را به ارث می‌برند و علاوه برآن دارای صفات دیگری هم هستند.

§         شرکت‌پذیری: هر یک از اجزای تشکیل دهنده سطح بالاتر هستندو مشخصات خاص خود را دارند.

2)      مدل DFD : هم محدوده اطلاعات را در نظر دارد و هم توابع عملکرد سیستم را.

رسم نمودار DFD: در ابتدا سیستم را به چند زیر سیستم تقسیم می‌کنیم

1)      ابتدا فرض بر این است که کل سیستم یک فرآیند است و فقط موجودیت‌ها و داده‌های ورودی و خروجی را مشخص می‌کنیم. به DFD سطح صفر, Contex Diagram می‌گویند.

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

3)      در گام بعدی برای تهیه و تولید DFD سطح دوم, یکی از زیرسیستم‌ها را انتخاب کرده و تجزیه می‌کنیم.

 

3) مدل CFD: روش رسم آن است که نمودار DFD را رسم کنیم و سپس تمام خطوط داده را حذف کنیم و رویدادها را مشخص کنیم. یک رویداد که وارد می‌شود یک سری اطلاعات کنترلی برای فرآیند فراهم می‌کند. صرفا به عنوان یک داده و اطلاع روی آن فعالیت انجام می‌شود و موجب فعال‌سازی فرآیندی نمی‌شود. جدولی به نام Pat وجود دارد که شامل رویدادهای مختلف و فرآیند فعال شدنی در آن رویدادهاست.

4) مدل STD: حالت‌های مختلف نرم‌افزار رانشان می‌دهد:

4-1) انتظار تا کسی کاری را انجام دهد.

4-2) دریافت ورودی

4-3) محاسبه خروجی

4-4) نمایش خروجی

 

ü      ERD جداول پایگاه داده و DFD معماری را می‌دهد.

ü      Pspec و Cspec طراحی مولفه‌های نرم‌افزار را در می‌آورند.

ü      STD و CFD برای طراحی واسط کاربری به کار می‌رود.

 

جلسه سوم

مدیریت ریسک

مفهوم ریسک: نمی‌دانیم چه مشکلی رخ می‌دهد اما می‌دانیم 80% احتمال بروز مشکل وجود دارد. هر ریسکس نتیجه‌اش یک فقدان است. اگر احتمال آن 100% باشد دیگر ریسک نیست بلکه یک محدودیت برای پروژه است.

انواع ریسک‌ها:

قابل پیش‌بینی: ریسک‌هایی که می‌توان آن‌ها را نام برد, تعیین می‌شوند.

غیر قابل پیش‌بینی: بستگی به مدیر یا فردی که ریسک‌ها را تحلیل می‌کند دارد. آنچه که اصلا به آن فکر نکردیم.

مراحل تحلیل ریسک:

1)      شناسایی ریسک‌ها: ریسک‌های پروژه را در یک چک لیست می‌نویسیم.

2)      تعیین احتمال ریسک‌ها: به هر یک از ریسک‌ها یک احتمال بر حسب درصد می‌دهیم .

3)      تعیین تاثیر ریسک‌ها در پروژه: میزان تاثیر ریسک‌ها را مشخص می‌کنیم. کم اهمیت, متوسط, بحرانی, فاجعه آمیز

4)      مدیریت ریسک: برنامه‌ای برای مدیریت ریسک‌ها تهیه می‌کنیم.

5)      اولویت‌بندی ریسک‌ها: ریسک‌هایی که تاثیر زیاد و احتمال وقوع آن متوسط رو به بالاست را در اولویت قرار می‌دهیم.

مولفه‌ها: برای تعیین تاثیر هر ریسک چهار مولفه را در نظر می‌گیریم و احتمال آن‌ها را تعیین می‌کنیم و میانگین احتمالات را محاسبه کرده و به عنوان احتمال ریسک در جدول ثبت می‌کنیم:

1)      کارایی: اگر ریسک تعیین شده اتفاق افتد چقدر در عدم انطباق محصول با نیازهای تعیین شده تاثیر دارد.

2)      هزینه: اگر ریسک تعیین شده اتفاق افتد چقدر احتمال دارد هزینه واقعی از هزینه برآورد شده بیشتر یا کمتر باشد.

3)      حمایت: با وقوع این ریسک این محصول چقدر امکان پشتیبانی, تصحیح و تغییر دارد.

4)      زمانبندی: اگر ریسک تعیین شده اتفاق افتد چقدر احتمال دارد از زمانبندی عقب بیفتیم.

برنامه RMMM :

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

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

3)      مدیریت ریسک: همه کارها برای کاهش و نظارت بر وقوع ریسک انجام شده ولی حالا ریسک اتفاق افتاده. چه کارهایی باید انجام دهیم و چه برنامه‌ریزی‌هایی برای آینده داریم.

انواع ریسک‌های نرم‌افزاری:

1)      ریسک‌های پروژه‌ای

2)      ریسک‌های فنی

3)      ریسک‌های تجاری

4)      ریسک‌های بازاریابی

5)      ریسک‌های استراتژیک

6)      ریسک‌های حمایت مدیران ارشد

7)      ریسک‌های تکنیکی

8)      ریسک‌های محیط توسعه نرم‌افزار

مدیریت پیکربندی

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

فعالیت‌های مدیریت پیکربندی:

1)      شناسایی اقلام پیکربندی: اولین گام شناسایی اقلام است.که هریک می‌تواند منفرد باشد یا ترکیبی.

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

پس از آنکه محصول تووسط تولید کننده تولید و به مدیریت ارائه شد, مرور تکنیک رسمیروی آن انجام می‌شود و پس از تایید به عنوان خط مبنا در مخزن ذخیره می‌شود. بعد از اینکه خط مبنا در مخزن اضافه شد, هر تغییری روی آن نیاز به درخواست تغییر اجازه مدیریت دارد.

2)      کنترل نسخه: در این مرحله گراغ تکامل مربوط به نسخه‌های مختلف هریک از اقلام پیکربندی رسم می‌شود. شماره‌گذاری نسخه‌ها همان فرآیند کنترل نسخه است که تعیین می‌کند کدام نسخه از روی چه نسخه‌ای ساخته شده است.

گراف نکامل نرم‌افزار: هرگاه نسخه‌ای از یک قلم پیکربندی تغییر می‌کند و نسخه‌ی جدیدی تولید می‌شود, نرم‌افزار هم تغییر می‌کند و نسخه‌ی جدیدی از نرم‌افزار تولید می‌شود.

3)      کنترل تغییر: مدیر باید کنترل‌های زیر را انجام شود تا کنترل تغییر انجام شود:

الف) کنترل دسترسی: قلم پیکربندی تایید شده و عنوان خط مبنا به مخزن اضافه می‌شود. کسی که درخواست تغییر می‌دهد باید کنترل شود او اجازه دسترسی و تغییر دارد یا خیر. ابزارهایی وجود دارند که این دسترسی‌ها را به افراد می‌دهند.

ب) کنترل همزمانی: دونفر به طور همزمان نتوانند یک قلم پیکربندی را تغییر دهند, با دسترسی هر فرد قلم قفل شود.

4)  برسی پیکربندی: بررسی وضعیت پیکربندی, بررسی می‌شود آنچه انجام شده از نظر تکنیکی درست بوده یا خیر. تغییرات  انجام شده مطابق با استانداردها انجام شده یا خیر.

5)  گزارش وضعیت: هرگاه درخواست تغییری تصویب شود, رکوردی به این گزارش اضافه می‌شود که نشان می‌دهد چه         

    زمانی, چه تغییری, توسط چه کسی انجام شده و نتیجه‌ی ان چه بوده است.

 

اطمینان از کیفیت نرم‌افزار (SQA)

قابلیت اطمینان : با Kloc و FP نیز سنجیده می‌شود اما MTBF ( متوسط زمان بین خرابی‌ها) نهتر است زیرا به کاربر وابسته است.

MTBF = MTTF + MTTR

قابلیت در دسترس بودن: برای  وظیفه تعیین شده کاربرد دارد یا خیر. هرچه  MTTR کمتر باشد قابلیت در دسترس بودن بالاتر خواهد بود.

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

تیم FTR : این تیم از 3 تا 5ر نفر مهندس نرم‌افزار تشکیل می‌شود. این تیم محصولات را از نظر مطابقت با استانداردها بررسی  می‌کند. سپس جلسه‌ای برای بررسی تشکیل می‌شود. حاضران این جلسه اعضای FTR و تولیدکنندگان هستند. در پایان جلسه یا نرم‌افزار مردود می‌شود و پس از اصلاح دوباره جلسه‌ای تشکیل می‌شود یا تایید می‌شود و به مخزن اضلفه می‌شود یا با وجود مشکلات کوچک, تایید می‌شود تا پس از اصلاح بدون تشکیل جلسه به مخزن سپرده شود.

تیم SQA : از مهندسین نرم‌افزار تشکیل شده که کارهای تکنیکی را انجام می‌دهند. افراد SQA مرورها, آزمایش‌ها و تست‌ها را در می‌آورند. برنامه‌ریزی‌هایی برای مرورها, بازبینی‌های نرم‌افزار و ثبت اطلاعات امنیتی و آماری و تولید گزارشات را انجام می‌دهند.

 

زمانبندی و پیگیری پروژه

زمانبندی پروژه: بی‌نظمی, رخداد ریسک‌های پیش بینی نشده, تغییرات خواسته‌های مشتری, ناهماهنگی تیم‌ها, ناتوانی مدیر پروژه در شناسایی وحل بحران و معقول نبودن زمان تعیین شده توسط مشتری همه از دلایلی است که سبب عقب ماندن پروژه‌ها از زمانبندی می‌شود.

اصول زمانبندی:

§         سیستم را به زیر سیستم‌ها تقسیم نموده و در مورد هریک از آن‌ها گام‌های مهندسی را تعیین کنیم.

§         تخمین نفر ماه برا یانجام هر یک از فعالیت‌ها

§         به هریک از فعالیت‌های تعیین شده فردی را اختصاص دهیم

§         اعتبارسنجی فعالیت

§         برای هر بخش فعالیت‌ها, خروجی تعیین کنیم.

§         میزان فعالیت یعنی زمان شروعو پایان هر فعالیت را تعیین کنیم.

به طور کلی سه درجه دقت در انتخاب کارهای مهندسی وجود دارد:

1)      معمولی: تمام کارهای مربوط به طور حداقل انجام شودو فعالیت‌های چتری به طور حداقل انجام می‌شود

2)      ساختاریافته: SQA و مستندسازی هم انجام می‌شوند, تاحدی که کیفیت تضمین شود.

3)      اکید: دقیقا همه کارها با دقت تمام و شدت زیاد انجام می‌دهیم برای رسیدن به حداکثر کیفیت

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

پیگیری پروژه: مدیر مرورها, گزارشات مدیران تیم‌ها را بررسی می‌کند, جلسات رسمی یا غیر رسمی برای وضعیت پروژه برگزار می‌کند تا ببیند پروژه چطور پیش می‌رود.

بررسی آماری پیگیری پروژه: مدیر تعیین می‌کند, هرنفرماه چقدر هزینه دارد و هزینه برنامه‌ریزی شده را تعیین می‌کند. مدیر زمان ثابتی مثل t را در نظر می‌گیرد, کل هزینه‌های زمانبندی شده برای پروژه تا زمان t را محاسبه کند و هزینه‌های واقعی صرف شده تا این زمان را نیز تعیین کند.

                                                 هزینه زمانبندی شده                                                 CS = ∑ CS_i

                                                هزینه واقعی زمانبندی شده                                     CP = ∑ CP_i

                                                 کارایی زمانبندی   Spl = CP / CS

جلسه دوم : اصول و مفاهیم مدیریت پروژه های نرم افزاری

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

مدیر پروژه برای مدیریت حوزه‌های زیر را باید پوشش دهد:

1)      افراد (People) : مهم‌ترین جزء هر پروژه نرم‌افزاری است. 5 گروه از افراد درگیر پروژه هستند:

1-1)            مدیران ارشد: کارهای مدیریت سیستم را انجام می‌دهند. تصمیم‌های مهم و تاثیرگذار را می‌گیرند.

1-2)            مدیرپروژه: رهگیری و سازماندهی و برنامه‌ریزی پروژه را انجام می‌دهد.

1-3)            مهندسان: کارهای تحلیل و طراحی و پیاده‌ازی و تست و نگه‌داری را انجام می‌دهند (مجریان)

1-4)            مشتری: نیازها, مشخصه‌ها و خصوصیات نرم‌افزار را تعیین می‌کنند. (نرم‌افزار را سفارش می‌دهند)

1-5)            کاربر: کسانی هستند که از نرم‌افزار استفاده می‌کنند.

مدل MOI رهبری:

الف) انگیزه: رهبر باید بتواند افراد را فعال کند تا پروژه به ثمر برساند. رهبری قوی انگیزه افراد را تا آخر پروژه حفظ می‌کند.

ب‌)    سازماندهی: افراد با مهارت‌های مختلف کنار هم باشند, وظیفه تعیین شده برای افراد متناسب با مهارت‌ها و ویژگی‌های افراد باشد.

ج‌)      خلاقیت: شکوفایی خلاقیت‌های افرلد.

 

2)      محصول (Product) : مهم‌ترین وظیفه مدیر در این بخش, تعیین محدوده نرم‌افزار و تجزیه آن است. یعنی زمانی که مشخصه سیستم را دریافت می‌کند آنقدر آن را گسترش می‌دهیم تا عملکرد, کارایی, رفتار, داده‌ها و محدودیت و .. مشخص شود.

عملکرد: نرم‌افزار چه کارهایی انجام می‌دهد.

رفتار: رفتار و حالت‌های مختلف سیستم. اتفاقات مختلفی که در نرم‌افزار رخ می‌دهد.

داده‌ها: سیستم از چه داده و ساختمان داده‌ای استفاده می‌کند.

محدودیت: چه موانع و نبایدهایی در سیستم وجود دارد.

3)      فرآیند (Process) : متناسب با مهارت اعضای تیم, نیازها, خصوصیات محصول, میزان پیچیدگی نرم‌افزار و نوع سیستم فرآیند مناسب باید انتخاب شود. در این مرحله فرآیند هم تجزیه می‌شود. از محصول و فرآیند مدل سازی انجام می‌شود. برای هر محصول تعیین می‌کنیم در هر گام از تحلیل و طراحی و .. چه کارهایی باید انجام شود. برای هریک تخمین زده می‌شود و زمانبندی کل پروژه و هزینه آن تعیین می‌شود.

4)      پروژه (Project) : عواملی که باعث شکست پروژه می‌شوند:

عدم شناخت نیازهای مشتری, محدوده نرم‌افزار مشخص نشده, مدیریت ضعیف تغییرات, تغییر تکنولوژی, تغییر نیازهای مشتری, مشخص نبودن مهلت‌ها, مقاومت کاربران, از میان رفتن حمایت‌ حامیان, فقدان افراد ماهر, اجتناب از بکارگیری آموزش‌های دیده شده.

اندازه‌گیری: یکی دیگر از وظایف مدیر پروژهاندازه‌گیری است. اندازه‌گیری در کار مهندسی معنا پیدا می‌کند. برای آنکه نسبت پروژه, فرآیند و محصول فهم درستی بدست آوریم باید یک سری صفات رااندازه‌گیری کنیم.

معیار: تخصیص اندازه به یک صفت کمی, یک معیار نامیده می‌شود. مانن هزینه, زمان, تعداد خطا

شاخص – دیدگاه: ترکیبی از معیارها که دیدگاهی را به ما می‌دهد.

کاربرد معیارها:

1) خصوصی: برای فرآیندهای خاص کاربرد دارد.

2) عمومی: در طول پروژه انجام می‌شود.

نرمال‌سازی: برای مقایسه معیارها و نتیجه‌گیری براساس آن‌ها, ابتدا آن‌ها را نرمال‌سازی می‌کنیم و بعد مقایسه.

1)      نرمال‌سازی اندازه‌گرا: تعداد خطاها در هر هزار خط کد.(Kloc)

2)      نرمال‌سازی عملگرا(FP)   :  براساس تعداد نقاط عملکرد. برای این کار ابتدا تعداد ورودی‌ها, خروجی‌ها, درخواست‌ها,فایل‌ها و رابط‌های خارجی را محاسبه و در میزان پیچیدگی هر یک ضرب می‌کنیم و از فرمول زیر بدست می‌آید:

N = ∑ f_i

C = ( 0.65 + 0.01 * N )

FP = ∑ ( Count * Weight ) * C

§         Kloc چون بستگی به برنامه‌نویس و زبان برنامه‌نویسی دارد مناسب نیست.

§         FP چون معلوم نیست چیست و کجاست و اینکه به عملکرد داخلی نرم‌افزار کاری ندارد مناسب نیست.

§         مقدار Kloc قابل تبدیل به FP است.

کیفیت: یکی دیگر از معیارهای نرم‌افزار, معیار اندازه‌گیری کیفیت است. کیفیت نرم‌افزاررا نمی‌توان مستقیما اندازه گرفت, بلکه از دو روش استفاده می‌کنیم:

1)      مستقیم: به طور مستقیم کیفیت نرم‌افزار را تعیین کنیم. که روش چندان مناسبی در مهندسی نیست.

2)      غیر مستقیم: کیفیت را براساس معیارهای دیگری بررسی کرده و آن‌ها را اندازه‌گیری می‌کنیم. این معیارها:

2-1) قابلیت نگه‌داری: درجه‌ای که بعدا می‌توانیم برنامه را تغییر دهیم یا آن را بهبود ببخشیم. معیار آن MTTC است. MTTC میانگین زمان لازم برای تغییر نرم‌افزار, که هرچه کمتر باشد نرم‌افزار قوی‌تر است.

2-2) امنیت: هرچه میزان یکپارچگی نرم‌افزار بیشتر باشد امنیت هم بیشتر است. منظور از یکپارچگی, درجه‌ای که نرم‌افزار در برابر تهدیدات خارجی مقاومت نشان می‌دهد.

2-3) قابلیت استفاده: میزان زمان مورد نیاز برای آموزش کاربران و کارکردن با نرم‌افزار, قابلیت سودندی, میزان فعالیت و مهارت لازم برای کار و استفاده از نرم‌افزار و میزان زمان لازم برای ورود.

 

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

گام‌های برنامه‌ریزی:

1)      مسئله و کارهایی که باید انجام شود را بشناسیم. داده‌ها, رفتار, عملکرد و محدودیت‌ها مشخص باشد.

2)      تخمین: تخمین میزان فعالیت و زمان موردنیاز

3)      ریسک: چطور می‌توان از وقوع آن جلوگیری کرد. در مورد هرکدام برنامه‌ریزی می‌کنیم.

4)      زمانبندی: کارهای متفاوت در طول پروژه را زمانبندی می‌کنیم.

5)      کنترل استراتژی: استراتژی‌های کنترل کیفیت و کنترل تغییرات را کنترل کنیم.

تخمین هزینه:  برای این کار باید محدوده پروژه به روشنی تعیین شده باشد, تجزیه کارها و وظایف به اندازه‌های کوچکتر بسیار مفید خواهد بود.

تخمین تکنیک‌ها:

مشابه پروژه‌های قبلی این کار را انجام دهیم.

از روش‌های مرسوم تخمین استفاده کنیم.

·         تفتیک وظایف و تخمین فعالیت‌ها

·         تخمین اندازه

استفاده از ابزارهای این کار مانند CheckPoint

تصمیم برای خرید:

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

 

خلاصه جلسه اول : اصول و مفاهیم مهندسی نرم افزار

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

نرم‌افزارچیست:

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

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

مشخصات نرم‌افزار:

1)      سخت افزار یک محصول فیزیکی است اما نرم‌افزار یک محصول منطقی است.

2)      نرم‌افزاردورانداختنی نیست اما سختافزار بعد از مدتی کارایی خودرا از دست می‌دهد. نرم‌افزارهیچ‌گاه فرسوده نمی‌شود تنها ممکم است دیگر نیازهای ماراطی گذشت زمان و تغییر نیازها و خواسته ها برآورده نکند.

3)      در مهندسی سخت افزارعلاوه بر هزینه مهندسی، هزینه سخت‌افزار هم وجود دارد ولی در مهندسی نرم‌افزار، اصل هزینه مربوط به مهندسی است یعنی کاری که انجام می‌شود.

4)      به پروژه مهندسی نرم‌افزار Development می‌گویند اما محصول سایر مهندسی‌ها را Production می‌نامند.

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

انواع نرم‌افزار:

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

            سیستم‌عامل‌ها : داده‌های عظیم نامشخصی را پردازش می‌کنند.

            کامپایلرها و مفسرها: ساختارهای اطلاعاتی پیچیده ولی مشخصی را پردازش می‌کنند.

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

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

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

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

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

نرم‌افزار Web : صفحات Web توسط مرورگرها بازیابی می‌شوند که شامل دستورات اجرایی و داده‌ها می‌شوند. این شبکه شامل تعداد زیادی کامپیوتر است که منابع نرم‌افزاری نامحدود را ارائه می‌نمایند.

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

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

مهندسی نرم‌افزار پروژه ای با کیفیت را طراحی می‌کند و در این راه از فرآیندها استفاده می‌کند و در هر یک از فرآیندها از روش‌ها و ابزارهای خاصی استفاده می‌کند.

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

مدل آبشاری یا SSADM: این مدل ساده‌ترین و قدیمی‌ترین مدل فرآیند است.

مزایا: مدیریت آسان و خوب

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

 

مدل نمونه سازی: در این روش با توجه به این نکته که مشتری به خوبی از نیازها آگاه نیست برای تحلیل مناسب ابتدا یک نمونه با ابزارهای موجود و به شکلی ساده ساخته می‌شود و با ارئه آن به مشتری نیازها مشخص می‌شود. این تحلیل بسیار دقیق است.

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

مدل RAD (Rapid Application Development ): توسعه سریع نرم‌افزار. در 60 تا 90 روزپروز] باید تهیه شود.پروژه باید به صورت ماژولار باشد یعنی به بخش‌های کوچک‌تر شکسته شود و به صورت مجزا و موازی با هم کار کنند. روش مورد استفاده در هر بخش روش آبشاری است.

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

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

مدل مارپیچی: از دیگر نمونه مدل تکاملی است. در این مدل تحلیلگر مدتی بیکار است تا نسخه وارد بازار شود سپس دوباره شروع به کار می‌کند ولی در روش گام به گام تحلیلگر و سایر کارکنان بیکار نیستند.

مدل Component Based development : توسعه بر مبنای مولفه. این مدل برای پروژه های ماژولار مناسب است.در این مدل پس از تحلیل، مولفه‌ها شناسایی شده و اگر مولفه‌ای قبلا ساخته شده باشد باید یررسی شود آیا می‌توان آن را بدون تغییر استفاده کرد یا باید تغییر داد و اگر مولفه وجود ندارد باید ساخته شود و سپس نگه‌داری شود.

مدل تکنیک نسل چهارم (4G): یک محیط نرم‌افزاریست که در آن مسخصات و نیازمندی‌های سیستم که در مراحل تحلیل و طرهحی و .. بدست آوردیم را به آن می‌دهیم و در نهایت خود نرم‌افزار کد را تولید می‌کند. برای پروژه هایی که منطق سنگین و پیچیده‌ای ندارند مناسب است.

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

ویژگی‌های نرم‌افزار خوب: مواردی که موجب با کیفیت بودن نرم‌افزار می‌شوند:

1)      قابلیت نگهداری

2)      قابلیت استفاده

3)      قابلیت انعطاف

4)      قابلیت استفاده مجدد

5)      امنیت

6)      قابلیت اطمینان

7)      بهینه

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

1)      عمومی: برای طیف وسیعی از کاربران ساخته می‌شود

2)      سفارشی: برای کاربرد خاصی ساخته تولید می‌شودو هزینه بیشتری هم درپی دارد.

 

v      هدف از مهندسی نرم‌افزار آن است که هزینه‌های نگه‌داری آن کاهش یابد و تولید نرم‌افزار به صرفه باشد.

v      هزینه نگه‌داری از هزینه تولید نرم‌افزار بیشتر است.

 

اشاره :

در حقيقت ساختن يك نرم‌افزار فقط نوشتن كدهاي برنامه نيست. رويه ساخت نرم‌افزارها مراحل متعددي را دربرمي‌گيرد؛ از جمع آوري نيازهاي كاربران گرفته تا طراحي، نوشتن كد و در آخر امتحان نرم افزار. روش توليد نرم‌افزارهاي كوچك با نرم‌افزارهاي بزرگ متفاوت است و طبعاً رويه توليد نرم‌افزارهاي كوچك نيز متفاوت خواهد بود. البته اين رويه نبايد سنگين و حجيم باشد، بايد مستقيماً به تمامي فعاليت‌هاي لازم براي توليد نرم‌افزاري با كيفيت بالا نظارت داشته باشد و از تمامي رويه‌هاي آسان و متمركز استفاده كند. با استفاده از تكنيك‌هايي مفيد، از روش‌هايي مانند XP،Scrum و RUP مي‌توان رويه‌اي مناسب براي توليد نرم‌افزارهاي كوچك به‌وجود آورد. همچنين مي‌توان از روش‌هايPSP و TSP نيز كه براي توليد نرم‌افزارهاي كوچك مناسب هستند استفاده نمود و به‌وسيله اين روش‌ها كيفيت و قابليت‌هاي نرم‌افزارها را بالا برد و در حداقل زمان ممكن نرم‌افزار را تهيه نمود. اين مقاله با بررسي روش‌هاي جديد و متداول امروزي در توليد نرم‌افزار، بهترين و مناسب‌ترين روش توليد نرم‌افزارهاي كوچك را به شما نشان خواهد داد. گفتني است نوشتار حاضر نتايج تحقيقات من در گروه تحقيقاتي مهندسي نرم‌افزار دانشگاه ساندرلند انگلستان است و آمار و نتيجه‌گيري‌هاي آن براساس مصاحبه‌هاي انجام شده با چندين شركت كوچك و بزرگ توليد نرم‌افزار آن كشور است.

فرايند توليد نرم‌افزار

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

 

انجمن IEEE رويه يا فرايند توليد نرم‌افزار را اين گونه تعريف مي‌كند: رويه توليد نرم‌افزار در واقع شامل مراحلي مانند جمعآ‌وري نيازهاي كاربران ، طراحي سيستم با استفاده از تحليل اين نيازها و نوشتن كدهاي نرم‌افزار با استفاده از طرح نرم‌افزار است. همچنين بر اين‌باور است كه از آن جايي كه كيفيت و بهره‌وري نيروي كار با كيفيت روند توليد نرم‌افزار ارتباط مستقيم دارد، طراحي و مديريت رويه توليد نرم‌افزار از اهميت شاياني برخوردار است.

 

براي طراحي يك رويه توليد نرم‌افزار مي توان از روش‌هاي متفاوتي استفاده نمود و از آن جايي كه هر پروژه نرم‌افزاري با ديگر پروژه‌ها متفاوت است، مي‌توان گفت كه رويه توليد آن پروژه نيز با ديگر پروژه‌ها تفاوت دارد. در واقع مي‌توان گفت: انتخاب اين روش‌ها رابطه مستقيمي با اندازه گروه در پروژه دارد و نرم‌افزارهاي بزرگ و كوچك نياز به رويه‌هاي توليد متفاوت دارند.

 

در ادامه اين مقاله روش‌هاي توليد نرم‌افزارها، به خصوص نرم‌افزارهاي نسبتاً كوچك كه از گروه‌هاي توليد نرم‌افزاري كوچك‌تري استفاده مي‌كنند، بررسي مي‌شوند و مورد ارزيابي قرار مي‌گيرند.

 

روش SCRUM

در روش‌هاي قديمي و معمول ساخت نرم‌افزار، طراحان نرم‌افزار معمولاً ابتدا فرض مي‌كنند كه تمامي نيازهاي كاربران سيستم را درك كرده‌اند. اما هميشه نيازهاي كاربران سيستم در ابتدا مشخص نيست و كاربران ممكن است در همان مراحل ابتدايي، نيازهاي خود را تغيير دهند و اين چيزي است كه برنامه‌نويسان و طراحان سيستم هميشه از آن شكايت مي‌كنند و به دنبال راه‌حلي براي رفع اين موضوع مي‌گردند. به‌عنوان مثال مدل قديمي آبشاري (waterfall) را در نظر بگيريد.

 

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

 

امروزه يكي از روش‌هاي توليد نرم‌افزار كه به خصوص براي پروژه‌هاي نرم‌افزاري كوچك مورد استفاده قرار مي‌گيرد و توسط بسياري از اساتيد و صاحب‌نظران مورد تأييد قرار گرفته است، روش SCRUM است. با استفاده از اين روش كه روشي به اصطلاح (iterative تكراري يا چرخشي) مي‌باشد، مي‌توان نرم‌افزارهاي كوچك را با كيفيت بالا تهيه نمود. در اين روش كه به روش هوشمند يا Agile نيز مشهور است، مديريت قوي توليد نرم‌افزار وجود دارد كه به برنامه‌نويسان اجازه مي‌دهد با استفاده از آن در پروژه‌ها به سرعت نرم‌افزار موردنظر را تهيه نمايند. اسم Scrum در حقيقت از بازي راگبي گرفته شده است (در بازي راگبي Scrum تيمي متشكل از هشت نفر است كه با همكاري بسيار نزديك با يكديگر بازي مي‌كنند).

 

 

در اين روش هر عضو از گروه موظف به درك وظيفه خود در پروژه است و بايد يك هدف مشخص را در تمامي مراحل عملياتي يا فازهاي اجرايي دنبال كند. لازم به ذكر است كه در Scrum هر فاز عملياتي سيستم به Sprint مشهور است.

 

روش Scrum همانند پروسه‌هاي داراي مرحله برنامه‌ريزي مقدماتي يا Initial Planning است. در اين فاز اعضاي تيم بايد يك نقشه مقدماتي و يك معماري سيستم قابل تغيير به وجود آورند. بعد از اين فاز يك سري از Sprintها به صورت مرتب و جزء جزء نرم‌افزار مورد نظر را به وجود مي‌آورند (شكل1). انجام دادن هر Sprint ممكن است از يك تا چهار هفته به طول بينجامد و مجموع اين Sprintها نرم‌افزار كاملي را به‌وجود ميآورند.

 

فهرست تكاليف در هر Sprint به Backlog مشهور است كه تكاليف تيم عملياتي در هر Sprint را مشخص مي‌كند. اين Backlog در هر Sprint بروز مي‌شود و هر تكليف براساس اهميتي كه دارد در فهرست تكاليف تعيين اولويت مي‌گردد. هر فرد در گروه يك كار يا تكليف خاص از اين فهرست را به عهده مي‌گيرد و موظف مي‌شود تا شروع Sprint بعدي آن را به اتمام برساند. وقتي كه يك Sprint شروع شد، ديگر انجام هيچ تغييري در تكاليف امكان ندارد و حتي درخواست‌كننده نرم‌افزار نيز حق تغيير يا درخواست نياز ديگري در نرم‌افزار را نخواهد داشت.

 

البته درخواست‌كننده مي‌تواند از قسمتي از نرم‌افزار كه بايد در هر مرحله توليد شود بكاهد، اما نمي‌تواند تاريخ تحويل آن قسمت را تغييردهد. شايد بتوان گفت كه اين كار باعث ايجاد نظم در گروه مي‌شود و تاريخ تحويل نرم‌افزار به تعويق نخواهد افتاد. علاوه بر اين، در طول هر Sprint گروه موظف است روزانه جلساتي جهت بررسي روند پيشرفت و قابليت‌هاي نرم‌افزار داشته باشد كه اين نيز به هماهنگي بيشتر گروه كمك خواهد كرد. در اين جلسات كه معمولاً به صورت روزانه است، سه گروه مي‌توانند شركت كنند: گروه تهيه‌كننده نرم‌افزار، مديريت، و درخواست‌كنندگان نرم‌افزار.

 

در طول اين جلسات مسئول جلسه كه اغلب مدير پروژه است، از تمامي اعضاي تيم سه سؤال مي پرسد:

 

1- مسئوليت شما (تكاليف) از جلسه قبلي تاكنون چه بوده است و آيا توانسته‌ايد اين تكاليف را به اتمام برسانيد؟

 

2- در طول اين دوره به چه مشكلاتي برخورده‌ايد؟

 

3- بر طبق فهرست وظايف، مسئوليت شما از حالا تا جلسه بعدي چه خواهد بود؟

 

مدير Scrum در حقيقت مسئوليت شناسايي تكاليف محوله به اعضا، بررسي روند تكميلي ساخت نرم‌افزار، بررسي قابليت‌هاي اعضاي گروه و فعاليت در راستاي كم كردن ريسك در پروژه را داراست.

 

اما چه تفاوتي بين Scrum و ديگر روش‌هاي توليد نرم‌افزار وجود دارد؟ در جواب اين سؤال بايد يادآورشد كه در Scrum هر مرحله يا Sprint قسمتي از نرم‌افزار را آماده مي كند. در اين روش مي توان پيشرفت در توليد نرم‌افزار را در هر مرحله به خوبي احساس نمود. علاوه بر اين، گروه مي‌تواند پس از اتمام هر Sprint تصميم‌گيري‌كند كه آيا مي خواهد به كار روي پروژه ادامه دهد يا انجام پروژه مذكور غيرممكن است. روش Scrum وقتي مي‌تواند بيشتر مفيد باشد كه در ابتداي پروژه نيازهاي كاربران به صورت دقيق مشخص نباشد و يك گروه كوچك مسئول پروژه نرم افزاري باشد.

 

نتايج تحقيقاتي كه اواخر سال 2005 روي چندين شركت توليدكننده نرم‌افزار در كشور انگلستان انجام دادم، نشان‌دهنده اين بود كه شركت‌هايي كه از Scrum استفاده كرده بودند با حدود چهارصددرصد افزايش در بهره‌وري كار مواجه بودند. البته اين رقم در گروه‌هاي نرم‌افزاري مختلف متفاوت بود و مي‌توان گفت عوامل انساني از جمله مدير پروژه نقش بسيار مهمي در افزايش يا كاهش راندمان پروژه ها دارند.

 

شايد اين سؤال در ذهن شما به وجود آيد كه چرا Scrum ممكن است براي توليد نرم‌افزارهاي كوچك راه حل خوبي باشد؟ در جواب مي‌توان گفت، از آن جايي كه در تيم‌هاي كوچك، اعضاي گروه بايد از تمامي مسائل پروژه آگاه باشند و در Scrum تمامي مراحل ساخت توسط تمامي اعضاي گروه قابل مشاهده است. لذا اين روش مي‌تواند روش مناسبي باشد.

 

معايب روش Scram

مزاياي استفاده از Scrum بسيار است، اما اين روش چند اشكال نيز دارد. از جمله:

 

1- Scrum روش جديدي است و با روش‌هاي مرسوم تفاوت‌هاي زيادي دارد.

 

2- برخي از برنامه‌نويسان حرفه‌اي ممكن است از تكاليفي كه مدير Scrum به ايشان مي‌دهد راضي نباشند و بخواهند روش قديمي خود را اجرا نمايند و در صورت اجبار، در روند اجراي پروژه كارشكني كرده و مشكل‌آفريني كنند.

 

3- از آنجا كه مدير Scrum هم از نظر كيفي و هم كمي بايد پروژه را مديريت كند، Scrum نياز به مديريت بسيار قدرتمند دارد.

 

4- Scrum را مي‌توان به عنوان روش توليد نرم‌افزار نام برد، اما اين روش بيشتر روش مديريت پروژه هوشمند خوبي است و نمي‌توان آن را به صورت منفرد استفاده نمود و مي‌توان گفت براي حصول اطمينان از موفقيت پروژه‌هاي نرم‌افزاري (به خصوص در سطح كوچك) بايد اين روش را با روش‌هاي ديگر ادغام نمود. Scrum را از آن جهت مي‌توان روش خوبي برشمرد كه روشي تحقيقي براساس تخمين، اولويت‌بندي، عملكرد گروه و بررسي نتايج است كه اگر به صورت صحيح مورد استفاده قرار گيرد و قبل از استفاده به صورت كامل آموزش داده شود، مي‌تواند راندمان پروژه‌هاي نرم‌افزاري، به خصوص توليد نرم‌افزارهاي كوچك را به صورت بسيار محسوسي بالا ببرد.

 

روش XP

اشتباه نكنيد! منظور از روش اكس‌پي، ويندوزاكس‌پي نيست. اكس‌پي مخفف Extreme Programming يا برنامه‌نويسي سريع مي‌باشد كه مانند Scrum روشي هوشمند در توليد نرم‌افزار است. در اكس‌پي دو برنامه‌نويس كار را انجام مي‌دهند و قبل از اتمام برنامه آن را چندين‌بار امتحان مي كنند. اكس‌پي در حقيقت روشي از توليد نرم‌افزار است كه براساس آساني، ارتباط، واكنش و تصميم‌گيري سريع استوار است. شكل 2 اصول روش اكس‌پي را نشان مي‌دهد.

 

 

در روش اكس‌پي اعضاي گروه (كه كاربر سيستم نيز عضوي از آن است) در ابتدا جلسه‌اي تشكيل مي‌دهند و اولويت‌هاي پروژه را مشخص مي‌كنند. اين گروه ممكن است از چند برنامه‌نويس، امتحان‌كننده نرم‌افزار يا Tester و تحليلگر سيستم تشكيل شود كه با هم از ابتدا تا انتهاي پروژه همكاري مي‌كنند. معمولاً در اكس‌پي برنامه‌نويسان در گروه‌هاي دوتايي قرار مي‌گيرند و وظيفه تكميل قسمتي از برنامه را برعهده مي‌گيرند و هر دوي اين برنامه نويسان در مورد هر كدام از نيازهاي كاربران با هم بحث مي كنند و قدم به قدم كلاس هاي برنامه را آماده مي‌كنند.

 

بدين ترتيب كه در ابتدا كلاسي را به صورت ابتدايي و بدون هيچ طراحي اوليه به وجود مي‌آورند و اين كلاس را امتحان مي‌كنند. در صورتي كه اين كلاس فاقد هر گونه اشكال باشد، كد اصلي برنامه را بر آن اساس مي‌نويسند. وقتي يكي از برنامه‌نويسان مشغول نوشتن قسمتي از برنامه است، برنامه‌نويس ديگر وظيفه كنترل صحت اين كدها را عهده‌دار است و در صورت مشاهده هر گونه اشكال، نويسنده كد را مطلع مي‌كند.

 

مانند Scrum، در اكس‌پي نيز اعضاي گروه مي‌توانند روند تكميلي توليد نرم‌افزار را مشاهده كنند و در جريان كار قرار گيرند.اكس‌پي روش مناسبي براي مديريت پروژه‌هاي كوچك مي‌باشد كه از دو تا ده برنامه‌نويس تشكيل شده است. اگر چه اصولاً اكس‌پي هيچ رويه خاص و مراحل پيوسته‌اي را مشخص نكرده اما مي توان گفت كه اكس‌پي داري چهار مرحله اصلي مي باشد:

 

الف: مرحله زمانبندي پروژه: در اين مرحله اعضاي گروه با توجه به اندازه نرم‌افزار و كارايي آن برنامه زمانبندي را با هم تنظيم مي كنند.

 

ب: طراحي ابتدايي

 

ج: نوشتن كدهاي برنامه

 

د: امتحان‌كردن كدهاي نوشته شده

 

مطابق تحقيقاتي كه توسط نويسنده انجام شد، مشخص گرديد كه اكس‌پي در پروژه‌هاي بزرگ با تعداد اعضاي بالاي ده نفر اصلاً موفق نخواهد بود و تنها مي‌تواند براي پروژه‌هاي كوچك مفيد باشد. دليل آن را نيز مي توان در طبيعت اين روش دانست؛ زيرا مستندات چنداني براي نرم‌افزار وجود ندارد و فقط دو نفر يا حداكثر چهار نفر مي‌توانند در مورد قسمتي از نرم‌افزار اطلاعاتي داشته باشند. همچنين نرم‌افزار توليدشده توسط اين روش هيچ‌گونه طراحي سازمان يافته‌اي ندارد كه اين موضوع مي‌تواند براي مراحل پس از نصب يعني تعميرات و نگهداري سيستم باعث بروز مشكلاتي گردد.

 

از جمله مزاياي اكس‌پي مي‌توان به اين نكته اشاره نمود كه از آن جايي كه يك برنامه‌نويس به صورت مستقيم كدهاي برنامه را كنترل مي كند، مي‌توان گفت كه كيفيت نرم‌افزار توليدي بالا مي‌رود. همچنين مي‌توان گفت از آن جايي كه دو برنامه‌نويس با هم كار مي‌كنند، آموزش كمتري نياز است و در نتيجه هزينه توليد نرم‌افزار پايين خواهد آمد. اما اين روش مشكلات خاص خود را نيز دارد. مثلاً تصوركنيد اگر در يك گروه، يك برنامه‌نويس تمايلي براي كار با برنامه نويس ديگري را نداشته باشد يا در يك روز يكي از دو عضو گروه غايب باشد يا … در نتيجه چون نمي‌توان با يك برنامه‌نويس به ادامه كار پرداخت، اتمام پروژه با تأخير مواجه خواهد شد.

 

طبق نتايج تحقيقات به عمل آمده، وقتي يك برنامه‌نويس در كدهاي برنامه به دنبال اشكال مي گردد، حداكثر مي‌تواند ده تا پانزده‌درصد از اشكالات برنامه را پيدا كند. اما وقتي در روشي مثل اكس‌پي دو برنامه‌نويس با هم كار مي كنند و يكي از اين برنامه‌نويسان كدها را كنترل مي‌كند، بيست تا چهل‌درصد از اشكالات ساختاري برنامه خود را نشان مي‌دهد. اما با استفاده از روش‌هاي PSP و TSP كه در ادامه اين مقاله توضيح داده مي‌شوند حتي مي‌توان تا هشتاددرصد اشكالات برنامه (كه رقم بسيار خوبي است) را قبل نهايي‌شدن برنامه شناسايي و رفع كرد.

 

روشRational Unified Process) RUP)

 

در اين بخش يكي از معروف‌ترين رويه‌هاي توليد نرم‌افزار كه توسط شركت آي‌بي‌ام طراحي گرديده‌است را معرفي مي‌كنيم. اين روش با نام Rational Unified Process) RUP) در بسياري از پروژه‌هاي نرم‌افزاري به كار گرفته مي‌شود.

در حقيقت هدف اصلي RUP مطمئن‌شدن از اين موضوع مهم است كه آيا نرم‌افزار توليدشده نيازهاي كاربرانش را به صورت كامل، با كيفيت بالا‌، در زمان معين و با بودجه مشخص برآورده كرده است يا خير.

 

مطابق تحقيقات انجام شده، از آن جايي كه RUP به تمامي اعضاي تيم، اطلاعاتي مشترك مي‌دهد و تمامي اعضاي گروه با يك زبان مشترك با هم مرتبط هستند، بازده كاري گروه را بالا مي‌برد.

 

RUP داراي سه جزء اصلي است. جزء اول از مجموع راه‌حل‌هاي خوب كه در رويه مي‌تواند مورد استفاده قرار گيرد تشكيل شده است. جزء دوم همان مراحل تهيه نرم‌افزار است و جزء آخر قسمت‌هاي تشكيل‌دهنده اين رويه مي باشد.

  RUP شش راه‌حل خوب كه مي‌تواند در مراحل مختلف اين رويه به ما كمك كند را معرفي كرده است. از آن جمله:

 

1- استفاده از USE CASEها كه مي‌توانند در جمعآوري نيازهاي كاربران مفيد باشند.

 

2- استفاده از معماري نرم‌افزار قابل تغيير‌ ( onent reuse)

 

3- استفاده از روش‌هاي تكميلي و Iterative براي كنترل بهتر و آسان پروژه نرم‌افزاري‌

 

4- استفاده از نمودارهاي UML

 

5- كنترل تغييرات در نرم‌افزار

 

6- كنترل كيفيت نرم‌افزار با توجه به درخواست‌هاي اوليه كاربران

 

شكل 3 رويه RUP را نمايش مي‌دهد. همان‌طور كه در اين شكل مشخص شده است چرخه توليد نرم‌افزار به چهار قسمت اصلي تقسيم شده است:

 

الف: Inception phase يا مرحله آغازين:

در اين مرحله اهداف پروژه مشخص شده و درخواست‌هاي اوليه كاربران تعريف مي‌شود. از خروجي‌هاي اين مرحله مي‌توان به مدل اوليه Use Case، آزمون ريسك در پروژه و برنامه زمانبندي پروژه اشاره كرد.

 

ب: Elaboration phase يا مرحله مقدماتي:

در اين مرحله نيازهاي كاربران تحليل و بررسي شده و راه‌حل كلي طراحي سيستم ترسيم مي‌شود. از خروجي‌هاي اين مرحله مي‌توان از مدل كامل شده Use Case، فهرست نيازهاي كامل كاربران و طرح كلي سيستم نام برد.

 

ج: Construction phase:

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

 

د: Transition phase يا مرحله تغييرات:

در اين مرحله اگر نرم‌افزار به وجود آمده در مرحله ساخت دچار مشكل شود، مشكل رفع خواهد شد.

 

 

همانطور كه در شكل 3 مشاهده مي‌كنيد، تمامي مراحل توسط خطوط عمودي از همديگر جدا شده‌اند و هر مرحله با يك milestone يا نقطه مهم تمام مي‌شود. روش RUP با استفاده از مدل‌هاي مختلف همچنين مشخص مي‌كند چه كسي، چگونه و چه وقت چه كاري را انجام خواهد داد.

 

همان‌طور كه در اين قسمت ذكر شد، روش RUP روشي انعطاف پذير، قابل تغيير و پيشرفته است كه مي‌تواند در صورت استفاده صحيح، باعث افزايش كارايي و كيفيت نرم‌افزار توليدي گردد. اما آيا RUP مي‌تواند رويه خوبي براي توليد نرم‌افزارهاي كوچك باشد؟ در جواب بايد گفت كه RUP را طوري طراحي كرده‌اند كه بتواند براي انواع پروژه‌هاي نرم‌افزاري در هر اندازه مفيد باشد و از آن جايي كه از ابزارهاي خوبي مثل UML نيز استفاده مي‌كند، UML) در گروه‌هاي كوچك كه نرم‌افزارهاي كوچك طراحي مي‌كنند ابزار مدلي خوبي است) مي‌تواند باعث همكاري و هماهنگي بيشتر گروه گردد.

 

اما همان‌طور كه در ادامه اين بحث خواهيد ديد، اگر بتوانيم رويه‌هاي ساده‌تر را با يكديگر ادغام كنيم، شايد بتوانيم راه حلي با كارايي بالاتري داشته باشيم. جهت مطالعه بيشتر در مورد RUP مي‌توانيد به نشاني http://ref.web.cern.ch/ref/CERN/CNL/2002/001/SDTRUP مراجعه كنيد.

 

روش هاي PSP و TSP

PSP يا Personal Software Process در حقيقت روش توليد نرم‌افزار نيست بلكه روشي است نوين كه با ملزم نمودن اعضاي گروه پروژه‌هاي نرم‌افزاري به رعايت اصولي مشخص و استفاده از فرم‌ها و تكاليفي مشخص به آن‌ها كمك مي‌كند كارايي و بهره‌وري كاري خود را بالا ببرند. اين روش همچنين حاوي تكنيك‌هاي خوبي براي كنترل، ا‌ندازه‌گيري و تشخيص اشكالات مي‌باشد كه مي‌تواند به شخص (مثلاً برنامه‌نويس) كمك كند تا مثلاً با اندازه‌گيري نرم‌افزار، يادداشت ميزان فعاليت روزانه و ساعات هدر رفته، و اشكالات به وجود آمده، مشكلات را حل كند و در نتيجه بهره‌وري خود را بالاتر ببرد. TSP يا Team Software Process مانند PSP است، ولي براي يك تيم طراحي شده و با طرح روش‌هاي منظم جهت كنترل و جمع‌آوري اطلاعات روزانه به اعضاي تيم كمك مي‌كند تا كارايي خود را بالا ببرند.

 

راه‌حل‌هاي پيشنهادي

تا اين قسمت با برخي از روش‌هاي توليد نرم‌افزار آشنا شديم. اگر دقت كنيد تمامي اين روش‌ها و رويه‌ها مي‌توانستند براي توليد نرم‌افزارهاي كوچك مورداستفاده قرار گيرند، اما در ادامه مقاله با چند روش‌ جديد آشنا خواهيد شد كه در چندين گروه نرم‌افزاري كوچك مورد آزمايش قرار گرفته‌اند و در تمامي موارد بازدهي درخور داشته‌اند. در واقع نمي‌توان گفت تمامي روش‌هاي زير روش‌هاي جديدي هستند، بلكه برخي از آن‌ها از ادغام روش‌هاي بالا به وجود آمده‌اند.

 

روش RUP Scrum

همان‌طور كه قبلاً اشاره شد، روش Scrum روشي آسان براي توليد نرم‌افزار است كه مديريت پروژه و نظم موجود در آن مي‌تواند بسيار كارگشا باشد. حال تجسم كنيد كه روش RUP را اجرا و قسمت‌هايي از Scrum را در آن ادغام كنيم. پس از اين كار متوجه خواهيد شد كه روش RUP مي‌تواند از مدل Scrum كمك بگيرد و با ادغام اين دو مي‌توان پروسه‌اي منظم براي توليد نرم‌افزارهاي كوچك سازماندهي كرد. اما همان‌طور كه مي‌دانيد نمي‌توان دو رويه ناهمگون را با هم تركيب نمود. آيا RUP و Scrum با هم شباهت‌هايي دارند؟

 

همان‌طور كه قبلاً بيان شد، هر دو رويه ساخت نرم‌افزار روش حلقه‌اي تكراركننده يا Iterative را خط مشي خود قرار داده‌اند(البته در RUP تعريف بهتر و كامل‌تري از Iterative شده است). در Scrum تعريف نيازهاي كاربران توسط اعضاي تيم انجام مي‌پذيرد، اما در RUP تنها يك شخصRequirement Engineer) يا مهندس مسئول نيازهاي كاربران) است كه اين مسئوليت را برعهده دارد. در زمينه مدل سيستم اگر چه Scrum مسئوليت انجام اين كار را به تمامي اعضاي گروه داده است، اما هر دو روش از مدل UML پشتيباني مي‌كنند و استفاده از آن را پيشنهاد مي‌دهند.

 

ضمناً هر دوي اين روش‌ها روش‌هاي هوشمند و Iterative هستند كه مديريت و اندازه گيري كيفيت نرم‌افزار در تمامي مراحل اين رويه‌ها به خوبي ديده مي‌شود. همچنين هر دوي اين روش‌ها انجام تغييرات را در طول پروژه مجاز مي‌دانند. البته همان‌طور كه در قسمت Scrum توضيح داده شد، اين روش تغييرات را در طول مراحل Sprint مجاز نمي‌داند، اما مدير Scrum مي‌تواند تغييرات درخواستي توسط كاربران را جمعآوري و در جلسه بعدي مطرح نمايد.

 

به تازگي RUP نيز ابزارهاي جديدي مانند RUP Builder و RUP modeller را عرضه كرده كه به مديران پروژه‌ها اجازه مي‌دهد تا برخي از اصول Scrum را درRUP اجرا كنند. در نتيجه اين دو پروسه توليد نرم‌افزار مي‌توانند به كمك بيايند و روشي مناسب براي توليد نرم‌افزارها به‌خصوص در اندازه كوچك باشند.

 

 

روش RUP XP

روش دومي كه مورد آزمايش قرار گرفت، تلفيقي بود از اكس‌پي و RUP. ولي مي‌توان گفت ادغام اين دو رويه بسيار متفاوت است.

 

RUP رويه‌اي بسيار سنگين و اكس‌پي روشي بسيار سبك شكل 4است. مي‌دانيد كه RUP را مي‌توانيم تقريباً براي تمامي نرم‌افزارهاي كوچك و بزرگ به كار برد. اكس‌پي نيز همانند RUP براساس Iterationها يا مراحل پيوسته مانند تحليل، طراحي و امتحان نرم‌افزار استوار است.

 

از آن جايي كه RUP و اكس‌پي از اساس با هم تفاوت‌هاي زيادي دارند و اكثراً تصور مي‌كنند كه RUP راه‌حلي براي توليد نرم‌افزارهاي بزرگ و اكس‌پي براي توليد نرم‌افزارهاي كوچك است، ممكن شما هم تصور كنيد كه استفاده همزمان از هر دوي اين روش‌ها كاردرستي نيست.

 

اما مطابق تحقيقات انجام شده به نظر مي‌رسد كه براي توليد نرم‌افزارهاي كوچك روشي بين RUP و اكس‌پي نياز است.در نتيجه با اضافه‌كردن برخي از تكنيك‌هاي اكس‌پي به RUP مي‌توان به رويه‌اي مناسب‌تردست يافت. قبلاً نيز محققاني روي RUP كار كرده‌اند تا آن را براي پروژه‌هاي كوچك مناسب سازند. مثلاً در سال 2000 يك نسخه از RUP به نام dX معرفي گرديد كه RUP مختصر شده‌اي بود. براي نرم‌افزارهاي كوچك (كه اعضاي پروژه اغلب در يك محيط كار مي‌كنند) اكس‌پي مي‌تواند روشي بسيار خوب باشد، اما اگر اعضاي تيم پراكنده باشند و سيستم بخواهد توسعه يابد، اكس‌پي قادر به جوابگويي نيست و مي‌توان گفت كه با استفاده از قسمت‌هايي از روش قدرتمند RUP مي‌توان به اكس‌پي كمك نمود.

 

براي تلفيق اين دو روش تصوركنيد كه پروژه‌اي شروع شده است. در مرحله Inception يا آغازين مي‌توان از تكنيك‌هاي اكس‌پي در زمينه برنامه‌ريزي زماني و جمع آوري نيازهاي سيستم استفاده نمود. البته نمي‌توان گفت كه هميشه اين دو روش با هم سازگار هستند. مثلاً در اكس‌پي مرحله‌اي به نام طراحي يا Design Phase وجود ندارد. در صورتي كه RUP يك مرحله مجزا براي اين قسمت دارد.

 

روش Iterative Process

شايد به نظر برسد كه در پروژه‌هاي كوچك، اعضاي گروه نياز كمتري به ارتباط با يكديگر دارند. اما از آن جايي كه در اين گونه پروژه ها ارتباط بين اعضاي تيم و كاربر نزديك‌تر است و عوامل خارجي نيز نقش مهمي را در پروژه‌ بازي مي‌كنند، در اين پروژه‌ها نياز به ارتباط بين اعضاي تيم محسوس به نظر مي‌رسد. همچنين اگرچه پروژه‌هاي نرم‌افزاري كوچك طبيعتاً نياز به نوشتن كدهاي كمتري دارند و ممكن است به چند مدير نياز نداشته باشند اما مانند پروژه‌هاي بزرگ بايد نرم‌افزاري با كيفيت بالا ارائه دهند. در نتيجه مي‌توان گفت كه روشي براي توليد نرم‌افزار كوچك مناسب‌تر است كه تمامي موارد مذكور را در نظر بگيرد و اجرا كند.

 

رويه Iterative يكي از اين روش‌ها است. با استفاده از اين رويه دو نوع محصول به نام‌هاي Actual و by-product توليد مي‌گردد. در واقع محصولاتي كه در موفقيت پروژه نقش اساسي بازي مي‌كنند، Actulas و آن دسته كه به وجود آمدن Actualsها كمك مي‌كنند را By-Product مي‌گويند (مثلاً طرح اوليه سيستم). در اين مدل هر عضو از گروه مسئول انجام‌دادن قسمتي از كار مي‌شود و اين مدل همان‌طور كه در شكل 5 مشاهده مي‌كنيد، شامل هشت مرحله يا فاز است.

 

 

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

 

وقتي اين مرحله تمام شد و كدهاي سيستم نوشته شد، اعضاي تيم در فاز جمع‌بندي كدهاي سيستم را با توجه به مراحل اول تا پنج مرور مي‌كنند. در مرحله آخر نيز اعضاي گروه را امتحان مي‌كنند تا اولاً نيازهاي كاربران را تأمين كرده باشد و ثانياً فاقد هرگونه اشكال باشد. اگر نرم‌افزار فاقد اشكال باشد، رويه توليد نرم‌افزار به آخر خواهد رسيد. در غير اين صورت، اعضاي گروه به دنبال منبع مشكل در مراحل قبلي مي‌گردند و مجدداً رويه را از آن جايي كه فكر مي‌كنند باعث بروز اشكال شده است، ادامه مي‌دهند.

 

نتيجه گيري

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

 

از جمله اين رويه‌هاي ساده مي‌توان از Scrum نام برد. Scrum يك تكنيك مديريت پروژه است كه مي‌تواند به تيم‌هاي نرم‌افزاري كوچك كه روي پروژه‌هاي كوچك نرم‌افزاري كار مي‌كنند كمك كند راندمان و كارايي بالاتري در كار داشته باشند. اما اگر اين روش‌ها را با روش‌هاي مناسب ديگر ادغام كنيم، مي‌توانند بيشتر مفيد واقع گردند.

 

پس از Scrum، روش اكس‌پي توضيح داده شد و به عنوان بهترين راه براي توليد نرم‌افزارهاي كوچك از آن نام برده شد. اما اين روش به تنهايي كارايي چنداني نخواهد داشت. سپس RUP كه مي‌تواند در تمامي پروژه‌ها استفاده شود تشريح شد و در ادامه سه روش مناسب براي توليد نرم‌افزارهاي كوچك ارائه گرديد. اما همان‌طور كه بحث شد، داشتن يك روش مناسب به تنهايي نمي‌تواند ضامن موفقيت در پروژه باشد، بلكه انتخاب منابع انساني مناسب و با تجربه مي‌تواند راه را براي موفقيت پروژه‌هاي نرم‌افزاري هموارتر سازد.

 

منابع:

http://xprogramming.com/xpmag/whatisxp.htm

www-128.ibm.com/developerworks/rational/library/feb05/krebs

www-106.ibm.com/developerworks/rational/library/409.html

 

در ادامه مطلب قسمت دوم با يكسري مثالها در خصوص كاهش ريسك پروژه هاي نرم افزاري از طريق دقت در استخراج نيازمنديها صحبت شده است.

تشخيص ، تعريف ، تجزيه ، درستي و قابليت ارزيابي نيازمنديها يكي از بزرگترين مسائل پيش روي مهندسين نرم افزار مي باشد.در اكثر مستندات نيازمنديها ، نيازمنديهاي موجود مبهم و متناقض مي باشد در بعضي موارد نيازمنديها به صورت يكتا تعريف نشده و نهايتا منجر به اين مي گردد كه قابل پيگيري نبوده و تست آنها به سختي صورت پذيرد.در بسياري از حالات نيازمنديها بسيار سطحي و يا بسيار جزيي و در سطح تحليل سيستم بيان گرديده است(نه در سطح نيازمنديهاي نرم افزار)

اگر با استفاده از روشهايي بتوانيم بر اين مشكلات فائق آييم مي توانيم ريسك توسعه سيستمهاي نرم افزاري را (ريسك عدم پوشش نيازمنديها) تا حد زيادي كاهش دهيم.

در اين مثالها سعي شده است روش برخورد با مسائلي كه افراد مرتبط در تعيين نيازمنديها با آن دست و پنجه نرم مي كنند عنوان  گردد.

صورت كلي مثال : طبق برنامه ريزي مقرر گرديد تا نسبت به توسعه مجدد نرم افزارهاي قبلي اقدام گردد در اين راستا با توجه به محدوده سيستم ، چند تيم بصورت همزمان وظيفه مهندسي مجدد سيستمهاي موجود و تعريف نيازمنديها را عهده دار شدند و مشاوري جهت راهنمايي به تيمها در راستاي استخراج صحيح نيازمنديها بكار گرفته شده است.

 

مثالهاي مرتبط :

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

 

مثال 7 :

نيازمندي اوليه : 3.2.7.1 سيستم نبايد مانع  وارد نمودن سال از جانب كاربران كه قصد ورود اطلاعات پرداخت را دارند گردد اما مي بايد امكاني را فراهم نمايد كه آنها از درستي سال وارد شده مطمئن گردند.

ايرادات : اين يك نيازمندي منفي مي باشد نيازمنديهاي منفي نمي بايد تعريف شوند(عدم نيازمندي) زيرا آنها قابل پياده سازي نيستند. در نيازمنديها مي بايست تمامي شرايطي كه بايد وجود داشته باشد بيان گردد. اگر شرايطي لازم نيست پياده سازي نيز نمي شوند. علاوه بر آن دوبار از بايد(يكبار مثبت ، يكبار منفي) در يك نيازمندي استفاده شده است.

نيازمندي بازنويسي شده : 3.2.7.1 سيستم مي بايست :

1.       اجازه ورود سال پرداخت را به كاربر بدهد.

2.       ‎ٌامكاني جهت اطمينان كاربر از صحت سال پرداخت وارد شده فراهم نمايد.

 

 

مثال 8 :

نيازمندي اوليه : 3.2.7.3 بعد از اين كه سيستم يك فايل سالم را دريافت نمود، سيستم مي بايست:

• اگاه ساختن كاربر از پذيرش با عدم پذيرش فايل
• فايل پذيرفته شده مي بايست شامل نام و كد پستي فرد ارسال كننده باشد.
• درخواست پذيرفته نشده مي بايست شامل يك (كد علت عدم پذيرش) باشد.

 

ايرادات : آيتم دوم و سوم در صورتي كه مستقل از آيتم اول خوانده شوند هيچ معنايي ندارند :

• سيستم مي بايست فايل پذيرفته شده مي بايست ….
• سيستم مي بايست درخواست پذيرفته نشده مي بايست ….

از طرف ديگر استفاده از Bullets در تعريف نيازمنديها نبايد استفاده شود زير امكان رديابي وجود ندارد بنابراين از شماره گذاري و يا حروف استفاده نماييد. در كل اين نيازمندي مبهم بوده و قابل پياده سازي و تست نمي باشد.

نيازمندي بازنويسي شده : 3.2.7.3 هنگامي كه سيستم يك فايل سالم را دريافت مي نمايد مي بايست :

1.       عدم پذيرش فايل در صورتي كه شامل مشخصات ذيل از شخص تاييد كننده نمي باشد:

a.       نام

b.       كد پستي

2.       آگاه سازي شخص درباره پذيرش و يا عدم پذيرش با كد علت عدم پذيرش.مرجع كد علت ها جدول شماره 5.4.8 مي باشد.

 

مثال 9 :

نيازمندي اوليه :

 3.2.8.2 فرايند ثبت نام در انواع روشهاي ثبت نام بين 1 تا 10 روز بطول انجامد.

3.2.8.3 فرايند ثبت نام در موارد ذيل نبايد بيش از 3 روز بطول بينجامد.:

1.       ثبت نام با استفاده از كارت اعتباري

2.       ثبت نام بصورت درخواست كتبي

ايرادات : اين دو نيازمندي در تناقض با هم مي باشد.

نيازمندي بازنويسي شده : 3.2.8.2 فرايند ثبت نام مي بايست :

1.       براي روشهاي ثبت نام ذيل بين 1 تا 3 روز بطول بينجامد:

a.       ثبت نام با استفاده از كارت اعتباري

b.       ثبت نام بصورت درخواست كتبي

2.       براي ساير روشهاي ثبت نام بين 1 تا 10 روز بطول بينجامد.

 

مثال 10 :

نيازمندي اوليه : 3.2.8.6 هنگامي كه نرم افزار محاسباتي را انجام مي دهد مي بايست نتايج صحيح توليد نمايد.

 ايرادات : واقعا ؟ اين يك نيازمندي نيست. اين نوع از نيازها نبايد تعريف گردد.

نيازمندي بازنويسي شده : حذف نيازمندي

 

نتيجه گيري :

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

مرجع :

1.        Military Standard Specification Practices. MIL-STD-490A. U.S. Department of Defense, 4 June 1985.

منابع مفيد جهت مطالعه بيشتر :

1.       IEEE Std. 830-1998. IEEE Recommended Practices for Software Requirements Specifications. IEEE Computer Society. 20 Oct. 1998.

2.       Cook, David A., and Les Dupaix. “The Requirements for Good Requirements.” Software Technology Conference Proceedings. Mar. 2001.