فرآیند توسعه

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

فرآیند توسعه نرم افزار چیست؟

فرآیند مشخص می کند که چه کسی ، چه کاری را درچه موقعی و چگونه انجام دهد، تا به یک هدف خاص برسیم(who?, what?, when? And how?) . در مهندسی نرم افزار منظور از این هدف خاص، ساخت یک نرم افزار جدید یا بهبود یک نرم افزار موجود می باشد. یک فرآیند موثر مسیری را برای توسعه کارآمد نرم افزار فراهم می نماید، این فرآیند با توجه به شرایط موجود در سیستم تحت مطالعه نمونه های عملی متناسب را ارائه می دهد که بهترین راهکارهای موجود را برای شرایط جاری پیشنهاد می کند. در واقع فرآیند با ارائه راهنماییها و نمونه های عملی توسعه نرم افزار میزان ریسک را کاهش می دهد و به توانایی توسعه دهنده برای پیشگویی آینده پروژه می افزاید و بطور کلی یک دید و فرهنگ عمومی را برای توسعه نرم افزارهای مختلف ترویج می دهد.
ما به فرآیندی نیاز داریم که همه افراد دخیل در توسعه نرم افزار را هدایت کند - مشتریان ،کاربران،توسعه دهندگان و مدیران اجرایی. بنابراین فرآیند مذکور باید بصورت گسترده دردسترس باشند تا همه افراد ذینفع نقش آن را در توسعه نرم افزار درک کنند. نهایتاً فرآیند باید با توجه به تکنولوژی، ابزارها و ساختارهای سازمانی قابل تغییرباشد.

ابزارها(Tools): فرآیندها و ابزارها باید به صورت موازی گسترش یابند.

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

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

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

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

شروع Inception

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

تفصیل Elabboration

بعد از اینکه مجوز ادامه کار را از مسؤل پروژه گرفتیم، در این مرحله ما تنها لیستی ناقص از نیازهای کلی سیستم که مبهم و غیر گویا است، داریم در اینجا می خواهیم درک بهتری از مسئله داشته باشیم و بررسی می کنیم که: (1) واقعاً می خواهیم چه چیزی بسازیم؟ (2) چگونه سیستم موردنظر را بسازیم؟ درواقع دراین مرحله نیازهای کاربر بصورت دقیق، با جزئیات کامل در قالب موارد قابل کاربرد شناسایی می شود. این مرحله غالباً با ریسک همراه است، انواع ریسک های ممکن به چهار دسته تقسیم می- شوند:
ریسک نیازمندیها : نیازمندیهای سیستم کدامند؟ در تولید نرم افزار بدترین حالت هنگامی است که سیستم نادرستی تولید شود یعنی تفسیر نادرستی از نیازهای کاربر را در ساخت سیستم ملاک قرارداده ایم و سیستم تولید شده نیازهای کاربر را برآورده نمی- کند(درک نکردن سیستم مورد نیاز).
ریسک فنی: آیا تکنولوژیی که برای ساخت نرم افزار انتخاب شده واقعاً کار مورد نظر را انجام می دهد؟
ریسک مهارتها: آیا تخصص های لازم را برای انجام کار داریم؟
ریسک سیاسی: آیا انجام پروژه از نظر سیاسی مشکل ساز نیست؟
در زیر ریسک نیازمندیها به تفصیل بررسی می شود .

ریسک نیازمندیها

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

موارد قابل کاربرد کل سیستم را منعکس نمی کنند یعنی اسکلتِ یک مدل مفهومی از دامنه مسئله را نشان می دهند. بطور کلی برای بررسی و کشف دقیق نیازمندیها باید به مدل سازی دست بزنیم و با استفاده از مدل سازی دامنة مسئله را تصویر کنیم . مدلهای مختلفی وجود دارند که ماهیت سیستم مورد مطالعه را به روشنی نشان می دهند که تعدادی ازآنها عبارتند از(1) مدلها ی دامنة مسئله و موارد قابل کاربرد، (2) مدلهای تحلیلی و (3) مدلهای طراحی که در فصل قبل معرفی شد. درUML برای ایجاد مدلهای دامنة مسئله استفاده از نمودار های زیر پیشنهاد می شود:

• نمودارهای کلاس از چشم انداز مفهومی
• نمودارهای فعالیت ؛ این نمودارها در فصل بعد به تفصیل خواهد آمد.

ازمهمترین عناصر در کشف نیازمندیها میزان ارتباط با خبره های دامنة مسئله است. در پایان مرحله تفصیل معماری خط پایه سیستم مشخص می شود این معماری شامل (1) لیست تمامی موارد قابل کاربرد که نیازمندیهای سیستم را بیان می کند. (2) مدل دامنة مسئله که یک نقطه شروع برای کارهای بعدی است و (3) ساختار تکنولوژی انتخاب شده . به این معماری ، طرح اولیه گفته می شود.

برنامه ریزی مرحله ساخت

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

در قدم اول باید موارد قابل کاربرد طبقه بندی شود، مشتری موارد قابل کاربرد را با توجه به ارزش کار در سه سطح بالا، متوسط و پایین طبقه بندی می کند و به هر مورد قابل کاربرد یک اولویت نسبت داده می شود سپس مشتری مضمون هرطبقه را یادداشت میکند.

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

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

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

مرحله ساخت

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

مرحله انتقال

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