Y@SiN
11-19-2009, 07:20 PM
در رادمان براي جلب مشتري استراتژي جالبي بکار مي بريم و آن اينست که کار ها را در زمان بسيار کوتاه تري نسبت به آنچيزي که مشتري توقع دارد پروژه را به اتمام مي رسانيم ، بدين تيب که براي يک پروژه م�?روض به مشتري زمان معمول توليد سيستم را اعلام مي کنيم. مثلا براي يک پروژه کوچک يک ماه زمان در نظر مي گيريم که زمان منطقي است، اما پروژه را ظر�? يک ه�?ته تحويل مي دهيم! و مشتري را شگ�?ت زده مي کنيم! چطور اينکار را انجام مي دهيم جزء اسرار است! هر چند در متن زير اين اسرار برملا مي شود!!
پيشتر در هنگام توسعه سيستمهاي نرم ا�?زاري با است�?اده از روشهاي ساختيا�?ته، مديران پروژه ها براي تخمين زمان و هزينه توليد يک سيستم قبل از آغاز آن از روشهاي مختل�?ي است�?اده مي کردند.
از مهمترين روشهاي تخمين در آن زمان است�?اده از تجربيات گذشته در سيستمهاي مشابه و يا تخمين تعداد خطوط برنامه و يا تعداد عملکردهاي مت�?اوت سيستم مي باشد.
بدين معني که يک برنامه ساز زماني که مي خواهد در آغاز پروژه زمان و هزينه لازم را برآورد کند براي مثال در يک جستجو در تجربيات خود يک نمونه نزديک براي سيستم جديد پيدا مي کند. براي مثال در �?لان سيستم دو ماه کار توسط يک گروه 2 ن�?ره صورت گر�?ته است (به عبارتي 4 ن�?ر-ماه) و چون پروژه جديد هم شبيه اين تجربه مي باشد همين حدود زمان براي توسعه سيستم نياز است و يا چون مثلا يک کم از آن بزرگتر است يک مقدار اضا�?ه تر. گاهي هم بر اساس تخمين تعداد خطوط عمل مي شد. براي مثال برنامه ساز محاسبه مي کرد براي ايجاد سيستم نگارش حدودا 10.000 خط برنامه لازم است پس حجم پروژه معلوم است و بر اساس اينکه يک برنامه نويس در روز چند خط برنامه توليد مي کند (انگار کار برنامه نويسي پارچه با�?ي است که با يک معيار کمي آن را اندازه گيري مي کنيم!) کل زمان بدست بيايد. به همين شکل براي عملکرد ها هم عمل مي شد. و با شمارش تعداد عملکرد (Function) هاي اصلي و �?رعي سيستم حدود سيستم تخمين زده مي شد.
با توسعه روشهاي مهندسي نرم ا�?زار و مطرح شدن م�?اهيم شيء گرايي (Object Oriented Concept) در مهندسي نرم ا�?زار بالطبع معيارها و متريک ها نيز مت�?اوت شد. در شيء گرايي با تکيه بر است�?اده مجدد يا بازکارآيندگي (Reuseability) از يکسو �?رآيند توليد نرم ا�?زار سريعتر گرديد و از سوي ديگر معيارهايي نظير تعداد خطوط کارائي نداشت. چون ديگر در اينجا با نمونه سازي از اشياء و يا با است�?اده از وراثت و يا چند ريختي نه تنها مي توان از يک کد نوشته شده در قالب يک شيء مي توان بارها است�?اده کرد بلکه با گسترش يک کد در کلاسهاي ارث گر�?ته شده حجم کد نويسي مجدد را کاهش داد.
به همين منظور در روشهاي شيء گرايي با است�?اده از شمارش تعداد کلاس هاي کليدي (Key Class) و کليد هاي کمکي يا پشتيبان (Support Class) يک تخمين نسبت به حجم کلي سيستم بدست مي آيد.
در روشهاي ديگر با شمارش سناريو هاي کاري و يا شمارش زيرسيستمهاي سيستم هد�? و با بهره گيري از تجربيات گذشته به يک روش نيمه �?رمال براي تخمين زماني و مالي پروژه است�?اده مي نمايند. اين روشها تخمين بهتري براي زمان و هزينه مالي پروژه به دست مي دهند.
نکته حائز اهميت اينکه هر چند اين روشها تخمين خوبي براي روشهاي شيء گرا هستند اما با مطرح شدن روشهاي جديد مهندسي نرم ا�?زار از جمله روش توسعه نرم ا�?زار مبتني بر مؤل�?ه ها (CBSD: Component Based Software Development) بايستي در اين معيار ها اصلاحاتي به وجود بيايد و تغييرات عمده اي صورت گيرد.
با است�?اده از مؤل�?ه ها (Components) و چارچوب هاي (Frames) مناسب براي يک پروژه مي توان زمان توليد نرم ا�?زار را به طور چشمگيري کاهش داد. در نتيجه در تخمين زدن مي توان با توجه به مول�?ه ها و چارچوب هاي موجود در کتابخانه توليدي عمل کرد. هر چقدر اجزاء سيستم جديد با است�?اده از ابزارهاي موجود بيشتر قابل توسعه باشند مي توان پروژه را سريعتر توسعه داد.
اسرار هويدا شد! مکانيزم کار اين است که ما در رادمان با توجه به زمان و نياز بازار در زمانهاي بين پروژه ها مول�?ه ها و چارچوب هاي عمومي توليد مي کنيم و يا در زمان هر پروژه ابزارها را به قدري عمومي مي سازيم که بتوانيم از آنها در پروژه هاي بعدي است�?اده کنيم. حال در يک پروژه جديد زمانبندي اعلامي به مشتري زمان را با است�?اده از روشهاي معمول تخمين زده و اعلام مي کنيم. مشتري نيز معمولا با همين روش محاسبه زمان و هزينه را انجام داده و در مطابقت هزينه ها، زمان و هزينه اعلام شده ما منطقي جلوه مي کند. اما ما با توجه به توانايي هاي �?ني و ابزارهاي موجود، نرم ا�?زار را سريعتر توسعه مي دهيم که باعث کاهش �?وق العاده زمان براي ما مي گردد که از جانب مشتري هم مقبول واقع مي شود چون زودتر از آنچه تصور مي کرده به نياز خود رسيده است.
پيشتر در هنگام توسعه سيستمهاي نرم ا�?زاري با است�?اده از روشهاي ساختيا�?ته، مديران پروژه ها براي تخمين زمان و هزينه توليد يک سيستم قبل از آغاز آن از روشهاي مختل�?ي است�?اده مي کردند.
از مهمترين روشهاي تخمين در آن زمان است�?اده از تجربيات گذشته در سيستمهاي مشابه و يا تخمين تعداد خطوط برنامه و يا تعداد عملکردهاي مت�?اوت سيستم مي باشد.
بدين معني که يک برنامه ساز زماني که مي خواهد در آغاز پروژه زمان و هزينه لازم را برآورد کند براي مثال در يک جستجو در تجربيات خود يک نمونه نزديک براي سيستم جديد پيدا مي کند. براي مثال در �?لان سيستم دو ماه کار توسط يک گروه 2 ن�?ره صورت گر�?ته است (به عبارتي 4 ن�?ر-ماه) و چون پروژه جديد هم شبيه اين تجربه مي باشد همين حدود زمان براي توسعه سيستم نياز است و يا چون مثلا يک کم از آن بزرگتر است يک مقدار اضا�?ه تر. گاهي هم بر اساس تخمين تعداد خطوط عمل مي شد. براي مثال برنامه ساز محاسبه مي کرد براي ايجاد سيستم نگارش حدودا 10.000 خط برنامه لازم است پس حجم پروژه معلوم است و بر اساس اينکه يک برنامه نويس در روز چند خط برنامه توليد مي کند (انگار کار برنامه نويسي پارچه با�?ي است که با يک معيار کمي آن را اندازه گيري مي کنيم!) کل زمان بدست بيايد. به همين شکل براي عملکرد ها هم عمل مي شد. و با شمارش تعداد عملکرد (Function) هاي اصلي و �?رعي سيستم حدود سيستم تخمين زده مي شد.
با توسعه روشهاي مهندسي نرم ا�?زار و مطرح شدن م�?اهيم شيء گرايي (Object Oriented Concept) در مهندسي نرم ا�?زار بالطبع معيارها و متريک ها نيز مت�?اوت شد. در شيء گرايي با تکيه بر است�?اده مجدد يا بازکارآيندگي (Reuseability) از يکسو �?رآيند توليد نرم ا�?زار سريعتر گرديد و از سوي ديگر معيارهايي نظير تعداد خطوط کارائي نداشت. چون ديگر در اينجا با نمونه سازي از اشياء و يا با است�?اده از وراثت و يا چند ريختي نه تنها مي توان از يک کد نوشته شده در قالب يک شيء مي توان بارها است�?اده کرد بلکه با گسترش يک کد در کلاسهاي ارث گر�?ته شده حجم کد نويسي مجدد را کاهش داد.
به همين منظور در روشهاي شيء گرايي با است�?اده از شمارش تعداد کلاس هاي کليدي (Key Class) و کليد هاي کمکي يا پشتيبان (Support Class) يک تخمين نسبت به حجم کلي سيستم بدست مي آيد.
در روشهاي ديگر با شمارش سناريو هاي کاري و يا شمارش زيرسيستمهاي سيستم هد�? و با بهره گيري از تجربيات گذشته به يک روش نيمه �?رمال براي تخمين زماني و مالي پروژه است�?اده مي نمايند. اين روشها تخمين بهتري براي زمان و هزينه مالي پروژه به دست مي دهند.
نکته حائز اهميت اينکه هر چند اين روشها تخمين خوبي براي روشهاي شيء گرا هستند اما با مطرح شدن روشهاي جديد مهندسي نرم ا�?زار از جمله روش توسعه نرم ا�?زار مبتني بر مؤل�?ه ها (CBSD: Component Based Software Development) بايستي در اين معيار ها اصلاحاتي به وجود بيايد و تغييرات عمده اي صورت گيرد.
با است�?اده از مؤل�?ه ها (Components) و چارچوب هاي (Frames) مناسب براي يک پروژه مي توان زمان توليد نرم ا�?زار را به طور چشمگيري کاهش داد. در نتيجه در تخمين زدن مي توان با توجه به مول�?ه ها و چارچوب هاي موجود در کتابخانه توليدي عمل کرد. هر چقدر اجزاء سيستم جديد با است�?اده از ابزارهاي موجود بيشتر قابل توسعه باشند مي توان پروژه را سريعتر توسعه داد.
اسرار هويدا شد! مکانيزم کار اين است که ما در رادمان با توجه به زمان و نياز بازار در زمانهاي بين پروژه ها مول�?ه ها و چارچوب هاي عمومي توليد مي کنيم و يا در زمان هر پروژه ابزارها را به قدري عمومي مي سازيم که بتوانيم از آنها در پروژه هاي بعدي است�?اده کنيم. حال در يک پروژه جديد زمانبندي اعلامي به مشتري زمان را با است�?اده از روشهاي معمول تخمين زده و اعلام مي کنيم. مشتري نيز معمولا با همين روش محاسبه زمان و هزينه را انجام داده و در مطابقت هزينه ها، زمان و هزينه اعلام شده ما منطقي جلوه مي کند. اما ما با توجه به توانايي هاي �?ني و ابزارهاي موجود، نرم ا�?زار را سريعتر توسعه مي دهيم که باعث کاهش �?وق العاده زمان براي ما مي گردد که از جانب مشتري هم مقبول واقع مي شود چون زودتر از آنچه تصور مي کرده به نياز خود رسيده است.