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

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

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

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

روش Scrum

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

روش XP

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

روشRational Unified Process) ‌RUP)

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

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

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

به گزارش رویتر در سال 2001 میلادی بیش از ششصد هزار شرکت تولید کننده نرم افزار، از ابزارهای شرکت Rational استفاده می کرده‌اند که این تعداد کماکان هم در حال افزایش است. این متدولوژی، برای انواع پروژه‌های نرم‌افزاری در دامنه‌های مختلف ( مانند سیستم‌های اطلاعاتی، سیستم‌های صنعتی، سیستم‌های بلادرنگ، سیستم‌های تعبیه شده، ارتباطات راه دور، سیستم‌های نظامی و ...) و در اندازه‌های متفاوت، از پروژه‌های بسیار کوچک (یک نفر در یک هفته) تا پروژه‌های بسیار بزرگ (چند صد نفر تولید کننده با پراکندگی جغرافیایی)، کاربرد دارد.

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

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

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

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

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

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

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

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

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

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

- بدست‌ آوردن محدوده نرم‌افزاری پروژه و محدودیت‌های آن كه شامل یك دید عملیاتی، معیار پذیرش و اینكه چه چیز باید در محصول باشد و چه چیز نباید باشد، می‌شود

- مشخص كردن Use-Case های اساسی سیستم، سناریوهای اصلی عملیات كه مسائل مربوط به طراحی اصلی را ایجاد می‌كند.

- نمایش و شاید توضیح حداقل یك معماری كاندیدا برای بعضی سناریوهای اصلی

- برآورد هزینه و زمان كلی برای كل پروژه

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

- اطمینان از اینكه معماری، نیازمندی‌ها و طرح‌ها به اندازه‌ی كافی پایدارند و ریسك‌ها به اندازه‌ی كافی كاهش یافته‌اند بطوریكه بتوان هزینه و زمان‌بندی لازم برای تكمیل تولید را پیش‌بینی كرد. برای اكثر پروژه‌ها، گذر از این مرحله‌ی مهم مانند انتقال از یك عملیات سبك و سریع و با ریسك پایین به یك عملیات با هزینه و ریسك بالا همراه با اجبار سازمانی است.

- بیان همه‌ی ریسك‌های پروژه كه از نظر ساختاری اهمیت دارند.

- ایجاد یك معماری پایه، مشتق شده از سناریوهای مهم كه از لحاظ ساختاری اهمیت دارند، كه این معماری ریسك‌های فنی عمده پروژه را نیز مشخص می‌كند.

- تولید یك نمونه‌ی اولیه‌ی تكاملی از مولفه‌های با كیفیت تولیدی خوب، و همچنین یك یا چند نمونه‌ی اولیه‌ی اكتشافی و نمونه‌های اولیه‌ی غیر قابل استفاده جهت كاهش ریسكهای خاص مانند :‌

سازش‌های مربوط به نیازمند‌ی‌ها یا طراحی

استفاده‌ی مجدد از مؤلفه‌ها

عملی بودن محصول یا توضیحات برای سرمایه گذاران، مشتریان و كاربران نهایی

- توضیح اینكه معماری پایه از نیازمندی‌های سیستم با هزینه‌ی منطقی و در زمان منطقی پشتیبانی می‌كند

- ایجاد یك محیط پشتیبانی كننده

ج: Construction phase یا مرحله ساخت و توسعه:

- كمینه كردن هزینه‌های تولید با بهینه‌سازی منابع و پرهیز از دور انداختن و دوباره‌كاری غیر ضروری

- دستیابی هرچه سریعتر به كیفیت كافی

- دستیابی هر جه سریعتر به ویرایش‌های مفید (آلفا، بتا و سایر نسخه‌های تست)

- كامل كردن تحلیل، طراحی، تولید و تست كارآیی مورد نیاز

- تولید تكراری و گام به گام یك محصول كامل كه آماده‌ی انتقال به محیط كاربران باشد

- تصمیم در مورد اینكه آیا نرم‌افزار، سایت‌ها و كاربران همه برای استقرار طرح آمادگی دارند

- دستیابی به میزانی از موازی سازی در كار تیم‌های تولید.

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

- تست بتا برای تشخیص اعتبار سیستم جدید با توجه به انتظارات كاربر

- تست بتا و عملیات موازی همراه با یك سیستم قدیمی كه در حال جایگزینی می‌باشد.

- تبدیل پایگاه‌های داده‌ی عملیاتی

- آموزش كاربران و نگهداری كنندگان

- بازاریابی، توزیع و فروش برای نخستین انتشار محصول

- تنظیم فعالیت‌ها از قبیل رفع اشكال، افزایش كارایی و قابلیت استفاده

- ارزیابی خط مبناهای استقرار در مقایسه با تصویر كلی و معیار قابلیت قابل قبول برای محصول

- دستیابی به موافقت ذینفع در مورد اینكه خط مبناهای استقرار كامل می‌باشند

- دستیابی به موافقع ذینفع در مور اینكه خط مبناهای استقرار با معیار ارزیابی تصویر كلی سازگارند.

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

دیسیپلین‌های RUP

دیسیپلین مجموعه‌ای از کارهای به هم مرتبطی است که برای انجام جنبه خاصی از یک پروژه انجام می‌شوند. متدولوژی RUP دارای 6 دسیسپلین اصلی (مربوط به تولید محصول) و 3 دیسیپلین كمكی (مربوط به تیم و محیط تولید) است كه در ادامه به ترتیب معرفی خواهند شد.

دیسیپلین‌های اصلی:

Business Modeling (مدل‌سازی كسب و كار)

Requirements (نیازمندی‌ها)

Analysis & Design (تحلیل و طراحی)

Implementation (پیاده‌سازی)

Test (آزمون)

Deployment (استقرار)

دیسیپلین‌های کمکی:

Environment (محیط)

Project Management (مدیریت پروژه)

Configuration & Change Management (مدیریت پیكربندی و تغییرات)

تشریح دیسیپلین‌های اصلی:

1- Business Modeling (مدل‌سازی كسب و كار)

- شناخت ساختار و دینامیك‌های سازمانی كه در آن یك سیستم باید استقرار یابد(سازمان هدف).

- شناخت مشكلات فعلی در سازمان هدف و تشخیص پتانسیل‌های بهبود

- تضمین اینكه مشتری، كاربر نهایی و تولید كنندگان یك شناخت مشترك از سازمان هدف دارند.

- هدایت نیازمندی‌های سیستم كه برای حمایت از سازمان هدف مورد نیازند.

- دیسیپلین‌ مدل‌سازی كسب و كار توضیح می‌دهد كه برای رسیدن به این هدف چگونه می‌توان یك تصویر كلی از سازمان را تولید نمود، و براساس این تصویر كلی فرآیندها، نقش‌ها و مسؤولیت‌های آن سازمان را در یك مدل Use-case كسب وكار و یك مدل شیء كسب و كار تعریف كرد.

2- Requirements (نیازمندی‌ها)

- تشخیص و نگهداری موارد توافق با مشتری‌ها و سایر ذینفعان در مورد كارهایی كه سیستم باید انجام دهد.

- فرآهم آوردن شناخت بهتر از نیازمندی‌های سیستم برای تولید كنندگان سیستم

- تعریف مرزهای و حدود سیستم

- فراهم كردن یك پایه برای طرح ریزی مفاهیم تكنیكی تكرارها

- فراهم كردن یك پایه برای تخمین مخارج و زمان تولید سیستم

- تعریف یك واسط كاربر برای سیستم با تمركز بر روی نیازها واهداف كاربران

3- Analysis & Design (تحلیل و طراحی)

- تبدیل نیازمندی‌ها به طراحی سیستم كه قرار است بوجود آید.

- پیدایش یك معماری مستحكم برای سیستم

- سازگار ساختن طراحی برای هماهنگ شدن با محیط پیاده‌سازی و طراحی آن برای كارایی بهتر

4- Implementation (پیاده‌سازی)

- تعریف ساختمان كدها برای کدنویسی، برحسب زیر مجموعه‌ای از مجموعه‌های پیاده‌سازی سازمان یافته در لایه‌ها

- پیاده‌سازی كلاس‌ها و اشیاء بوسیله مؤلفه‌ها (فایل‌های منبع، باینری‌ها، فایل‌های اجرایی و ...)

- تست اجزاء تولید شده به عنوان واحد‌ها

- مجتمع‌سازی نتایج تولید شده توسط پیاده سازان فردی‌ (یا تیم‌ها) به صورت یك سیستم قابل اجرا.

5- Test (آزمون)

- یافتن و مستند كردن نقایص در كیفیت نرم‌افزار

- آگاهی دادن در مورد كیفیت نرم‌افزار بررسی شده

- اثبات اعتبار فرضیاتی كه در طراحی و مشخصات نیازمندی‌ها ساخته شدند، از طریق نمایش‌های واقعی

- تصدیق عملكردهای محصول نرم‌افزار همانطور كه طراحی شده است.

- تصدیق اینكه نیازمندی‌ها بدرستی پیاده‌سازی شده‌اند.

6- Deployment (استقرار)

- نصب اختصاصی

- آماده فروش كردن محصول نهایی

- دستیابی به نرم‌افزار از طریق اینترنت

تشریح دیسیپلین‌های کمکی:

7- Environment (محیط)

- دیسیپلین محیط بر فعالیت‌هایی كه برای پیكربندی فرآیند برای یك پروژه لازم و ضروری‌اند، متمركز می‌شود. این دیسیپلین فعالیت‌های مورد نیاز برای تولید رهنمودهایی كه در جهت پشتیبانی از یك پروژه لازم می‌باشند را توضیح می‌دهد. هدف فعالیت‌هایی محیطی فراهم آوردن محیط تولید (هم فرآیندها و هم ابزاری كه تیم تولید را پشتیبانی می‌كنند) برای سازمان تولید كننده نرم‌افزار می‌باشد.
جعبه ابزار مهندس فرآیند پشتیبانی ابزاری را برای پیكربندی یك فرآیند فراهم می‌كند. این مورد شامل ابزارها و نمونه‌هایی برای ایجاد سایتهای وب پروژه و سازمان بر اساس RUP می‌شود.

8- Project Management (مدیریت پروژه)

- فراهم كردن یك چارچوب برای مدیریت پروژه‌های صرفاً نرم‌افزاری

- فراهم كردن رهنمودهای عملی برای طرح‌ریزی، تعیین نیروی انسانی، اجرا و نظارت بر پروژه‌ها

- فراهم كردن یك چارچوب برای مدیریت ریسك

- با این وجود، این دیسیپلین از RUP برای پوشش دادن همه‌ی جنبه‌های مدیریت پروژه نیست. برای مثال این دیسیپلین موارد زیر را پوشش نمی‌دهد :‌

- مدیریت افراد : استخدام، آموزش، رهبری

- مدیریت بودجه : تعیین، تخصیص و غیره

- مدیریت قراردادها :‌ با پشتیبانی كنندگان و مشتریان

- این دیسیپلین بطور عمده روی جنبه‌های مهم یك فرآیند تكراری تمركز می‌كند كه عبارتند از :

- مدیریت ریسك

- طرح ریزی برای یك پروژه‌ی تكراری، از طریق چرخه‌ی حیات و برای یك تكرار بخصوص

- نظارت بر پیشرفت یك پروژه‌ی تكراری و متریك‌ها

9- Configuration & Change Management (مدیریت پیكربندی و تغییرات)

- تشخیص موارد پیكربندی

- محدود كردن تغییرات آن موارد

- رسیدگی به تغییراتی كه برای آن موارد ساخته شده

- تعریف و مدیریت پیكربندی آن موارد

http://st.aftab.cc