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 تيمي متشكل از هشت نفر است كه با همكاري بسيار نزديك با يكديگر بازي مي‌كنند).

شکل 1

در اين روش هر عضو از گروه موظف به درك وظيفه خود در پروژه است و بايد يك هدف مشخص را در تمامي مراحل عملياتي يا فازهاي اجرايي دنبال كند. لازم به ذكر است كه در 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 اصول روش اكس‌پي را نشان مي‌دهد.

شکل 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

همانطور كه در شكل 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 اجرا كنند. در نتيجه اين دو پروسه توليد نرم‌افزار مي‌توانند به كمك بيايند و روشي مناسب براي توليد نرم‌افزارها به‌خصوص در اندازه كوچك باشند.

شکل 4

روش 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 مشاهده مي‌كنيد، شامل هشت مرحله يا فاز است.

شکل 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

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

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

• 2.1 مهندسی نرم‌افزار و فرایندهای آن 

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

  • 2.1.1 جمع‌آوری نیازمندیها 

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

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

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

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

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

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

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

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

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

  2.2 فرایند تولید نرم‌افزار متن‌باز 

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

  • 2.2.1 فرایند تولید نرم‌افزار متن‌باز بدون حمایت مالی 

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

    • 2.2.1.1 جمع‌آوری نیازمندیها 

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

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

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

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

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

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

    2.2.2 فرایند تولید نرم‌افزار متن‌باز تجاری 

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

3 نگاه عمیق‌تر به فرایند تولید نرم‌افزار متن‌باز 

• 3.1 نمونه‌سازی[1] 

  فرآیند نمونه‌سازی در بسیاری از پروژه‌های متن‌باز دیده می‌شود. بسیاری از پروژه‌ها، معمولاً به صورت ناآگاهانه، از متدولوژی برنامه‌نویسی گروهی[2] استفاده می‌کنند. جملات مصطلح در تولید نرم‌افزار متن‌باز مانند “زود خروجی بده، همیشه خروجی بده” و “کدت را به من نشان بده” مثال‌های خوبی در این زمینه هستند. توسعه‌دهندگان به کار کردن با روشهای آزمایشی ترغیب می‌شوند و اگر تست‌کنندگان از بازخورد مثبتی ارایه کنند، کار آنها ممکن است با خط اصلی تولید نرم‌افزار یکپارچه شود. نمونه‌سازی سریع، احتمالاً یک از قوی‌ترین خصوصیات پروژه های متن‌باز است. [7] توضیح می‌دهد: 

  “ما هرگز از روش XP استفاده نمی‌کنیم. کلمه XP زمانی که ما پروژه را شروع کردیم، وجود نداشت. ما بعدها در پروژه‌مان از روش XP استفاده کردیم. XP روش خوبی برای پروژه های نرم‌افزار است اگر:

  • · پروژه بزرگ نباشد. 
    · یک یا چند عضو اساسی در تیم وجود داشته باشند. 
    · چند همکار و کمک کننده در پروژه وجود داشته باشد. 
    · پروژه برای سود نباشد. 
    · پروژه برای مشتری خاصی نباشد.”

  
  دیگران، مانند Linus Trovalds، نگاه ریشه‌ای به قضییه دارند؛ به این شکل که “هیچ کس به اندازۀ من Linux را “طراحی” نکرد، و من شک دارم که بسیاری با من مخالف باشند. Linux رشد کرد؛ با بسیاری از تغییرات رشد کرد، و به خاطر اینکه تغییرات کمتر از اتفاقات بودند، تغییرات سریعتر و جهت‌دار تر از ذرات اولیه DNA بودند.” 
  Trovalds معتقد است که نرم‌افزارها طراحی نمی‌شوند، بلکه متکامل می‌شوند. او می‌گوید “و حتی من جلوتر می‌روم و ادعا می‌کنم که هیچ نرم‌افزار بزرگی که در بازارهای عمومی موفق بوده بر پایه این چرخه عمر زیبا نوشته نشده است. آیا شما پروژه‌ای را می‌شناسید که واقعاً با فهمیدن اینکه چه کاری باید انجام بشود، فاز طراحی موشکافانه و فاز پیاده‌سازی به پایان رسیده باشد… 
  نرم‌افزار متکامل می‌شود؛ طراحی نمی‌شود. تنها سؤال این است که شما چقدر دقیق تکامل پروژه را کنترل کنید و چقدر باز نسبت به تغییر کدهای خارجی رفتار می‌کنید. 
  کنترل بیش از حد فرآیند تکامل، شما را می‌کشد. قطعاً و بدون تردید. همیشه: چه در زیست‌شناسی و چه در نرم‌افزار.” 
  3.2 مدیریت نسخه‌ها 

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

  • ۱) این توانایی به توسعه‌دهندگان داده می‌شود که کد برنامه را آزمایشی تغییر دهند، این تغییرات را اعمال کنند و هرگاه که به بن‌بست رسیدند به حالت پایدار قبلی خود بازگردند. 
    ۲) مدیریت نسخه‌ها به طور معمول پیشینه‌ تمامی نسخه‌ها را نگاه‌داری می‌کند و این قابلیت را در اختیار توسعه‌دهنده می‌گذارد که گزارش تغییرات داده شده را ذخیره کند. این گزارشات به عنوان یک مستند قابل اتکا برای فرایند توسعه می‌باشند و در اغلب اوقات صحیح‌ترین چیزی هستند که شرح حالت فعلی پروژه را بیان می‌کنند. 
    ۳) یکی‌سازی ده‌ها و شاید صدها تغییرات داده شده توسط افراد به صورت دستی تقریباً کار غیر ممکنی می‌باشد. سیستم‌های همزمان تجدید‌نظر نظیر CVS به توسعه‌دهندگان کمک می‌کنند که هماهنگ‌سازی و یکی‌کردن کارهای توزیع شده را ساده‌تر انجام دهند.

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

• 1.1 مدیریت بیرون دادن خروجی[1] 

  پروژه‌های نرم‌افزاری متن‌باز بسیاری از نسخه‌های کاری خود را با توجه به اصل “زود خروجی بده، همیشه خروجی بده”[2] به عنوان خروجی بیرون می‌دهند. اگرچه به طور معمول ساده است که بین نسخه‌های مختلف با استفاده از شماره‌ نسخه تفکیک قایل شویم اما گاهی‌اوقات درک این موضوع که یک شماره‌ نسخه چه معنی می‌دهد بسیار مشکل است. به عنوان مثال یک بیرون دادن خروجی لینوکس اینگونه توصیف شده است که “نسخه 2.4.0-test1 که در واقع همان نسخه 2.3.99-pre10-pre3 است بیرون داده شد.”. با اینکه بعضی از پروژه‌ها از شیوه غریبی برای شماره‌گذاری نسخه‌هایشان استفاده می‌کنند اما به طور معمول چند نکته برجسته در این کار مشخص است:

  • · عددگذاری: 

    اکثر پروژه‌ها از یک شیوه عدد گذاری برای شماره‌ نسخه‌هایشان استفاده می‌کنند. به عنوان مثال عدد 2.3.20 به این معنی است که شماره‌ اصلی ۲ و شاخه‌ی‌ توسعه ۳ و نقطه‌ بیرون دادن خروجی ۲۰. بسیاری از پروژه‌ها در یک زمان ممکن است دارای چند خط توسعه باشند که در آن صورت اعداد زوج در مکان دوم شماره‌ نسخه به معنی شاخه پایدار می‌باشند و اعداد فرد به مشخص‌کننده شاخه توسعه هستند. 
    · شاخه‌های توسعه 

    بسیاری از پروژه‌ها شاخه‌های متفاوتی از توسعه را دارا می‌باشند و شاخه‌هایشان را پایدار (برای استفاده از محصول) و آزمایشی (مخصوص توسعه‌دهنده‌ها) می‌نامند. بعضی از پروژه‌ها حتی از سه شاخه استفاده می‌کنند مانند پروژه Debian که دارای سه شاخه پایدار، در حال آزمایش و ناپایدار می‌باشد. 
    · وضعیت کاری 

    نرم‌افزارهای متن‌باز اغلب از واژه‌هایی برای مشخص کردن وضعیت کاری پروژه استفاده می‌کنند: آلفا (در حال توسعه)، بتا (در حال تکمیل قابلیت)، pre (نامزدهای ممکن بیرون‌داده شدن)، RC (نامزدهای بیرون‌داده شدن)، نهایی (خروجی بیرون‌داده شده رسمی). 
    · نامهای به‌صورت کد 

    بعضی از پروژه‌ها از نامهای به‌صورت کد برای بیرون دادنهای اصلیشان استفاده می‌کنند که به عنوان مثال potato به جای 2.2 نمونه‌ای از آن است. نامهای به‌صورت کد برای بسیاری از پروژه‌ها وسیله سرگرمی و یا بزرگ داشتن آن است و برای بدست آوردن این نامها تلاش زیادی صورت می‌گیرد. 
    · تاریخهای بیرون دادن 

    بعضی از پروژه‌ها از تاریخ بیرون دادن خود به عنوان شماره نسخه استفاده می‌کنند. 
    · نسخه‌های دلخواه 

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

  1.2 انتقال دادن 

  انتقال دادن واژه‌ای است که بسته‌ای کردن نرم‌افزار، مدیریت وابستگیها، سیاست ارتقا و نصب را در برمی‌گیرد. بسیاری از پروژه‌های متن‌باز در این زمینه دارای ضعفهایی هستند که شاید دلیل آن این باشد که گرایش این پروژه‌ها بیشتر به سمت کاربران خبره است که از آنها انتظار می‌رود قادر باشند که با این موضوعات به راحتی کنار بیایند. انتقال ضعیف یک مانع بسیار بزرگ در سرراه ورود به محدوده نرم‌افزارهای متن‌باز است. پروژه‌هایی که تلاش اضافی صرف می‌کنند که کاربر به راحتی بتواند برنامه آنها را نصب کند به راحتی می‌توانند کاربران و توسعه‌گران بیشتری را جذب کنند. یک نگاه تاریخی نشان می‌دهد که پروژه‌های متن‌باز زیاد به این قضییه توجه نداشته‌اند و برایشان مهم نبوده است که تنها یک گروه خاصی از افراد از محصولاتشان استفاده کنند. این دسته از پروژه‌ها سعی داشتند که با استفاده از یک محصول دارای ساختار مناسب و کارا باعث گسترش محصول خود شوند تا اینکه سعی کنند با استفاده از یک انتقال مناسب این جذب را فراهم سازند. اکنون مشخص شده است که اگر پروژه‌های متن‌باز سعی کنند این دو امر را باهم همراه سازند قطعاً کاربران بسیار زیادتری را نسبت به سایر نرم‌افزارها فراهم می‌کنند. 
  مدیریت وابستگیها بین بسته‌های نرم‌افزاری یک موضوع بسیار مهم در پروژه‌های متن‌باز می‌باشد. با توجه به خاصیت ذاتی پروژه‌های متن‌باز که استفاده مجدد از دیگر کدهاست، بسیاری از بسته‌ها به ده‌ها بسته‌ دیگر اعتماد می‌کنند و با فرض درست بودن آنها کار خود را انجام می‌دهند. راه‌حلهای مختلفی برای حل این مشکل توسعه داده شده است که یک نمونه آن APT است که Debian از آن استفاده می‌کند. APT قالبهای متعارفی تعریف می‌کند و با استفاده از آنها وابستگی بین بسته‌ها را تشخیص می‌دهد و قابلیت خودکار به‌روز شدن کامل سیستم را در اختیار می‌گذارد. 
  1.3 مستندسازی 

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

  • · داخلی و برخط 

    افراد غیر برنامه‌نویس عقیده دارند که کمک حساس به متن و برخط حتماً باید همراه با برنامه‌ کاربردی باشد. افراد غیربرنامه‌نویس به کمک برخط به عنوان یک مرجع سریع نگاه می‌کنند، برای همین اندیس‌گذاری کمک و توابع جستجو در کمک بسیار مهم هستند. اگر یک خودآموز برخط در برنامه کاربردی وجود داشته باشد، افراد غیربرنامه‌نویس حتماً به آن رجوع خواهندکرد. افراد غیربرنامه‌نویس به “Tips and Tricks”هایی که همراه با برنامه بیرون داده شده‌است رجوع می‌کنند. افراد غیربرنامه‌نویس به خودآموزهای چاپ‌شده‌ای که همراه با نرم‌افزار بیرون داده می‌شود رجوع خواهند کرد. افراد غیر‌برنامه‌نویس هیچ‌گاه یک کتاب راجع به یک برنامه کاربردی نمی‌خرند زیرا معتقدند که کتابهای فنی مختص برنامه‌نویسان است. 
    · ساده 

    افراد غیربرنامه‌نویس به هیچ‌وجه راجع به جزییات توضیح نمی‌خواهند. آنها به جوابهای ساده احتیاج دارند. این افراد از وارد شدن به جزییات بیزارند؛ دستورالعمل‌های کوتاه و باقاعده را دوست دارند؛ به اطلاعاتی علاقه دارند که جواب این سوال است: “چگونه من می‌توانم فلان کار را انجام دهم”(که فلان کار یک قابلیتی است که برنامه در اختیار شما قرار می‌دهد) و اینکه افراد غیربرنامه‌نویس نمی‌خواهند اطلاعاتی راجع به اینکه قابلیت‌های سیستم چگونه پیاده‌سازی شده‌اند مشاهده کنند. 
    · کامل، درست و به‌روز 

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

منبع : FOSS_ir طرح ملی نرم‌افزارهای آزاد-متن‌باز ایران

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

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

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

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

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

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

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

مثال 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.