نحوه ارزش گذاري بر پروژه هاي فناوري اطلاعات و ارتباطات

محمد حسين دالوند

دانشجوي علوم كامپيوتر

تير 1388

بسم الله الرحمن الرحيم

چکيده مطلب :

فرض کنيد شما مي خواهيد مقداري برنج خريداري کنيد. اولين اقدام شما اين است که از منزل بيرون برويد و خود را به يک فروشگاه مواد غذايي که برنج هم دارد برسانيد. در اينجا شما مي بايستي مقدار برنجي را که نياز داريد به صورت عددي از فروشنده درخواست نماييد.

در چنين حالتي شما دو گزينه داريد. يا بر حسب مقدار پولي که در جيب داريد برنج بخواهيد و يا بر اساس مقدار برنجي که نياز داريد. براي مثال شما ممکن است بگوييد به اندازه ي يک کيلو برنج به من بدهيد و يا ممکن است بگوييد پنج کيلوگرم برنج به من بدهيد.

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

حال فرض کنيد، شما مي خواهيد براي خود کفش بخريد. مجددا" از منزل بيرون مي رويد، و خود را به يک فروشگاه کفش مي رسانيد. در آنجا تقاضاي مقداري ؟ يک جفت کفش مي کنيد. در اينجا نيز شما از يک واحد، هم رديف کيلوگرم براي برنج، براي خريد کفش خود استفاده کرده ايد.

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

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

مقدمه:

سپاس خداوند بلند مرتبه که به ما فرصت زندگي کردن و آموختن داده است.

همانطور که مي دانيم در کشور ايالات متحده آمريکا کامپيوتر ها در دهه ي 1950 به صورت جدي و موثر وارد سيستمهاي اداري شده اند. در آن دوران مفاهيمي چون HRM ( مديريت منابع انساني ) و حتي FM ( مديريت ناوگان ) و از اين قبيل بر عهده ي کامپيوترها بوده اند.

در دهه ي 1960 با روي کار آمدن Access methods ها، به عنوان سيستمهاي واسطه ي دسترسي کاربران به فايلها، که مي توان به انوع سيستم عامل نيز اشاره داشت، صنعت نرم افزار با رشد سريعتري نسبت به دهه ي گذشته ي خود رو به رو شد، تا آنجا که در اين دهه اکثر شرکت ها و سازمانها به سيستم هاي نرم افزاري حسابداري و واژه پرداز مجهز شدند.

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

در اواخر دهه ي 1960، تقريبا" اکثر برنامه نويسان با نقايص سيستمهاي Access methods رو به رو شدند، و تقريبا" به نا کار آمد بودن آنها همگان پي بردند، و اولين تلاشها براي ساخت سيستمهاي پايگاهي و يا DBMS ها آغاز شد.

درست در اوايل دهه ي 1970 بود، که اولين سيستمهاي DBMS با عرصه ي وجود گذاشتند. در دهه ي 1980، انجمنهايي چون ANSI با تصويب و تاييد استانداردهاي زبان SQL به عنوان DML و DDL ( زبان تعريف و زبان استخراج داده ها در نظام مديريت پايگاه اطلاعات )، صنعت نرم افزار با موجي به نام پايگاههاي داده رو به رو شد، و همين موج باعث پيشرفتهاي بعدي شد.

در سالهاي 1990 تا 1995، با ابداع روشهاي UML جهت مدلسازي نرم افزار و پس از آن با روي کار آمدن روشهاي مهندسي نرم افزار به کمک کامپيوتر در سالهاي 1998 موسوم به CASE صنعت نرم افزار دستخوش تغييرات مهيج و بي نظيري شده است، به طوريکه آقاي بيل گيتس مدير ارشد شرکت مايکروسافت در سخنراني تاريخي خود در سال 1998 به مناسبت ورود ويندوز 98 مايکروسافت به بازار، اذعان داشت که اگر صنعت خودرو سازي مانند صنعت کامپيوتر پيش مي رفت، اکنون خودروهايي داشتيم که بجاي حرکت بر روي جاده با چرخ، بر روي هوا حرکت مي کردند.

هدف از بيان سريع و گذراي تاريخ جوان، اما غني علوم کامپيوتر رسيدن به اين نکته بود که بدانيم جايگاه فعلي صنعت کامپيوتر در کشور ما ايران کجا ست ؟

بين سالهاي 1370 تا 1378 ، صنعت نرم افزار در کشور ما با رشد قابل قبولي در حال ترقي و تعالي بود، که نا گاه با ورود اينترنت در سالهاي 1379 و 1380 و اوج گيري آن در سالهاي 1382 و 1383 ، ناگهان بحثي با عنوان فناوري اطلاعات و ارتباطات در کشورمان، عنوان شد.

برخي از قابليتهاي اينترنت مانند جهاني بودن آن، و همچنين ماهيت ارزش افزوده اي آن ( چون بر روي شبکه هاي مخابراتي فعال است )، نظر متخصصان نرم افزار کشور را به خود جلب کرد، که در اين راستا به دليل عدم وجود ساختار و بستر مناسب، آغاز اين راه با آزمون و خطاهاي بسيار همراه بوده است.

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

در اين بين اکثر شرکتها که داراي پيشينه ي نرم افزاري قوي بودند وارد عرصه شدند، و سعي کردند تا حدودي نظرات مشتريان را در کارشان اعمال کنند، اما در نهايت به دليل وجود يک فاصله ي سيستمي، تقريبا" اکثر پروژه هاي فناوري اطلاعات و ارتباطات در کشورمان، متاسفانه با مشکل مواجه شدند.

شايد، ابزار طراحي و ساخت نرم افزارهايمان به روز شده باشد، اما دقيقا" در همان دهه اي به سر مي بريم که معادل آنرا کشورهايي مانند انگلستان و امريکا در سالهاي 1975 و 1985 گذرانده اند.

براي مثال، کشور مالزي. اگر وارد فروشگاههاي با سابقه و معتبر اين کشور شويد، هنوز سيستمهايي را خواهيد ديد که بر روي NetWare و يا Foxpro کار مي کنند، اما سمت ديگر آنها خدمات وب دارد، و سمت ديگر آنها به شبکه هاي Wireless متصل است. ( از اين مفهوم به EDI سنتي نام مي برند که امروزه XML به عنوان جايگزين مناسبي براي آن است ).

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

اما هنوز يک مشکل وجود دارد، و آن تعيين بهاي پروژه هاي فناوري اطلاعات مي باشد. در دانشگاههاي معتبر دنيا روشهايي مانند CoCoMo را آموزش مي دهند، اما در کشور ما به دليل

وجود خلاء هاي قانوني، روش مناسبي آموزش داده نمي شود، و فقط در برخي رشته ها و برخي دانشگاهها اشاراتي مختصر به روشهايي چون CoCoMo شده است.

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

متاسفانه گه گاه مي شنويم که فلان پروژه توسط فلان شرکت با هزينه اي در حدود چند صد ميليون تومان اجرا شده است، و همين پروژه اکنون در جايي ديگر توسط شرکتي ديگر با يکدهم آن بها طراحي و اجرا شده است.

در بسياري از دادگاهها و دعواهاي نرم افزاري، مشتري همواره خواستار استرداد تمام يا قسمتي از وجه پروژه مي باشد!!!

البته مشابه اين اتفاق در دهه ي 1990 براي شرکت PeopleSoft در آمريکا رخ داد. اين مثال به عنوان يکي از تلخ ترين مثالهاي تاريخ پروژه هاي فناوري اطلاعات مي باشد.

در سال 1995، يک شرکت دارو سازي آمريکايي سفارش يک سيستم يکپارچه ثبت سفارش را به شرکت پيپل سافت داد. رقم اوليه اين پروژه ( فقط نرم افزار ) برابر با 5 ميليون دلار بوده است و پروژه قرار بود در سال 1998 به صورت آزمايشي راه اندازي شود.

پيپل سافت با بالغ بر دويست برنامه نويس به صورت متمرکز بر روي اين پروژه فعاليت کرد. پروژه در سال 2000 به فاز آزمايشي رسيد، و درست يک هفته پس از اجراي آزمايشي آن، سيستم به صورت کامل از کار افتاد. پس از آن سيستم بار ديگر در سال 2003 آماده و اجرا شد، اما در آن زمان مبلغي در حدود پانزده ميليون دلار توسط شرکت دارو سازي براي اين پروژه خرج شده بود.

در مارچ 2003 که سيستم راه اندازي شد، پس از گذشت يک ماه از راه اندازي سيستم متوجه شدند که سيستم فقط قادر به انجام 30% تراکنشهاي روزانه شرکت مي باشد. در مي 2004 هيئت مديره ي شرکت دارو سازي تغيير يافتند، و به دادگاه بر عليه شرکت پيپل سافت شکايت کردند.

مدير عامل جديد شرکت دارو سازي اذعان داشت " براي ما جاي سوال بود که چرا پروژه اي را که مي شد با صرف مبلغي در حدود يک ميليون دلار با نرم افزار هاي آماده ي آن زمان در بازار

راه اندازي نمود، اکنون پس از گذشت نزديک به ده سال، با صرف پانزده ميليون دلار هنوز راه اندازي نشده است ؟ "

البته پس از اين ماجرا پيپل سافت توسط شرکت اوراکل خريداري شد، و از ورشکستگي ناشي از بدنام شدن نجات پيدا کرده بود.

مشابه همين اتفاق نيز براي بسياري از شرکتها در داخل ايران رخ داده است.

پس از قضيه و در حين ماجراي پيپل سافت، نزديک به 90% شرکت هاي آمريکايي و نزديک به 70% شرکتهاي انگليسي از روش CoCoMo و مشابه آن براي ارزش گذاري معقول پروژه هاي خود استفاده کردند.

راه حل بسيار ساده بود، با انتخاب يک ترازوي عادلانه، هم شما رضايت مشتري را داريد و هم ريسک مالي پروژه ي خود را به حد اقل رسانيده ايد.

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

از اينرو، اينجانب در ادامه به بررسي انواع روشهاي معمول و مناسب بر گرفته از روش CoCoMo مي پردازم، تا با معرفي يک استاندارد در اين زمينه، راه را براي ديگران جهت فعاليت در اين زمينه هموار سازم و انشاالله به پيشرفت مملکت اسلاميمان کمک کند.

محمد حسين دالوند

تير 1388

دانشجوي كارشناسي ارشد مهندسي نرم افزار

فهرست مطالب :

عنوان	صفحه
مدت پروژه	9
روشهاي برنامه نويسي	10
مدل نرم افزار	11
سيستم عامل	12
تعداد افراد برنامه نويس حاضر در پروژه	13
مجموع سابقه افراد برنامه نويس به ماه	14
ميزان پشتيباني در تعهد به ماه	14
ميزان مشارکت کارفرما در پروژه	15
آناليز پروژه	16
ماهيت اجرايي پروژه	17
تحويل سورس کد	18
تعداد اتصال به دستگاههاي سخت افزار جانبي در پروژه	19
تعداد خروجيهاي پروژه ي شما	19
تعداد وروديهاي پروژه ي شما	19
نمونه ي فرم محاسبه	20
منابع	24

مدت پروژه

متاسفانه در اغلب شرکتهاي نرم افزاري مدت پروژه و تعداد ساعات کار برنامه نويس بر روي پروژه را ملاک سنجش بهاي پروژه قرار مي دهند که شايد به صورت عيني کاري درست باشد، اما از نظر ضمني ملاک درست و دقيقي نمي باشد.

فرض کنيد، برنامه نويسي در فلان پروژه يک Component قبلا" توليد کرده باشد و در آن پروژه زماني در حدود يک ماه براي ايجاد آن صرف کرده باشد، حال در پروژه ي ديگري مي خواهد از همان Component استفاده نمايد. در اينصورت تکليف چه است ؟ اخذ هزينه ي مجدد ؟ يا اخذ کسري از هزينه و به طور کلي چه ملاکي وجود دارد.

از طرف ديگر در اکثر پروژه ها عبارت ساعت کارکرد را براي برنامه نويس تجويز مي کنند، که بازهم ملاک درستي نيست چون ساعت کارکرد برنامه نويس به عوامل بسيار متعددي بستگي دارد!

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

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

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

از اينرو اولين قدم براي محاسبه ي بهاي پروژه ي فناوري اطلاعات و ارتباطات تصميم گيري براي زمان آن است و مطرح کردن آن به ماه.

روشهاي برنامه نويسي :

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

برخي از رويکردهاي مهم شامل :

1. غير ساخت يافته

2. ساخت يافته

3. ويژوال

4. شي گرا

فرآيندهاي غير ساخت يافته به عنوان ارزان ترين فرآيند طراحي نرم افزار و مشکل دار ترين فرآيند طراحي نرم افزار مي باشد، و فر آيند هاي ويژوال و شي گرا، جزو فرآيندهاي معمول، گران، و با کارآيي بسيار بالا مي باشند.

معمولا" وقتي فرآيند غير ساخت يافته توسط تيم يا شخص انتخاب مي شود که اولا" تجربه ي کمي درباره ي پروژه و هدف آن وجود داشته باشد، و قرار باشد به صورت آزمون و خطا به نتايج پروژه دست يابند.

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

اين روش، در نهايت باعث به وجود آمدن مشکلاتي در گسترش سيستم و به روز رساني سيستم و در برخي اوقات باگ يابي و يا اشکال يابي سيستم مي شود. اما به دليل سرعت آماده سازي آن، جزو فرآيندهاي ارزان قيمت مي باشد.

در مقابل آن روشهاي ساخت يافته و در نهايت شي گرا، به عنوان روشهاي مطمئن و دقيقتر مي باشند.

در ارزش گذاري بايد يکي از موارد نام برده شده را انتخاب نماييد.

مدل نرم افزار:

منظور از مدل نرم افزار نحوه ي تعامل نرم افزار مي باشد. به طور مشخص بيان کننده ي اين موضوع است که غايت کار نرم افزار در چه نوع سيستمي مي باشد. براي روشن تر شدن اين موضوع به ذکر مثالي مي پردازيم.

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

در مثالي ديگر، يک فروشگاه مواد غذايي محلي که فقط يک صندوق فروش دارد، نياز به يک نرم افزار دارد. در اين فروشگاه ديگر خبري از شبکه و ملزومات آن نمي باشد.

از اينرو در فرآيند طراحي يک مدل استاندارد براي پروژه ي فناوري اطلاعات، مدلهاي ذيل مطلوب هستند:

1. اجرا بر روي يک سيستم بسته، مانند مثال فروشگاه مواد غذايي محلي

2. اجرا بر روي چند سيستم نا همزمان ( مانند سيستمهاي بارکد خوان انبارها که پس از جمع آوري هر شب اطلاعات آنها تخليه مي شود و به سرور منتقل مي گردد )

3. مدل توزيعي شبکه اي، ( مانند سيستمهاي صندوق فروش که داده هاي فروش را بر روي سيستم خود پردازش مي کنند، و پس از پايان پردازش، اطلاعات را به سرور اصلي منتقل مي کنند ).

4. مدل مشتري/خدمتگذار ( Client/Server ) که کل عمليات دريافت داده و پردازش و تبديل آن به اطلاعات در محل سرور انجام مي پذيرد ( در برداشتي آزاد، مانند سيستم هاي مبتني بر فناوري HTTP بر روي وب ).

از اينرو، گام بعدي براي مشخص کردن ارزش پروژه ي شما انتخاب مدلي است که پروژه ي شما مي بايستي بر روي آن طراحي و ساخته شود، که مي تواند يکي از 4 مورد بالا باشد.

سيستم عامل:

سيستم عامل به عنوان يک رابط بين شما و سخت افزار کامپيوتر و يا حتي هر نوع سخت افزار جانبي مي باشد. با ارتقاي روز افزون سيستمهاي عامل، نوع پشتيباني و ارتباط آنها و امنيت آنها رو به افزايش است ( منظور سيستم عاملهاي مجاز و Register شده عاري از هرگونه خرابي مي باشد که تحت حمايت و پوشش پشتيباني شرکتهاي سازنده مي باشند ).

اگر قرار باشد، شما پروژه ي خود را بر روي سيستم عامل MS-Windows 2000 ارايه نماييد، مطمئنا" هزينه ي اجراي پروژه ي شما بسيار متفاوت خواهد بود با زمانيکه مي خواهيد همين پروژه را بر روي سيستم عامل Ms-Dos 6.22 ارايه نماييد.

همچنين، عموميت و مقبوليت استفاده از سيستم عامل نقش مهمي در انتخاب سيستم عامل اجراي پروژه ي شما خواهد داشت.

برخي اوقات شما نياز داريد که سيستم خود را غير وابسته به سيستم عامل طراحي کنيد ( براي مثال، طراحي يک سيستم عامل براي تلفن همراه )، در اينصورت هم مطالعه ي بيشتر و هم زحمت طراحي ارتباطات سخت افزاري بر عهده ي شما خواهد بود، و مطمئنا" پروژه داراي هزينه ي بالاتري خواهد شد.

از اينرو انواع وابستگي ارزش پروژه هاي فناوري اطلاعات به سيستم عامل به صورت ذيل است:

1. Ms-Dos

2. Win 3.1

3. Win 9.x

4. Unix

5. Linux

6. Win Nt,2000,Xp,Vista

7. Java

8. Symbian

9. غير وابسته به سيستم عامل

بنا بر اين مرحله ي بعدي براي ارزش گذاري بر روي پروژه ي فناوري اطلاعات و ارتباطات شما انتخاب سيستم عامل آن مي باشد.

تعداد افراد برنامه نويس حاضر در پروژه :

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

هر چقدر پروژه بزرگتر شود، کنترل و هدايت و مشکل يابي آن نيز سخت تر خواهد شد، از اينرو حضور يک گروه برنامه نويس ( حد اقل 2 نفر ) مي تواند به شما در ثبات و اجراي پروژه کمک هاي شاياني نمايد.

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

شرکتهايي که بتوانند کار گروهي ارايه کنند، مطمئنا" از بالاترين استانداردها و پروتکلها در ارايه ي سيستمشان استفاده نمودند و همانطور که مي دانيم در دنياي تجارت امروز گروهها و شرکتهايي موفق هستند که بتوانند کار گروهي انجام دهند.

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

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

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

مجموع سابقه ي افراد برنامه نويس حاضر در پروژه:

همانطور که در ابتدا در بحث مربوط به مدت زمان پروژه مطرح شد، سابقه ي افراد در امر برنامه نويسي يا انجام پروژه ي مشابه مي تواند در ارزش گذاري پروژه نقش داشته باشد. براي مثال وقتي شما مي خواهيد طراحي وب نماييد، هرچه تجربه ي شما بالاتر باشد، مطمئنا" پروژه با کيفيت بهتري رو به رو خواهد شد.

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

منظور اصلي اين است که تا بحال درگير چند پروژه بوده است، و مدت هر پروژه به صورت مکتوب و مستند، طي قرار دادها چه مدت بوده است. براي مثال، فلان برنامه نويس که ادعاي 8 سال سابقه ي برنامه نويسي دارد، شايد در مجموع در اين 8 سال درگير 4 پروژه بوده است و هر پروژه در نهايت به طور ميانگين 3 ماه به طول انجاميده است و ما بين اين پروژه ها، برنامه نويس به مطالعه و يا بازاريابي اشتغال داشته است.

در نتيجه، مجموع سابقه چنين برنامه نويسي در نهايت 12 ماه و به طور کلي يک سال است. از اينرو در محاسبه ي ارزش پروژه هاي فناروي اطلاعات و ارتطابات بايد مجموع سابقه ي افراد به صورت ماه بيان شود.

براي مثال، اگر در پروژه ي شما دو برنامه نويس حضور دارند که هر کدام به ترتيب 3 و 5 ماه سابقه ي فعاليت دارند، مجموع سابقه اي که بايد براي آنها در نظر گرفته شود 8 ماه است.

ميزان پشتيباني در تعهد به ماه:

اين عدد به عنوان يکي از مهمترين اعداد طلايي در محاسبه ي ارزش پروژه هاي فناوري اطلاعات و ارتباطات مي باشد. نکته ي مهم در محاسبه ميزان تعهد پشتيباني بيان آن به صورت ماه است. براي مثال اگر قرار است يکسال پشتيباني ارايه نماييد آنرا به صورت عدد 12 ماه در نظر بگيريد.

ميزان مشارکت کارفرما در پروژه:

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

بايد به اين نکته اشاره داشته باشيد که اين کارفرما است که پروژه را سفارش داده است، و شما بايد نظرات او را تا حد امکان اجرا نماييد، اما به اين نکته نيز اشاره داشته باشيد، که تا حد امکان. اين تا حد امکان همان ضعفهاي فناوري را مشخص مي نمايد که شما بايد سعي کنيد آنرا به کارفرما تفهيم نماييد.

از طرف ديگر هر چقدر که کارفرماي شما داراي دانش کامپيوتري بيشتري باشد، شما در انجام پروژه ي خود به مشکلات کمتري بر خواهيد خورد. اما اگر، اطلاعات کامپيوتري فقط داشته باشد، مطمئنا" در اجراي پروژه با مشکلات اندکي برخورد خواهيد کرد.

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

از اينرو ميزان مشارکت کارفرما در پروژه يکي از موارد ذيل خواهد بود :

1. کارفرما فقط سفارش داده است بدون مشخص نمودن محدوده

2. کارفرما فقط سفارش داده و محدوده پروژه را مشخض نموده است

3. کارفرما پروژه را مشخص و روال کار را نيز مشخص نموده است

4. کارفرما پروژه را مشخص، روال را مشخص، و سطح انتظارات خود را نيز مشخص نموده است.

5. کارفرما پروژه را مشخص، روال را مشخص، سطح انتظار را مشخص، و مرحله به مرحله در تکميل بخشهاي مختلف پروژه نظرات اصلاحي خود را بيان مي کند.

بد ترين حالت مشارکت کارفرما، حالت اول مي باشد، و بهترين حالت، حالت پنجم مي باشد.

برخي اوقات کارفرمايان فقط مي دانند که فلان پروژه را مي خواهند، و برخي اوقات روال کار را نيز مشخص مي کنند ( طي جلسات، دفترچه ها و ... ) و در برخي مواقع نيز سطح انتظار خود را از خروجي پروژه مشخص مي کنند، و در بهترين حالت علاوه بر موارد ذکر شده، مرحله به مرحله ي پروژه را بررسي و نظرات خود را مطرح مي کنند.

آناليز پروژه :

به طور کلي دو رويکرد وجود دارد. يا آناليز پروژه بر عهده ي شما است و يا نمي باشد. معمولا" در اکثر پروژه هاي فناوري اطلاعات و ارتباطات آناليز پروژه بر عهده ي مجري است، و کمتر اتفاق مي افتد که يک پروژه ي آناليز شده در اختيار شرکت مجري توسط کارفرما قرار گيرد.

منظور از آناليز پروژه مشخص نمودن روالهاي اجرايي در قالب الگوريتم، UML بالاخص Sequence Diagrams و Activity Diagrams مي باشد. البته دو مورد ذکر شده به عنوان مثالهاي استاندارد مي باشد، اين آناليز مي تواند به هر شيوه ي ديگري نيز باشد.

در صورتيکه آناليز پروژه بر عهده ي مجري باشد، هزينه ي ديگري نيز بر پروژه تحميل خواهد شد.

در شرايط ايده آل، بهتر است آناليز پروژه اي که قرار است توسط مجري انجام پذيرد در يک شيوه ي استاندارد توسط گروهي ديگر از اعضاي شرکت مجري صورت پذيرد، و در نهايت اين آناليز بايد مورد تاييد کارفرما قرار گيرد.

تاييد کارفرما بايد به صورتي باشد که در قرارداد في ما بين مشخص شده است.

ماهيت پروژه:

شايد ماهيت پروژه بخشي از آناليز پروژه باشد. اما با مشخص شدن ماهيت پروژه کار آناليز پروژه ساده تر خواهد شد. به طور کلي منظور از ماهيت پروژه، اين است که ايده ي پروژه بر اساس چه الگويي بايد اجرا شود. در اين زمينه سه الگوي کلي در نظر گرفته شده است :

1. طراحي و توسعه ي يک سيستم جديد

2. توسعه ي يک سيستم قديمي

3. طراحي و توسعه ي يک سيستم جديد بر اساس يک سيستم قديمي

به طور کلي، اکثر برنامه نويسان ترجيح مي دهند که موارد 1 و 3 براي آنها اتفاق بيافتد. مورد 2 ، معمولا" به عنوان يک کابوس براي برنامه نويسان و شرکتهاي نرم افزاري مي باشد. در صورت نياز به انتخاب حالت دوم، بهترين حالت آن است که برنامه نويس به اسناد و مستندات و Document هاي برنامه نويسان قبلي دسترسي داشته باشد.

اما معمولا" در اکثر موارد اين چنين نمي باشد.

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

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

وقتي نرم افزار خود را قرار باشد بر اساس ايده ي يک نرم افزار قديمي طراحي و پياده سازي نماييد، مي توانيد مطمئن باشيد که در حال پياده سازي نرم افزار جديدي بر اساس دانش عيني هستيد و نه دانشي ضمني چون برنامه نويس قبلي، تا جايي که امکان داشته است دانش ضمني مديران را در نرم افزار پياده سازي نموده است و آن نرم افزار براي مديران قابل قبول شده است، و حال از شما خواسته اند که نرم افزاري جديد پياده سازي نماييد.

تحويل سورس کد:

يکي از جنجالي ترين بحثهاي پروژه هاي فناوري اطلاعات و ارتباطات تحويل سورس کد مي باشد. اکثر سازمانها سه رويکرد اساسي براي تحويل گرفتن سورس کد دارند:

1. سورس کد به عنوان دارايي سازمان

2. سورس کد به عنوان سوپاپ اطمينان سازمان براي روز مبادا

3. سورس کد به عنوان انحصاري نمودن پروژه

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

Input A

Rem دريافت متغير

A=A + 1

Rem اضافه نمودن يک واحد به متغير دريافت شده

If A > 3 then print "OK"

Rem چاپ پيغام قبول در صورتيکه مقدار متغير بيشتر از 3 باشد

توضيح خط به خط و يا صفحه به صفحه بايد در سورس کد وجود داشته باشد، همچنين يک نسخه از کامپايلر در کنار آن، و تست و بررسي سورس کد توسط يک ناظر بايد انجام پذيرد.

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

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

اما اگر سورس کد را بدون توضيحات ارايه نماييد، هر چند کامل، اما دانش ضمني خود را منتقل نکرده ايد و صرفا" يک دانش عيني را منتقل کرده ايد که ارزش آن برابري مي کند با اعطاي حق امتياز آن نسخه از نرم افزار ساخته شده.

تعداد اتصال به سخت افزار جانبي :

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

مطمئنا" تعداد آنها در ارزش گذاري بر روي پروژه ي شما نقش اساسي دارد.

براي مثال اگر پروژه ي شما قرار باشد، خروجي خاصي را بر روي يک دستگاه Printer و يا چاپگر مشخص و ارايه نمايد، اين خروجي نياز به طراحي و پياده سازي دارد و مطمئنا" هزينه بر خواهد بود هر چقدر هم که معمول و ساده باشد.

در راستاي آن، اگر قرار باشد، شما پروژه اي انجام دهيد که خروجي آن SMS يا پيامک باشد، ابتدا نياز داريد که نرم افزار شما با يک سخت افزار جانبي به نام GSM MODEM ارتباط بر قرار نمايد، و همچنين نياز داريد که بتوانيد استانداردهاي GSM MODEM مربوطه را رعايت نماييد. از اينرو اين بخش نيز هزينه بر خواهد بود.

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

تعداد خروجي نرم افزار:

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

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

مطابق با آنچه براي خروجيهاي نرم افزار ذکر شد، تعداد وروديهاي نرم افزار را نيز بايد مشخص نماييد.

نمونه ي فرم محاسبه:

فورمول محاسبه ي ارزش پروژه ي شما بر اساس موارد بالا به صورت ذيل است :

الف = زمان پروژه به ماه + تعداد افراد حاضر در پروژه + مجموع سابقه افراد به ماه + ميزان پشتيباني به ماه

ب= ( روش برنامه نويسي + مدل پروژه + سيستم عامل ) * ( تعداد ورودي + تعداد خروجي )

ج = الف * ب

ج = (( ماهيت پروژه * ج ) تقسيم بر 100 ) + ج

ج = (( آناليز پروژه * ج ) تقسيم بر 100 ) + ج

ج = (( سورس کد پروژه * ج ) تقسيم بر 100 ) + ج

ج = (( ميزان مشارکت کارفرما * ج ) تقسيم بر 100 ) + ج

ج = ((( تعداد سخت افزار جانبي * 20 ) * ج ) تقسيم بر 100 ) + ج

بها نشان = ( ج تقسيم بر 1000 ) .

رديفهاي قبل از بها نشان درصد تاثير هر قسمت را بر بهاي پروژه مشخص نموده و آنرا به پروژه اضافه مي کند.

محاسبات مهم :

در محاسبه ي روش برنامه نويسي استفاده شده :

رديف	مقدار	عدد
1	غير ساخت يافته	10
2	ساخت يافته	20
3	ويژوال	22
4	شي گرا	30

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

در محاسبه ي مدل نرم افزار :

رديف	شرح	عدد
1	اجرا بر روي يک سيستم بسته	1
2	اجرا بر روي چند سيستم نا همزمان	1
3	مدل توزيع شبکه اي	2
4	مشتري / خدمتگذار	3

در محاسبه ي سيستم عامل :

رديف	شرح	عدد
1	غير وابسته به سيستم عامل	51
2	MS-Dos	11
3	Ms-Win 3.x	11
4	Ms-Win 9.x	21
5	Unix	21
6	Linux	31
7	Ms-Nt,2000,Xp,Vista	31
8	جاوا	41
9	سيمبيان	40

در محاسبه ي ميزان مشارکت کارفرما:

رديف	شرح	عدد
1	کارفرما فقط سفارش داده بدون مشخص نمودن محدوده	100
2	کارفرما فقط سفارش داده است و حدود را مشخص کرده	80
3	کارفرما حدود و روال را مشخص نموده است	70
4	کارفرما پروژه و روال و سطح انتظار خود را مشخص کرده است	50
5	کارفرما پروژه و روال و سطح انتظار را مشخص و در پروژه مشارکت دارد	30

در محاسبه ي آناليز پروژه :

رديف	شرح	عدد
1	آناليز بر عهده ي شما است	20
2	آناليز بر عده ي شما نمي باشد	2

در محاسبه ي ماهيت پروژه :

رديف	شرح	عدد
1	طراحي و توسعه يک سيستم جديد	50
2	توسعه ي يک سيستم قديمي	100
3	توسعه يک سيستم جديد بر اساس سيستم قديمي	30

در تحويل سورس کد برنامه :

رديف	شرح	عدد
1	بله ( بنا به شرايط ذکر شده در اين مقاله )	30
2	خير	2

· نکته: اعداد بالا بر اساس ميزان درصد تاثير گذاري بر روي پروژه با بررسي بيش از دويست پروژه ي بين المللي و هفتاد پروژه ي نرم افزاري داخلي بدست آمده اند. اين اعداد بنا به سلايق مختلف و در زمانهاي مختلف قابل تغيير هستند، اما اعداد متعبر اينها هستند.

محاسبه ي بهاي نهايي :

پس از آنکه از طريق جداول و فورمولهاي ذکر شده، عدد بها نشان بدست آمد، آن عدد را بايد در عددي ديگر که عدد نرخ روزانه مي باشد ضرب نماييد. عدد نرخ روزانه را اينگونه بدست مي آورند که يک هدف براي درآمد ماهيانه افراد حاضر در پروژه محاسبه مي کنند. براي مثال، اگر يک شخص قرار است پروژه را انجام دهد، و فقط همين پروژه را داشته باشد و طول مدت پروژه يک ماه باشد، سطح حقوق خود را ماهيانه 500 هزار تومان در نظر مي گيرد و عدد را بر 30 روز ماه تقسيم مي کند، که تقريبا" روزي 17 هزار تومان مي شود. حال اگر بها نشان پروژه عدد 70 باشد، مبلغ انجام اين پروژه ولو اينکه يکماه است برابر خواهد بود با يک ميليون و يکصدو نود هزار تومان.

براي شرکتهاي نرم افزاري، بدست آوردن عدد نرخ روزانه برابر است با مجموع هزينه هاي دفتري و حقوقي و ماهيانه ي تعداد افراد حاضر در پروژه. براي مثال، براي پروژه اي شرکتي که دو نفر در آن حضور دارند، و حقوق هر يک 500.000 تومان در نظر گرفته مي شود، و با تمامي هزينه ها اين دو نفر در ماه هزينه اي در حدود 1.500.000 تومان بر شرکت تحميل مي کنند، نرخ روزانه برابر خواهد بود با 50.000 که از تقسيم عدد 1.500.000 بر 30 بدست آمده است، و همان پروژه اي که بهاي نشان آن عدد 70 بود، هزينه اش برابر خواهد بود با : 50.000 * 70 = 3.500.000 ( سه ميليون و پانصد هزار تومان ).

در پايان، اميد وار هستم که اين روش و روشهاي مشابه بتواند در هرچه علمي تر شدن پروژه هاي فناوري اطلاعات و ارتباطات و انجام هزينه هاي معقول در اين زمينه ياري رساند. در صورتيکه خواننده ي محترم تمايل به محاسبه ي بها نشان پروژه ي خود به صورت برخط ( آنلاين ) داشتند، مي توانند از طريق فرم " محاسبه بهاي پروژه فناوري اطلاعات " در وب سايت Www.MHDsoft.Com استفاده نمايند.

در پناه حق

محمد حسين دالوند

منابع :

1. فناوري اطلاعات در مديريت، افرايم توربان

2. Unified Modeling Language ، Addison Wesly

3. Discovering models for selling software ، Scott Andrews

4. مديريت پروژه هاي فناوري اطلاعات، انتشارات علوم رايانه

5. Structured programming methods ، London metropolitan university

6. سيستمهاي هوشمند مدلسازي، شبکه هاي عصبي، دانشگاه پيام نور

7. حسابداري هزينه