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

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

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

همين!

همانگونه كه پيشتر در مطلبي در مورد مشاوره �?نآوري اطلاعات نوشته بودم، يكي از مهمترين كارهاي مشاور قبل از آغاز يك پروژه تهيه RFP است. اين كار مشكلات خاص خود را دارد به طوري كه باعث مي شود برخي اوقات به يك كار طاقت �?رسا و زمانگير تبديل شود. در بين مستندات مكتوب ابتدايي يك پروژه به نظر من پيچيده ترين است. شما در قرارداد (Contract) يك طرح به اندازه كا�?ي مبهم نوشته مي شود كه بعدا بتوان روي آن مانور كرد!  در پيشنهاد (Proposal) هم   آنقدر بزرگنمايي و كلي گويي صورت مي گيرد كه يك طرح را بسيار بزرگتر از حد واقعي نشان داده و همه ابزارهاي مورد است�?اده را بهترين ابزار معر�?ي كرد!

اما در RFP  طرح بايد به اندازه واقعي خود مشخص باشد و درخواست بايد به شكلي باشد كه پيشنهاد دهنده ها، پيشنهاد هاي نزديك به هم از نظر زمان و هزينه ارائه نمايند. در اينكار هم بايد نياز كار�?رما در نظر گر�?ته شود و هم توانايي هاي شركتهاي مجري و �?نآوري هاي موجود.
حال اگر اين RFP براي يك سازمان دولتي باشد كار مشكل تر هم مي شود چون بايد مقررات مختل�? اداري را نيز در تهيه آن در نظر گر�?ت و تاييد بخش هاي مختل�? را براي آن بدست آورد كه به دليل تنوع مقررات و كندي �?رآيند كاغذ بازي هاي اداري و نيز ت�?اوت سليقه هاي مختل�? كار مشكل تر هم مي شود.
به نظر مي رسد براي ارائه يك RFP  خوب بهتر است همانگونه كه در روشهاي تجزيه و تحليل سيستمها متدولوژي هاي استاندارد مطرح هستند و يا در برنامه سازي، زبانهاي برنامه نويسي بايد در تهيه اينگونه مستندات هم يك زبان �?رمال وضع نمود.هر چند تلاشهاي در اين زمينه صورت گر�?ته است كه در اين بين مي توان به كار خوب "نماتن" اشاره كرد اما متاس�?انه هم چيز در جهت قالب بندي و نگارش مستند به صورت سطحي باقيمانده است و تلاش جدي براي ارائه يك راه كار كلي تر و اصولي تر صورت نگر�?ته است. كاري كه در صورت انجام مي تواند حجم زيادي از �?شارهاي كاري مشاورين �?نآوري اطلاعات را كاهش دهد.

به لحاظ كاري هم اكنون مشاور يكي از شركتهاي دولتي بزرگ هستم در زمينه �?نآوري اطلاعات و دولت الكترونيك و در اين مقطع از زمان در حال تهيه RFP مربوط به سيستمهاي اطلاع رساني شركت و به طور مشخص پايگاه اطلاع رساني اينترنتي و يا وب سايت شركت. در آغاز تهيه اين RFP �?كر مي كردم كه اين گزارش در حداكثر دو ه�?ته تا يك ماه اينكار جمع خواهد شد. كه همينگونه هم شد. در عرض 20 روز گزارش نهايي (از ديدگاه من) آماده شد و تحويل كار�?رما شد اما از آن روز تا كنون (كه حدود 3 ماهي گذشته!) مدام در حال تغيير است و شايد جمع خطوط تغيير يا�?ته اش روي هم به 10 خط هم نرسد! اما هر بخش از سازمان نظري مي دهد كه به نظر خودش بايد اعمال شود و اولويت ها را از ديدگاه خود تعيين ميكند و جمع كردن همه اين اولويت ها اغلب غير ممكن است و بايد به يك جمع بندي برسيم. �?قط اميدوارم در ه�?ته آينده اين RFP بالاخره تاييد شود تا بتوانم مرحله ديگري از كار را سريعتر آغاز كنم

همين!

یکی از استادان گرانقدرم در دوره کارشناسی، جناب آقای روحانی رانکوهی، همیشه از استادانی که دروس مختل�?ی را تدریس می کردند انتقاد می کردند و به آنها می گ�?تند: "�?ول چارت" : یعنی همه دروس چارت آموزشی را تدریس می کنند! همانطور که اسم عام دانشجو "تنبل" و اسم خاص من هم "دلار باز" بود! چون در زمان دانشجویی سر کار می ر�?تم و استاد این شیوه دانشجویی را نمی پسندیدند، بگذریم ....
انوقتها  با وجودیکه برای استاد احترام ویژه ای قائل بودم به نظرم این حر�?شان درست نبود. �?کر می کردم استاد "�?ول چارت" بودن نه تنها بد نیست بلکه این مساله که یک ن�?ر دروس مختل�? را در یک زمان تدریس کند نشانه تبحرش در همه دروس است و عمق دانش وی را نشان می دهد.

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

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

همین!

"روز چهارشنبه بیژن با خانم ولیزاده مشغول راه اندازی سیستمهای ستاد بودند و برنامه اموال آنها (پروژه آبتین) را روی  ایستگاههای کاری نصب کردند. آخر وقت با بیژن صحبت می کردم تا از وضعیت نهایی مطلع شوم. خیلی خوشحال بود. می گ�?ت جزو تجربه های اولیه اش است که یک سیستم را در این حد نصب کرده است. همزمان کاربرهای مت�?اوت با سیستم کار کنند. سیستم ما تقریبا یک اتوماسیون برای یک اداره  به صورت کامل است. به بیژن گ�?تم پس هنوز Package نساختی بدونی اون چه لذتی داره ....! به جای اینکه در یک سازمان از یک سیستم  چند ن�?ر است�?اده کنند در چند سازمان مت�?اوت از یک سیستم است�?اده کنند.... "

از این تجربه که بگذریم لذت تولید نرم ا�?زار در همین نکته ظری�? است. همان مساله معرو�? یک بار تولید N بار است�?اده.صنعت نرم ا�?زار برخلا�? خیلی از صنایع دیگر این خاصیت را دارد که یکبار یک محصول تولید می شود و بعد می توان از آن است�?اده های بیشمار کرد. این همان مساله است که برای من انگیزه باقی ماندن در این صنعت را ایجاد می کند. وگرنه نرم ا�?زار به لحاظ �?رآیند تولید یک �?رآیند گران قیمت می باشد. دلیل این امر گرانی قیمت هزینه نیروی کارشناسی است که در این صنعت نسبت به صنایع دیگر وجود دارد. در صنایع دیگر هر چند ار ابزار و تجهیزات بیشتری است�?اده می شود اما نیروی کار بیشتر در حد نیروی کاردان و یا کاربری است تا کارشناسی در حالیکه در نرم ا�?زار حجم نیروی کارشناسی (مدیر پروژه، تحلیل گر، برنامه نویس , آزمایش کننده و حتی نصاب)  بیشتر است. علاوه بر این �?رآیند تولید در نرم ا�?زار معمولا زمان بیشتری نسبت به صنایع دیگر دارد و این مساله نیز هزینه ها را بالاتر می برد.

اما حسن نرم ا�?زار در آن است که با تولید یک بسته نرم ا�?زاری با در نظر گر�?تن نیازهای مشتریان مت�?اوت می توان آن را به مشتریان مختل�? عرضه کرد بدون اینکه هزینه زیادی برای هر مشتری جدید متقبل شد(هزینه مواد اولیه و یا تولید مجدد (تحلیل، طراحی و پیاده سازی) حذ�? می گردند ) و برای هر مشتری جدید �?قط هزینه های عمومی شرکت، هزینه بازاریابی و �?روش، منطبق سازی (که معولا از بقیه بخش ها بیشتر است) و هزینه های نصب و پشتیبانی باید در نظر گر�?ته شود. این مساله باعث می شود که در شرکتهای نرم ا�?زاری معمولا ر�?تار کسب درآمد برای هر محصول یک نمودار تقریبا سینوسی است و یک زمان هزینه های بالایی دارند (زمان تولید) و یک زمان درآمد بالا (زمان �?روش) . شرکتی مو�?ق است که یا سرمایه زیادی داشته باشد تا نقاط �?رود نمودار مشکل ساز نباشد و یا بتواند نقاط اوج �?روش یک نرم ا�?زار را با نقاط �?رود تولید یک نرم ا�?زار دیگر همزمان کنند تا با کمبود نقدینگی مواجه نشوند.

باز هم در این مورد مطلب خواهم نوشت ........

"چند وقت پیش با آقای مجید نوید در مورد سند زدن در حسابداری شرکت های نرم ا�?زاری صحبت می کردم. صحبت جالبی می کرد. می گ�?ت اینکار بسیار مت�?اوت از خیلی شرکتها است. در زمان تولید یک نرم ا�?زار معمولا شرکتهای نرم ا�?زاری �?قط هزینه می کنند و درآمدی از آن پروژه ندارند، حال اگر به عملکردشان نگاه شود شرکت زیانده نشان داده می شود. در حالیکه اگر در زمان �?روش همان نرم ا�?زار بدون در نظر گر�?تن زمان تولید از حسابهای شرکت گزارش گر�?ته شود سود غیر منطقی و بالایی نشان داده می شود. نکته ای که اکثر شرکتهای نرم ا�?زاری به آن دقت نمی کنند و حسابداری آنان اصولی نیست و با تغییر دوره ها و یا تعیین حسابهای سرمایه ای و یکسری چیزهای دیگر که من از آنها سر در نیاوردم [!] می توانند از عملکرد مالی خود در زمانهای مت�?اوت جمع بندی مناسبی داشته باشند."

همین!

اين چند روز، روزهاي انتهايي پروژه آبتين است. �?رآيند توسعه اين پروژه مدتهاست كه تمام شده ، اما همانگونه كه براي همه پروژه هاي نرم ا�?زاري متصور است از زمان اتمام توسعه از ديدگاه گروه مجري (پيمانكار) تا زمان تحويل گر�?تن آن توسط مشتري (كار�?رما) مدت زمان نسبتا زيادي طول مي كشد! در اين مدت معمولا تازه  كار�?رما متوجه مي شود كه چه نيازهايي از سيستم جديد دارد و چه جاهايي را �?رآموش كرده است. خصوصا اگر مشتري از بين سازمانهاي دولتي باشد اين زمان طولاني تر مي شود.
پيشتر زماني كه براي پروژه ها زمانبندي مي كردم �?كر مي كردم زماني حدود يك ه�?ته براي نصب نهايي سيستم كا�?يست. اما تجربه نشان داد كه اين زمان بسيار كم است.

براي مثال در  پروژه آبتين ، حدود 70% از كار در مدت 2 ه�?ته انجام شد. يعني براي يك پروژه به اين بزرگي از زمان دريا�?ت س�?ارش تا آماده شدن نسخه اول 2 ه�?ته بيشتر طول نكشيد كه زمان بسيار خوبي است. اما بعد از آن مواجه شديم با حجم زيادي از تغيير نيازها ، برخي از اين نيازها باعث شد كه بخشهايي از سيستم با تغييرات ساختاري مواجه شوند و حدود 2 ماه بعد درگير انجام اين تغييرات و در ادامه 30% انتهاي پروژه شديم.هر چند براي اين پروژه بيشتر �?از تحليل توسط نيروهاي داخلي سازمان كه بالطبع آشنايي خوبي با سيستم دارند صورت گر�?ته بود و مبناي كار پياده سازي بر اساس اين تحليل ها صورت مي گر�?ت ، تغييرات جديد مواردي بود كه نمي شد آنها را قبل از اتمام پروژه تشخيص داد. چون خود تحليل كنندگان هم با آن آشنا نبودند.

به جز اين بعد از تحويل نهايي نوبت نصب مي رسد كه �?رآيند زمانگيري است(البته در ايران و به خصوص در مراكز دولتي). چون تا سيستمها آماده شوند و نيروهاي كاري آماده پذيرش سيستم جديد شوند معمولا روزهاي زيادي به بيهودگي مي گذرد.

اما در اين دو ه�?ته گذشته به مرور  پروژه آبتين به مراحل  پاياني خود نزديك شد و تحويل گرديد. امروز هم بچه هاي شركت مشغول نصب دوباره نرم ا�?زار بر روي سيستمهاي موجود مي باشند و به نظر مي رسد عامل ديگري موجب تاخير در اختتام پروژه نشود! مساله اي كه مي دانم تا زمان تاييد نهايي كتبي كار�?رما نبايد زياد به آن دلخوش بود!

همين! 

بیژن از آن گروه برنامه نویسهایی است که از برنامه نویسی لذت می برد. بیژن برنامه نویسی را نه به عنوان یک راه برای کسب پول بلکه به عنوان یک ت�?ریح نگاه می کند و عامل مو�?قیتش هم همین است. چون از برنامه نویسی لذت می برد می تواند خوب و با پشتکار برنامه بنویسد. نکته جالبی که در مورد بیژن می توان گ�?ت تن�?رش از گزارش نویسی در دل�?ی در آغاز دوره برنامه نویسی حر�?ه ایش با رادمان بود. اولین کار جدیش این بود که گزارشات یک سیستمی که پیشتر تولید شده بود را از quick Rep به Rave تبدیل کند و او از این کار متن�?ر بود. به همان دلیلی هم که در ابتدای نوشتار ذکر کردم چون از این کار لذت نمی برد به سختی این کار را انجام می داد. تا اینکه ..... در پروژه جدیدی که با هم قرار شد کار کنیم به بیژن قول دادم به مجردی که توانایی جذب یک نیروی جدید را داشته باشیم یک ن�?ر را به عنوان گزارش ساز استخدام کنیم. تا آن زمان با وجودیکه می دانم سخت است ساخت گزارشات به عهده وی باشد. با وجودیکه زیاد راضی نبود اما پذیر�?ت. اما در تمام طول پروژه نگران بودم که اینکه بیژن از این کار لذت نمی برد باعث ا�?ت کی�?یت نرم ا�?زار شود هر چند به وجدان کاریش اعتقاد دارم و می دانم هر وقت کاری را قبول کرد حتما انجامش می دهد. اما ..... نتیجه خیلی جالب بود. بیژن برای اینکه از گزارش گیری هم لذت ببرد شروع کرد به ایجاد به قول خودش ماژول های جنرال! این کار باعث شد که ما در انتهای پروژه یک ابزار گزارش گیری پویا با قابلیتهای خوب داشته باشیم.نتیجه به حدی راضی کننده بود که توانستیم �?رآیند زمانگیر تولید گزارشات را در زمان خیلی کوتاه تری از آنچه پیش بینی کرده بودیم به انجام برسانیم. ات�?اقی که ا�?تاد خیلی جالب بود ، با وجودیکه نیروی جدیدی هم در انتهای پروژه در رادمان جذب شد، بیژن آنقدر نسبت به Rave آشنایی پیدا کرد که سند نوشتن گزارشات برای تمام عمر به نامش ثبت شد!! اما چرا این ها را نوشتم.... به خوانندگان این وبلاگ موکدا توصیه می کنم که چنانچه مایلند با دل�?ی خوب آشنا شوند و بویژه بتوانند از ابزار جدید گزارگیری آن (Rave) به خوبی است�?اده کنند حتما از بیژن کمک بگیرند و نوشته هایش را در سایت به صورت جدی دنبال کنند. مطمئن هستم از این کار ضرری نخواهند کرد. همین!

در �?رآیند ساخت سیستمهای اطلاعاتی مبتنی بر کامپیوتر (CBSD: Computer Based Information System) سه �?رآیند اصلی نقش دارد: 1- �?رآیند توسعه : شامل تمامی مراحل تجزیه و تحلیل، طراحی، پیاده سازی و تست سیستم و .... 2- �?رآیند مدیریت : مدیریت پروژه نرم ا�?زاری شامل همه اعمال تعری�? ابزارها و تشکیل گروه کاری، زمانبندی و تخمین هزینه و .... 3- �?رآیند پشتیبانی : شامل �?عالیت های مرتبط با پشتیبانی و نگهداشت نرم ا�?زار هر سه این �?رآیند ها بایستی به دقت انجام شوند تا در نهایت یک پروژه نرم ا�?زاری به نتیجه دلخواه خود برسد. اما متاس�?انه در بازار نرم ا�?زاری ایران اغلب شرکت های تولید کننده نرم ا�?زار این مسائل را نادیده می گیرند و معمولا این �?رآیند ها به خوبی پیموده نمی شود. با این وجود با توسعه متدولوژی های تجزیه و تحلیل سیستم ها و بالا ر�?تن سطح آگاهی مشتریان و بالطبع آن سطح توقعشان از یک نرم ا�?زار ، گروه های تولید ناچار شده اند که �?عالیت تجزیه و تحلیل سیستم ها را جزء مراحل ساخت سیستم خود در نظر بگیرند و زمان و هزینه آن از یک طر�? و خروجی آن از طر�? دیگر را جزء اجزای پروژه خود در نظر بگیرند.بگذریم از اینکه معمولا خروجی �?ازهای تحلیل و طراحی مورد است�?اده در پیاده سازی قرار نمی گیرد! و معمولا �?از پیاده سازی همزمان با �?از تجزیه و تحلیل شروع می شود تا در زمانبندی سرعت ببخشند و گزارش های تحلیل و طراحی معمولا صر�?ا برای خالی نبودن عریضه و بستن دهان کار�?رما تولید می شود. اما در �?رآیند های دیگر همچنان ضع�? به چشم می خورد. اکثر مدیران پروژه نرم ا�?زاری در ایران، برنامه نویسان قدیمی تر و یا قوی تر گروه می باشند. در حالیکه �?رآیند مدیریت دانش و توانایی خاص خود را می خواهد و بسیار مت�?اوت از برنامه سازی و یا حتی تجزیه و تحلیل سیستم هاست. هر چند یک مدیر پروژه باید در در جه اول برنامه نویس خوب و تحلیل گر خوبی باشد اما لزوما یک برنامه نویس خوب یک مدیر پروژه خوب نیست.به عنوان مثال مدیریت نیروی کارشناسی بحثی است که بسیار مشکل است و نیاز به تجربه و شناخت کا�?ی از اخلاق و روحیات بدنه کارشناسی تولید کننده سیستم می باشد و یا از طر�? دیگر بحث زمانبندی و تخمین های سیستم و یا مدیریت ریسک نیاز به دانش کا�?ی از مسائل مرتبط دارد. �?رآیند پشتیبانی که وضعیت بسیار بدتری نسبت به �?رآیند های مرتبط با ساخت دارد. جو بی اعتمادی که در بین صنایع و شرکتها و سازمانهای ایرانی نسبت به تولید کنندگان نرم ا�?زاری داخلی وجود دارد ناشی از همین ضع�? است.برای نمونه چند ماه پیش در یک شرکت خصوصی متوسط (و نه بزرگ) جلسه داشتیم. این شرکت از بهترین (یا به عبارت بهتر معتبر ترین و یا باز هم دقیق تر �?قط معرو�?ترین!) شرکتهای تولید کننده سیستمهای جامع مالی ایران نرم ا�?زار خریداری کرده بودند. ضع�? در پشتیبانی از نرم ا�?زارهای خریداری شده به حدی خریدار را دچار مشکل کرده بود که راه را در خرید نرم ا�?زار از خارج از ایران و شرکتهای خارجی دنبال کرده بودند و با یک شرکت هندی در این زمینه قرارداد امضا کرده بودند! این که مشاهده می شود با وجودیکه در ایران اینهمه توانایی �?نی نرم ا�?زاری وجود دارد و اکثر شرکتهای نرم ا�?زاری با مشکل پیدا کردن مشتری خوب مواجه هستند و در همینه حال خریداران با وجود گرانتر بودن قیمت از خارج نرم ا�?زار تهیه می کنند واقعا تاس�? برانگیز است. اما مقصر اصلی این مشکل خود شرکتهای نرم ا�?زاری هستند چون �?رآیند پشتیانی نرم ا�?زار های خود را به خوبی انجام نمی دهند. در این باره باز خواهم نوشت. همین!

در این وبلاگ در مورد برنامه Rave که یک برنامه گزارش گیری است نکاتی را آموزش داده می شود. Rave برنامه گزارش گیری است که با است�?اده از یکی از زبانهای برنامه نویسی قابل است�?اده است که در اینجا قصد دارم نحوه است�?اده آن با زبان دل�?ی (Delphi) را آموزش بدهم. به زودی �?هرستی از مطالبی را که در مورد این برنامه گ�?ته خواهد شد مینویسم اگر نظری در مورد شروع مطالب دارید می توانید من را از آن مطلع کنید تا بر اساس آن اولویت ارائه مطالب را تنظیم کنم. بیژن قاسمی

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

در ترم جاری (نیمسال اول 84-83) در دو دانشگاه مت�?اوت کلاس دارم. یکی از این دانشگاه ها ، دانشگاهی سراسری و دیگری یکی از دانشگاههای غیر انت�?اعی است. تجربه جالبی است تدریس در دو دانشگاه مت�?اوت. اولی با وجودیکه دانشجوها و استادان بهتری دارد اما اصلا نظم ندارد و آموزش دانشکده واقعا خیلی ضعی�? کار می کند. در حالیکه در دانشگاه دوم با وجودیکه نسبت به اولی وضع دانشجویان از نظر سطح آموزشی پایین تر است اما واقعا روی یک نظم مشخص و خیلی خوب عمل می کنند. من هم مانده ام بین دو سبک کار. در اولی دانشجویان بهتر و بیشتر �?عالیت می کنند اما واقعا با کارکنان اداری دانشکده کار کردن مشکل است. در دومی با وجودیکه دانشجویان نسبتا خوب هستد اما زیاد تنبلی می کنند. تا امروز یک شیوه برخورد را در هر دو دانشگاه است�?اده می کردم اما کم کم به این نتیجه رسیدم که نوع برخورد باید مت�?اوت باشد. نکته ای که قبلا در برخی استادان دانشگاه ها دیده بودم و همیشه به آن انتقاد می کردم. واقعا که آدم باید جای یک ن�?ر باشد تا بتواند در مورد ر�?تار وی خوب قضاوت کند. نکته دیگر آنکه خود من یک زمانی دانشجوی دانشگاه اول بودم. اما امروز که به یک نقش دیگه به اون دانشگاه می رم چیزهای جالبی کش�? می کنم. اولا واقعا تجربه عجیبیه! این که آدم بره دانشگاه سابقش برای تدریس. زمانی نشسته روی صندلی های کلاس ها، زمانی ایستاده کنار تخته سیاه! برای خودم که خیلی جذابه. ثانیا نقش بعضی آدم ها رو زمان دانشجویی نمی دونستم چیه!؟ اما الان کاملا می �?همم. مثلا یک آقایی بود که زمان دانشجویی همش �?کر می کردم عجب آدم علا�?یه همش تو دانشکده قدم می زنه! اما امروز �?همیدم که اون قدم می زنه تا چک کنه ببینه همه کلاس ها تشکیل شده یا نه!؟ نکته آخر این که برخورد استادهای قبلیم با من خیلی جالبه! یک زمان دانشجوی آن ها بودم حالا به نوعی همکار. گرچند عضو هیات علمی نیستم و هنوز خیلی راه است تا رسیدن به جایگاه استادهای خودم. اما واقعا برخورد برخی از آنها برام لذت بخش بوده و برخورد خوبی با من کرده اند. اما وای از دست بعضیها! انگار جای اونها رو گر�?تم! و در برخوردشون می خواهند به من حالی کنند که هنوز دانشجوی آنها هستم. هر چند واقعا در خودم همین احساس رو نسبت به اونها دارم و خیلی براشون احترام قائلم. اما کاش ...... همین!

امروز جلسه ای در یک کارخانه صنعتی که در زمینه تولید لوازم خانگی فعالیت می کند بحث جدیدی در مورد کاربردهای گویا2 انجام دادیم. این کارخانه یکی از بزرگترین تولید کنندگان نوع خاصی از لوازم خانگی است که تقریبا بازار ایران را به طور کامل پوشش داده است و به جز این صادرات خوبی به کشورهای خارجی داشته است. مساله ای که هم اکنون فکر مدیران این کارخانه را به خود مشغول کرده است بحث خدمات پس از فروش و کیفیت ارائه این خدمات می باشد. نکته آنجاست که به دلیل حجم فروش بالا و بالطبع آن بالا بودن نرخ تماس ها برای پشتیانی فنی و ارائه خدمات پس از فروش کیفیت ارائه خدمات کاهش پیدا نکند. مشتریان بتوانند در 24 ساعت و در 7 روز هفته امکان برقراری تماس داشته باشند و این تماس ها به طور کامل ثبت گردد. پیشنهاد ما به آنها -که خوشبختانه مورد قبول واقع شد!- آن بود که با کمک یک سیستم تلفن گویا اینکار را انجام دهند. به نحوی که در ساعات اداری سیستم به عنوان یک شروع کننده تماس مطرح باشد و به تماس گیرنده خوش آمد گوید تا زمانی که اپراتور سیستم را فعال نماید. در ساعات غیر اداری سیستم خود فعال شده مشتری نوع دستگاه، اطلاعات تماس و شرح خرابی خود را با سیستم مطرح کند تا در ساعات اداری اپراتور با وی تماس برقرارکرده و تعمیر کار را به محل اعزام کند. یکی دیگر از بخش های این سیستم سرویس دهی به نمایندگان خدمات پس از فروش شرکت در تمام کشور است . به طوریکه به صورت تمام وقت امکان ثبت سفارش قطعات یدکی و اعلام گزارش های مالی برای وی وجود داشته باشد. به همان دلیلی که در مورد سیستم اطلاعات آموزشی در چند نوشته قبل مطرح شد فعلا نمی توانم اطلاعات دیگری در مورد این سیستم در وبلاگ مطرح کنم! بزودی -ظرف3 هفته آینده سیستم تولید و آماده بهره برداری خواهد شد- اطلاعات مفصل در مورد این سیستم و مشتری فعلی آن و مشتریان بالقوه آن در قسمت گویا2 سایت رادمان مطلب خواهیم نوشت. همین!

یکی از قسمت های مهم نرم افزارهای تولیدی رادمان, امکاناتی است که برای پویا سازی آنها اضافه شده است. از مهمترین آنها, امکان فیلتر کردن اطلاعات یک فهرست بر اساس مقادیری است که کاربر برای برخی فیلد ها انتخاب کرده است. در سیستمهای قبلی رادمان این امکان با ایجاد یک فیلتر ساده اما در عین حال کارا که بسیار شبیه عملکرد excel ld می باشد به انجام رسید اما در پروژه جاری -پروژه آبتین- مساله جدیدی مطرح می شود. کاربران بیشتر مایلند یکسری فیلد مشخص را در فیلترکردن استفاده کنند. هر چند اینکار با فیلتر موجود قابل انجام است اما چون این کار همیشگی است و در تعداد بار زیاد اتفاق می افتد بهتر است ابزار ساده تری برای کاربر پیش بینی گردد. مساله ای که فعلا مشغول به فکر کردن در مورد آن هستم. اگر کسی از دوستان نظری دارد مطرح کند تا به ساده ترین شکل برای کاربر ابزاری تولید شود. همین!