فرآيند توسعه نرم افزار

فرآيند توسعه نرم افزار

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

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

در ساخت يک سيستم نرم افزاري سه فرآيند مهم تاثير گذار مي باشند:
- فرآيند توسعه (

Development Process): سازماندهی فعالیت ها است برای ساخت یک سیستم
- فرآيند مديريت (Management Process): انتخاب افراد، تجهیزات و فرآیند هاست برای توسعه یک سیستم و کنترل و نظارت بر روند اجرای پروژه (مدیریت پروژه)
- فرآيند پشتيباني (Maintenance Process): کنترل و پشتیبانی نرم افزار پس از تولید آن

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

Validation) و وارسی پذیری: صحت عملکرد خروجی (Verification) باشد. فرآیند توسعه ضمن دادن آزادی به تحلیل گر باید تضمین کند که زمانبندی رعایت شود.

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

1- ساده ترین روش: تبدیل فرآیند توسعه سیستم در قالب دنباله ای از وظایف مشخص و ترسیم

CPM: CriticalPath Model ، یک نمودار از تمام فعالیت ها

2- فرایند توسعه خطی

Liner: به ترتیب مراحل انتخاب پروژه، تعریف مفهومی (تعریف مساله، امکان سنجی) ، تعریف مشخصات (خواسته ها ، تعریف مساله) ، طراحی (طراحی معماری، تفصیلی) ، توسعه (ساخت سیستم، تست) ، ارزیابی و درنهایت تعریف پروژه جدید

3- مدل آبشاری (

WaterFall) : تقسیم وظائف توسعه سیستم در قالب یک مدل آبشاری از تعریف مساله، امکان سنجی، تحلیل (سیستم، خواسته ها)، طراحی ، پیاده سازی و تست ، یکپارچه سازی و تست، نصب و تست ، نگهداری و مرور , با امکان برگشت از یک مرحله به مرحله قبل

4- توسعه مرحله ای، افزایشی و یا نموی

Incremental Methods : تقسیم یک مساله به مسائل کوچکتر و انجام هر زیر سیستم (مساله کوچکتر) و انجام هر یک به صورت جداگانه و در صورت امکان اجرا به صورت همزمان

5- الگو سازی (

Prototyping) :ایجاد یک الگو برای کاربران برای اینکه درک بهتری از سیستم داشته باشند و درنهایت پیاده سازی سیستم بر اساس این نمونه

6- توسعه سریع سیستم

RAD: Rapid Application Development : ادغام برخی مراحل با یکدیگر و استفاده از زبانهای نسل چهارم برای توسعه سیستم (مراحل: برنامه ریزی، طراحی و تست)

7- طراحی تکاملی به صورت حلزونی و یا مارپیچی (

Spiral) : توسعه سیستم به صورت افزایشی به صورت بازگشتی Recursive

8- با اضافه کردن مفاهیم برنامه سازی شی گرایی (

OOP) به روش حلزونی و تبدیل به صورت موازی بازگشتی (Parallel Recursive Method )

9- توسعه سیستم مبتنی بر مولفه ها (

CBSD: Component Based Software Development )

10- مهندسی همزمان (

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

11- روشهای فرمال : بکارگیری مدل ها و مفاهیم ریاضی در توسعه سیستم

12- روشهای نسل چهارم: بگارگیری از ابزارهای گرافیکی و ابزارهای مهندسی نرم افزار (

CASETools)

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

- درجه ساختاری سیستم

- آشنایی با فنآوری

- اندازه پروژه

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

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

- طراحان برای یادگیری تکنیک های جدید وقت زیاد تلف نمی کنند.

- مستند سازی بهتر صورت می گیرد

- کاهش هزینه آموزش کاربران سیستم ها

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

از قيمت نرم افزار تا استاندارد سازي عوامل کيفي نرم افزار - بخش 1.

از قيمت نرم افزار تا استاندارد سازي عوامل کيفي نرم افزار - بخش 1.
در اين چند ساله که در بازار نرم افزار کشور مشغول توليد و فروش نرم افزار مي باشم مدام با بحث تعيين قيميت نرم افزار مواجه شده ام. بحثي که بسيار اختلاف بر انگيز است. در پروژه هاي مختلف، پيمانکاران مختلف قيمت هاي متفاوت و حتي با اختلاف بسيار زياد عرضه مي کنند. براي مثال براي يک پروژه قيمت هاي از 700 هزارتومان تا 8 ميليون تومان به کارفرما پيشنهاد شده بود! در پروژه ديگري تفاوت قيمت بين نفر کمترين و بيشترين پيشنهاد بيش از 150 ميليون تومان بود! پروژه ديگري را که خود کارفرما در حدود 50 ميليون پيش بيني مالي کرده بود کسي بود که ادعاي انجام اين کار را با مبلغي کمتر از 5 ميليون تومان داشت! حتي در بازار بسته هاي نرم افزاري هم اين وضعيت وجود دارد. براي مثال الان سيستمهاي حسابداري از 20 هزارتومان قيمت داريم تا 3 ميليون تومان! يا در سيستم هاي تلفن گويا در حاليکه رنج نرمال قيمت بين 1 ميليون الي 3 ميليون تومان بين اکثر توليد کنندگان مطرح است شرکتي هم پيدا مي شود که ادعاي ارائه اين نرم افزار با قيمت زير 70 هزارتومان دارد!
از اين مثال ها که بگذريم اين اختلاف قيمت گرچند در يک حد نرمال طبيعي است و موجب پويايي و تعادل در توليد و نظام عرضه و تقاضاي نرم افزار مي گردد در حالتي که تفاوت بسيار زياد باشد موجب سردرگم شدن خريدارن مي شود. امري که بايد به آنها حق داد که نتوانند انتخاب درستي انجام دهند.

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

اين اختلاف قيمت از کجا ناشي مي شود؟

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

Package)، طبيعتا قيمت توليد مجدد و يا قيمت فروش ارزان تر از حالتي است که سيستم از ابتدا توليد شود.
-تفاوت راه حل ها: برخي موارد راه حل هاي ارائه شده توسط شرکت هاي مختلف براي يک مساله مشخص کاملا متفاوت است و طبيعتا هزينه انجام آنها نيز متفاوت مي باشد.

و تعدادي عوامل نادرست -که عوامل مجازي بوده و شرايط رقابتي را از بين مي برند- عبارتند از:
- ميزان سرمايه مشتري: برخي موارد بسته به سطح پولدار بودن مشتري قيمت تعيين مي شود. بالطبع به مشتريان پولدارتر سيستم گرانتر فروخته مي شود.
- رقابت ناسالم : براي حذف رقبا، ارائه قيمت هاي کم غير معقول ، متاسفانه از ابزارهاي جاري بين شرکتهاي نرم افزاري مي باشد.
- فداکردن کيفيت براي کاهش قيمت: براي گرفتن پروژه، با فدا کردن کيفيت و استفاده از ابزارها و نيروي انساني ارزان قيمت، هزينه ها را کاهش مي دهند.
- عدم دانش پيمانکار: برخي موارد ارائه قيمت هاي کم و يا زياد ناشي از ناآگاهي توليد کنندگان به بحث تخمين هزينه هاي توليد نرم افزار بر مي گردد و ارائه قيمت صرفا بر اساس حدس و گمان استوار است.
- رعايت نکردن اخلاقيات: عقيده متاسفانه مطرحي است که شما پروژه را بگير، بعد به بهانه هاي مختلف کارفرما را مجبور مي کني که پول اضافه تر بدهد!!
- عدم تعيين دقيق مشخصات سيستم توسط سفارش دهنده: چنانچه کارفرما و يا خريدار نرم افزار نتوانند -و يا نخواهند!- مشخصات دقيق نياز خود را مطرح کنند، مجريان مختلف بر اساس حدس و گمان و با توجه به شناخت خود پيشنهاد خود را تنظيم مي کنند (هر کسي از ظن خود شد يار من!!)

نگاهي به معيارها و متريک ها در تخمين زمان و هزينه توليد نرم افزار

در رادمان براي جلب مشتري استراتژي جالبي بکار مي بريم و آن اينست که کار ها را در زمان بسيار کوتاه تري نسبت به آنچيزي که مشتري توقع دارد پروژه را به اتمام مي رسانيم ، بدين تيب که براي يک پروژه مفروض به مشتري زمان معمول توليد سيستم را اعلام مي کنيم. مثلا براي يک پروژه کوچک يک ماه زمان در نظر مي گيريم که زمان منطقي است، اما پروژه را ظرف يک هفته تحويل مي دهيم! و مشتري را شگفت زده مي کنيم! چطور اينکار را انجام مي دهيم جزء اسرار است! هر چند در متن زير اين اسرار برملا مي شود!!

پيشتر در هنگام توسعه سيستمهاي نرم افزاري با استفاده از روشهاي ساختيافته، مديران پروژه ها براي تخمين زمان و هزينه توليد يک سيستم قبل از آغاز آن از روشهاي مختلفي استفاده مي کردند.
از مهمترين　 روشهاي تخمين　 در آن زمان استفاده از تجربيات گذشته در سيستمهاي مشابه و يا تخمين تعداد خطوط برنامه و يا تعداد عملکردهاي متفاوت سيستم مي باشد.
بدين معني که يک برنامه ساز زماني که مي خواهد در آغاز پروژه زمان و هزينه لازم را برآورد کند براي مثال در يک جستجو در تجربيات خود　 يک نمونه نزديک براي سيستم جديد پيدا مي کند. براي مثال در فلان سيستم دو ماه کار توسط يک گروه 2 نفره صورت گرفته است (به عبارتي 4 نفر-ماه) و چون پروژه جديد هم شبيه اين تجربه مي باشد همين حدود زمان براي توسعه سيستم نياز است و يا چون مثلا يک کم از آن بزرگتر است يک مقدار اضافه تر. گاهي هم بر اساس تخمين تعداد خطوط عمل مي شد. براي مثال برنامه ساز محاسبه مي کرد براي ايجاد سيستم نگارش حدودا 10.000 خط برنامه لازم است پس حجم پروژه معلوم است و بر اساس اينکه يک برنامه نويس در روز چند خط برنامه توليد مي کند (انگار کار برنامه نويسي پارچه بافي است که با يک معيار کمي آن را اندازه گيري مي کنيم!) کل زمان بدست بيايد. به همين شکل براي عملکرد ها هم عمل مي شد. و با شمارش تعداد عملکرد (

Function)　 هاي اصلي و فرعي سيستم حدود سيستم تخمين زده مي شد.
با توسعه روشهاي مهندسي نرم افزار و مطرح شدن مفاهيم شيء گرايي (Object OrientedConcept)　 در مهندسي نرم افزار بالطبع معيارها و متريک ها نيز متفاوت شد. در شيء گرايي با تکيه بر استفاده مجدد يا بازکارآيندگي (Reuseability)　　 از يکسو فرآيند توليد نرم افزار سريعتر گرديد و از سوي ديگر معيارهايي نظير تعداد خطوط کارائي نداشت. چون ديگر در اينجا با نمونه سازي از اشياء و يا با استفاده از وراثت و يا چند ريختي نه تنها مي توان از يک کد نوشته شده در قالب يک شيء مي توان بارها استفاده کرد بلکه با گسترش يک کد در کلاسهاي ارث گرفته شده حجم کد نويسي مجدد را کاهش داد.
به همين منظور در روشهاي شيء گرايي با استفاده از شمارش تعداد کلاس هاي کليدي (Key Class) و کليد هاي کمکي يا پشتيبان (Support Class)　 يک تخمين نسبت به حجم کلي سيستم بدست مي آيد.
در روشهاي ديگر با شمارش سناريو هاي کاري و يا شمارش زيرسيستمهاي سيستم هدف و با بهره گيري از تجربيات گذشته به يک روش نيمه فرمال براي تخمين زماني و مالي پروژه استفاده مي نمايند. اين روشها تخمين بهتري براي زمان و هزينه مالي پروژه به دست مي دهند.
نکته حائز اهميت اينکه هر چند اين روشها تخمين خوبي براي روشهاي شيء گرا هستند اما با مطرح شدن روشهاي جديد مهندسي نرم افزار از جمله روش توسعه نرم افزار مبتني بر مؤلفه ها (CBSD: Component BasedSoftware Development) بايستي در اين معيار ها اصلاحاتي به وجود بيايد و تغييرات عمده اي صورت گيرد.
با استفاده از مؤلفه ها (Components) و چارچوب هاي (Frames)　 مناسب براي يک پروژه مي توان زمان توليد نرم افزار را به طور چشمگيري کاهش داد. در نتيجه در تخمين زدن مي توان با توجه به مولفه ها و چارچوب هاي موجود در کتابخانه توليدي عمل کرد. هر چقدر اجزاء سيستم جديد با استفاده از ابزارهاي موجود　 بيشتر قابل توسعه باشند مي توان پروژه را سريعتر توسعه داد

فرآيند توسعه نرم افزار

مطالب مشابه :

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

تست نرم افزار (قسمت 1)

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

تست نرم افزار (قسمت 2)

خرید سی دی آموزش تست زنی مهندسی معکوس

آموزش روشهای یافتن درایورهای سخت افزار

تست سالم بودن سخت افزار به خصوص کارت گرافیک

فرآيند توسعه نرم افزار