آب بندی نرم افزار!

October 17, 2009 4:32 PM

قدیمها هر کس ماشینی صفر کیلومتر می خرید، مدتی را یا نمی دانم مسافتی را با سرعت کم و با درنظرگرفتن شرایط خاص می پیمود تا به اصطلاح ماشین جدیدش آب بندی شود، نمی دانم این رسم هنوز هم برای ماشین های جدید پابرجا است یا نه ....
به نظر می رسد نرم افزارها هم آب بندی می خواهند، اینکه مدتی پس از آماده شدن یک نسخه از نرم افزار با شرایط خاص از آن استفاده کنی تا نرم افزار جا بیافتد! این همان مفهوم ساده شده تست بتا(Beta Test) است، که نرم افزار را در محیط واقعی توسط نماینده مشتری و یا بازی کننده نقش مشتری آزموده شود.
اما ....
این تست بتا همیشه جوابگوی همه نرم افزارها برای همه محیط ها نیست و گاهی رخ می دهد که  پردازش های نرم افزاری در یک محیط خاص وارد نواحی بحرانی شده و خطایی آشکار شود که سالها نهفته بوده است.
هفته پیش همین اتفاق برای یکی از نرم افزارهای ما افتاد، نرم افزاری که یکی دو سال است نسخه جدید آن روانه بازار شده بود و در اختیار ده ها مشتری مختلف و متفاوت قرار گرفته بود تا اینکه ... مشتری آخری آن را در شرایطی استفاده کرد با ترافیک کاربری بالا و استفاده بدون وقفه که ما هم انتظار نداشتیم، در این شرایط خطایی رخ داد که در این یکی دو سالی که از عمر این نسخه می گذرد مشاهده نشده بود، تشخیص و رفع این خطا از آنجا مشکل بود که فقط در آن محیط و در شرایط واقعی رخ می داد و نه در دفتر و نه در هیچ مشتری دیگری این خطا آشکار نمی شد، بنابراین نمی شد روشهای عادی تست و رفع عیب را در آن بکار برد.
القصه پس از چند روز کار شبانه روزی بدون وقفه، عملا اتفاقی که افتاد آن بود که یک بخش از سیستم مجددا کاملا بازنویسی شد چرا که مساله نشان می داد که نمی شود بر اساس همین ساختار موجود، که تشخیص علت خطا در آن غیرممکن به نظر می رسید، عمل کرد و باید ساختار جدیدی برای آن ایجاد کرد، ساختاری که در ترافیک بالا و حجم استفاده زیاد نیز جوابگو باشد و مکانیسم های exception handling به آن اضافه شود.
خلاصه اینکه همیشه آب بندی کردن تنها جوابگو نیست، باید برخی وقت ها با ماشین خود مسابقه هم بدهید که مطمئن بشوید سالم است!
همین!

Ali Vahed | 4:32 PM

مروری بر واژگان مهندسی نرم افزار- بخش 2

August 9, 2009 1:51 PM

واژه های این نوشته را می توان در دسته بندی "Project Management Techniques" قرار داد و عبارتند از:


- steering committees : کميته راهبري، موظف به تهيه اهداف، اصول و  زمانبندي و نحوه تامين منابع لازم براي يک پروژه است.  این کمیته از ذینفعان اصلی پروژه که بر روند اجرایی آن نظارت دارند تشکیل می شود و مدیریتش به عهده مالک اصلی پروژه است. تشکیل این کمیته فقط برای پروژه های متوسط و بزرگ لازم است. این کمیته عهده دار مسؤولیت تغییرات اساسی در محدوده پروژه، اهداف آن، زمانبندی و هزینه ها است. علاوه بر آن این کمیته زمانی که به تصمیم گیری های مهم در فرآیند های اصلی نیاز است تشکیل جلسه می دهد. پیشنهاد می شود این کمیته حداکثر 8 عضو داشته باشد که دو نفر از آنها مالک پروژه و مدیر پروژه باشند.


- project justification :يک پروژه بايد در موارد مالي، اقتصادي و يا ريسکها توجيه داشته باشد. اگر اين اتفاق نيافتد که اين پروژه سود آوري خاصي داشته باشد و يا از نظر اقتصادي و يا کسب و کار اجراي آن درست باشد و يا ريسک هاي قابل قبول و قابل مواجه داشته باشد، پروژه مي تواند از آغاز به شکست بيانجامد.


- project planning :برنامه ريزي پروژه معمولا شامل اقداماتي براي تهيه يک نقشه و مسير درست براي پيمودن گامهاي مختلف است، قبل از آنکه راه آغاز شود بدين شکل که زمانبندي اجراي عمليات چگونه باشد، منابع را به چه شکلي و چه موقعي و چه حجمي نياز داريم، برنامه ريزي مالي چگونه است، به کيفيت چگونه مي انديشيم و کي آن را اندازه گيري مي کنيم، چگونه و در چه زمانهايي با مشتري ارتباط برقرار مي کنيم و اصطلاحا Mile stone هاي پروژه که در آنها کار را ارزيابي مي کنيم چه مواقعي هستند.

- project development strategies : با توجه به عوامل دخيل در يک پروژه از جمله ذينفعان آن، توليد کننده، منابع و محدوديت هاي آن يکي از کارهاي اصلي در ابتداي پروژه، تدوين استراتژي توسعه سيستم است. اينکه چگونه فاز توسعه سيستم پيموده شود. استراتژي هاي زيرادي براي توسعه سيستم وجود دارد که مي توان مهمترين ها را چنين برشمرد:
-روش توسعه خطي : که از تحليل، طراحي و پياده سازي و تست پشت سرهم پيموده مي شود. معمولا براي پروژه هاي ساده و يا کوچک کاربرد دارد.پ
-روش آبشاري (Waterfall) که به صورت پشت سرهم مراحل به شکل فرمال تر و به همراه مستند سازي صورت مي گيرد، معمولا در پروژه هاي ساختيافته استفاده مي شد.
-روش توسعه تدريجي: که سيستم به چند زير سيستم تقسيم مي شود و هر يک جداگانه مثلا به روش خطي ساخته و به تدريج به مشتري تحويل مي شود.
-روش توسعه سريع يا RAD: Rapid application Development که يا ادغام فازهاي مختلف و با تشکيل جلسات هماهنگي با مشتري و سپس توسعه سيستم انجام مي شود.
-روش حلزوني يا spiral که در اين روش به صورت نسخه بندي شده (versioning ) سيستم کامل مي شود، يعني ابتدا هسته اصلي آن ساخته مي شود و سپس مرحله مرحله سيستم کاملتر مي شود.
-CBSD: component based Software Development که با استفاده از مولفه ها (Component) ها سيستم ساخته مي شود
-و ....

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

- methodologies : متدولوژي روشي استاندارد و مدون براي پيمودن فاز هاي تحليل، طراحي و پياده سازي نرم افزار ها به همراه ابزارها و تکنیک های برای تسهیل این کار است. متدولوژي هاي در گروه هايي مانند متدولوژي هاي ساختيافته (نظير SSADM) ، متدولوژي هاي شيء گرا (مانند RUP) يا متدولوژي هاي چابک agile (مانند XP) مورد استفاده قرار مي گيرند. هر متدولوژي علاوه بر آنکه يک تحليل گر را هدايت مي کند که در هر مرحله چه بايد بکند بلکه مجموعه از نماد ها و يا ابزارها و يا تکنيک ها را هم براي وي فراهم مي کند که داشته هاي خود را مستند و مديريت کند.

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

- estimation : تخمين يکي از وظائف اوليه هر پروژه است به شکلي که بتوانيم سايز و در نتيجه نفر-ساعت مورد نياز و منابع لازم را شناسايي کنيم تا قبل از اجرا بتوانيم به يک برآورد درستي از هزينه هاي پروژه و امکان سنجي اجراي آن برسيم.
براي تخمين معمولا بايد سايز براساس تعداد خط LOC يا FP اندازه گيري شود و سپس با يک نسبت گيري و يا بر اساس روشهايي نظير COCOMO تخمين زمان صورت گيرد.

- quality assurance : تضمين کيفيت نرم افزار معمولا در پارامترهاي زير صورت مي گيرد:
-صحت Correctness : چقدر نرم افزار نيازهاي مشتري آن را به شکل درست برآورد مي کند.
-قابليت اطمينان و توانمندي robustness & reliability: به جز صحت، چقدر نرم افزار در شرايط غير طبيعي و ورودي هاي اشتباه مقاوم است و واکنش درست نشان مي دهد.
-کارايي efficiency : چقدر از منابع سخت افزاري و نرم افزاري درست و به شکل بهينه استفاده مي شود.
-قابليت جابجايي Portability : چقدر مي توان نرم افزار را از يک Platform به ديگري منتقل کرد، مثلا روي سيستم عامل هاي مختلف کار مي کند يا نه...
-قابليت استفاده مجدد reusability : اينکه از يک قسمت از نرم افزار يا همه آن بتوان در همان نرم افزار و يا در سيستمهاي ديگر مجدد استفاده کرد.
-قابليت استفاده usability يا استفاده آسان easy to use : چقدر نرم افزار براي گروه کاربران هدفش آسان و قابل استفاده است و راهنما و يا واسط کاربري user interface مناسب دارد.
-قابليت نگهداري maintainability : با چه هزينه اي مي توان نرم افزار را نگهداري و پشتيباني کرد.
-قابليت وارسي verifiability : چقدر آسان مي توان نرم افزار را تست کرد و از صحت و قابليت اطمينان آن مطمئن شد.
-سازگاري compatibility يا Interoperability : آيا نرم افزار در کار ساير نرم افزار ها اختلال ايجاد مي کند و آيا مي تواند با آنها کار کند مثلا داده به شکل فرمتهاي استاندارد به عنوان وروردي يا خروجي بگيرد .
-و....

- scheduling : زمانبندي پروژه همان است که چه کاري قبل و بعد از چه کارهايي و در چه زماني بايد انجام دهد و چه کساني مسؤول آن هستند و چه منابعي براي آن نياز است. معمولا در اين زمان از نمودار گانت Gantt استفاده مي شود با تعريف نقاطي براي ارزيابي.

- project tracking and reporting : ردگيري پروژه از اين جهت که چقدر با برنامه زماني و بودجه پيش بيني شده همراه است و انحراف دارد يا خير و اينکه چه ميزان منطبق بر تخمين اوليه استوار است از وظائف اصلي و نظارتي يک مدير پروژه است. اينکه قبل از اينکه از زمان يا هزينه عقب بيافتيم آن را شناسايي کنيم و بتوانيم با تغيير مسير و يا افزايش و يا مديريت مجدد نيروي انساني و منابع دوباره در مسير درست قرار بگيريم تا اهداف پروژه محقق شود.

ادامه دارد...
همین!

Ali Vahed | 1:51 PM

مروری بر واژگان مهندسی نرم افزار- بخش 1

July 30, 2009 11:15 AM

دوستی از من خواست، چند واژه مهندسی نرم افزار را به زبانی ساده برایش تعریف کنم، گویا برای جایی لازم داشت، قبول کردم، هر چند نشد و لزومی هم نداشت که خیلی درست و کامل این واژه ها تعریف شوند اما بد ندیدم برای تکمیلشان آنها را اینجا بگذارم. علی الحساب قسمت اول واژه ها را که می توان در دسته بندی Concepts and Models  قرار داد می نویسم تا در نوشته های بعدی سایر مباحث مهندسی نرم افزار و تضمین کیفیت نرم افزار را نیز پوشش دهم.


1- project definition : تعریف پروژه مهمترین کار ابتدایی در یک پروژه است، در این مرحله شما اهداف، محدودیت ها، منابع، عوامل موفقیت و ریسکهای پروژه شناسایی شوند. در موفیت یک پروژه مهمترین مساله آنکه، می گویند همیشه باید از نقطه درست شروع کرد، برای همین باید نقطه شروع را ابتدا به صورت کامل شناسایی کرد و آنها که گفتم را مشخص نمود. تا بتوان یک سازماندهی درست انجام داد، سپس برنامه ریزی درستی کرد و در نهایت ارزیابی کاملی از نحوه اجرا انجام داد.


2- project success :میزان تحقق اهداف پروژه و موفقیت آمیز بودن آن را مشخص می کند، به پیشنهاد برخی ها می توان آن را در چهار سطح بررسی نمود :
- Project Managment Success : بررسی هزینه، زمان و کیفیت پروژه و محصولات آن
- Repeatable Project Managment Success :  مرور و مقبولیت سنجی محصولات قابل پیش بینی پروژه ها
-Project Success : سنجش میزان سود حاصل از اجرای پروژه
-Cooperate Success : مطالعه استراتژی های نهاینه شده  در اثر اجرای پروژه ها و ارزش افزوده حاصل

3- measuring success : جمله معروفی هست که می گوید اگر بتوانی یک چیز را اندازه بگیری می توانی آن را مدیریت کنی! در نرم افزار می توان چهار هدف زیر را برای اندازه گیری مشخص کرد:
- برای مشخص سازی (to Characterize) : برای فهم یک موضوع (فرآیند، محصول، منبع یا ... ) و ایجاد یک مبنا و پایه برای بررسی های بعدی
- برای ارزیابی (to Evaluate) : تشخیص وضعیت جاری نسبت به برنامه ریزی ها و اندازه گیری های اولیه و تعیین میزان انحراف
- برای پیش بینی (to Predict) : برای ایجاد امکان برنامه ریزی برای پروژه جاری و پروژه های آتی
- برای بهبود (to Improve) :ارتقاء هر چیز و تشخیص کاستی های یک چیز و حرکت در جهت اصلاح آنها
طبیعتا یک اندازه گیری که در راستای هدف های فوق باشد می تواند موفق گردد و سه چیز اصلی را برای ما روشن کند، سایز ، کیفیت و نحوه صرف زمان و هزینه

4- post-implementation reviews فرایند PIR یک کار تقریبا فرمال است که مدت زمانی پس از پایان پروژه صورت می گیرد. برای اینکه:
-میزان تحقق اهداف پروژه را بدست آوریم.
-کارایی محصول را اندازه بگیریم تا به نیاز آن به بهبود احتمالی در بعد برسیم.
-برای اینکه از پروژه درس بگیریم تا در پروژه های بعدی استفاده کنیم.
این کار معمولا پس از مدتی از پایان پروژه (در پروژه های متوسط و بزرگ بین 6 هفته تا 6 ماه بعد صورت می گیرد) و با طرح سوالات مشخصی در جنبه های مختلف صورت می گیرد و توسط خود تیم پروژه و یا تیمی مستقل صورت می گیرد.

5- project size سایز پروژه که بر مبنای تعداد خطوط برنامه LOC و یا FP Function Point و یا Object Point اندازه گرفته می شود. سایز پروژه از آن جهت مهم است که می توان پیش از آغاز تخمین زد چقدر زمان و منابع برای اجرای پروژه مورد نیاز است.

6 - lines of code معیار اندازه گیری سایز یک برنامه (تعداد خط برنامه) که معمولا پیش از آغاز پروژه بر اساس تجربیات برنامه نویس و یا مشاهده نمونه های مشابه تخمین زده می شود تا بر اساس آن مدت زمان و تلاش مورد نیاز برای پروژه بدست آید. معمولا به صورت مخفف LOC نام برده می شود و در زبانهای ساختیافته و محیط های برنامه سازی غیر ویژوال بیشتر کاربرد داشت.

7- effort/duration میزان تلاش در واحد زمان که به صورت نفر-ماه و یا نفر-ساعت بیان می شود. پس از تخمین سایز پروژه شما باید محاسبه کنید که از تخصص های مختلف در پروژه جاری چه مقدار نیاز دارید، مثلا چند نفر-ماه برنامه نویس و یا چند نفر-ماه گرافیست یا .... در هنگام اجرای پروژه نیز یکی از وظائف مدیر پروژه مطابقت آمار واقعی کار انجام شده با تخمین های اولیه است.

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

9- project life cycle : می توان چرخه حیات یک پروژه را در چهار مرحله شناسایی کرد:
- آغاز : شامل شروع پروژه با مستند سازی محیط تجاری، امکان سنجی، ارجاعات و چیدن تیم پروژه و سازمان کاری آن
- برنامه ریزی: شامل برنامه ریزی و تهیه نقشه راه پروژه با ایجاد برنامه های پروژه، برنامه منابع، برنامه مالی، برنامه کیفیت، برنام مقبولیت و برنامه ارتباطات پروژه
-اجرا: شامل ساخت محصولات قابل عرضع پروژه بر مبنای مدیریت محدوده، هزینه، کیفیت و ریسکهای پروژه
- اختتام: شامل عملیات پایانی پروژه، رها سازی منابع، تحویل محصولات قابل عرضه به مشتریان و تکمیل مرور پس از پیاده سازی (PIR).

ادامه دارد...
همین!

Ali Vahed | 11:15 AM

خدمات پشتیبانی محصول نرم افزاری، بخش 6، مدیریت بحران

November 8, 2008 10:38 AM

یکی از وظائف اصلی فرآیند مدیریت پشتیبانی، مدیریت ریسک و مدیریت بحران است.
چرا؟



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

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


در نوشته (های) بعد، انواعی از این خطرات و ریسکها یا بحرانها به همراه روشهای تحلیل و مدیریت آنها را بررسی خواهم کرد.


همین!

Ali Vahed | 10:38 AM

خدمات پشتیبانی محصولات نرم افزاری، بخش 5 ، انتخاب نیروی پشتیبانی

August 11, 2008 12:29 PM

یکی از مسائل مهم در مورد خدمات پس از فروش، انتخاب نیروی انسانی مناسب و خوب در این بخش است. چون در این خدمات، وجه نیروی انسانی و توانایی وی در ارائه خدمات به مشتری به اندازه وجه فنی اهمیت دارد، در کتاب Software That Sells خصوصیات یک نیروی پشتیبانی به شرح زیر ارائه شده است:
اگر چه نیروهای پشتیبانی خوب در همه سن و جنسیتی هستند، اما باید یکسری مشخصات مشترک را داشته باشند. آنها شنونده های خوبی هستند. آنها محصول خود را هم از جنبه خارجی و هم داخلی به خوبی می شناسند. آنها به وضعیت مشتری حساس هستند و نمی توانند از آن بی تفاوت گذر کنند. آنها می توانند مشکلات را درک کنند و راه حل ها را با زبانها و شیوه های مختلف بیان کنند، چون مشتریان یکسان نیستند و با هر کس باید به زبان خودش صحبت کرد.
آنها به مشتری احترام می گذراند و اگر مشتری با آنها تماسی برقرار کرد بلافاصله پس از رفع نیاز وی ارتباط را قطع نمی کنند بلکه از وی می پرسند آیا کار دیگری برای وی می توانند انجام دهند؟
این افراد کم گیر می آیند، آنها دارای خصوصیت ذاتی هستند به شکلی که به مشکلات مردم اهمیت می دهند و می توانند در مورد این موضوع با آنها صحبت کنند، کسانی که از کمک به دیگران لذت می برند. این افراد معمولا گران قیمت نیستند اما باید بدانیم که لازم است به خوبی آموزش ببینند و به انها انگیزه داده شود.
همین!

Ali Vahed | 12:29 PM

فروش قبل از تولید یا تولید قبل از فروش

August 4, 2008 9:34 AM

در حرفه واسطه گری، گاهی وقت ها واسطه ها کارهایی را می کنند که انسان تعجب می کند، اینکه یک محصولی که هنوز تولید نشده را می خرند و می فروشند و سرآن معامله می کنند! همه ما ابتدا که چنین موضوعی را می شنویم بلند بلند می گوییم: از دست این دلال ها! ببین چقدر دروغ گو هستند!
اما به خودمان که می رسد، نرم افزاری را که آماده نشده را آنقدر طبیعی می فروشیم و یا در جلسه دمو در مورد آن صحبت می کنیم که بیایید ببینید که چقدر امکانات دارد! و به خودمان این مهلت را می دهیم که اگر مشتری خواست، اشکالی ندارد برایش تولید می کنیم! به قول بچه ها یک نوع خالی بندی با پشتوانه و خالی بندی بدون پشتوانه (اینکه اصلا می توانی آنکار را انجام دهی یا نمی توانی) تازه در این شرایط به خودمان هم دروغگو و شارلاتان هم نمی گوییم!
از شوخی که بگذریم، نگاهی بیاندازیم به مساله تولید و فروش نرم افزار:
حالت کلاسیک:
در شرکتهای Package ساز، روال آن بود که یک بسته نرم افزاری به صورت عمومی آماده می شد (فرآیند تولید) پس از وارسی در شرکت عرضه کننده ( Alfa Test) در چند مشتری اول تست بتا (Beta Test) را انجام داده و پس از انجام اصلاحات بدون اینکه دیگر به آن دستی زده شود تا نسخه بعدی همان سیستم به فروش می رفت. در هنگام فرآیند فروش هم تولید روی ایجاد نسخه های جدید و سرویس پک های بعدی نرم افزار کار می کرد. به عبارت ساده تر تولید قبل از فروش
در شرکت های پروژه محور، روال کار برعکس است، شرکت بر اساس توانمندی و یا سوابق قبلی یا هر پارامتر تعیین کننده دیگر، قراردادی را بایک شخص حقیقی و یا حقوقی  منعقد کرده (فرآیند فروش) و پس از آن برای ایجاد آن نرم افزار مهلتی خواسته و تولیدی را آغاز می کنند تا محصول پروژه (Product) آماده شده و پس از طی مراحل مختلف به کارفرما تحویل و پروژه خاتمه یابد و پروژه بعدی آغاز شود، به عبارت ساده تر فروش قبل از تولید.

حالت امروزی:
اما در حالت نوین و شرکتهای امروزی، دیگر نمی شود به سادگی این تفکیک را انجام داد. نمی توان یک شرکت را Package ساز صرف و دیگر را پروژه محور خالص دانست. کسانی که پروژه کار می کنند به دلیل هزینه های بالایی تولید مایلند و به این چرخه وارد می شوند که محصول پروژه را به مشتری دیگری نیز بفروشند که همان سیاست Packe فروشی است. از سوی دیگر همانطور که قبلا در نوشته های دیگر به اشکال مختلف به آن اشاره کرده ام، هر مشتری حتی در شرکت Package ساز به دلیل نیاز به منطبق سازی (که در تجارت امروزی میان مشتریان یک امر طبیعی شمرده می شود و مشتری حاضر نیست نرم افزاری را بخرد که نتواند تغییر دهد) چیزهایی می خواهد که در اکثر مواقع یک فاز تولید را هر چند کوچک به سیستم تحمیل می کند. این مساله باعث می شود که در شرکتهای Package ساز در میان تیم تولید یک نوع سردرگمی و یا همان بحث تولید تحت فشار رخ دهد و میان اجرای پروژه های کوچک مختلف برای چند مشتری در یک زمان و تولید نسخه جدید اختلال ایجاد شود و از این مساله در مرحله اول تولید و در مرحله بعدی کل شرکت آسیب ببیند.
چرا؟
- اجرای چند پروژه با محدوده زمانی کم در یک زمان مدیریت پروژه متفاوتی از مدیریت یک پروژه بلند مدت دارد.
-این تولید چون پس از فروش همراه می شود، مشتری را پشت در سازمان می بیند، مشتری خواسته های عجیب و غریب مطرح می کند و به دلیل آنکه همه یا بخشی از پول را پرداخته است، توقع دارد که یکشبه دریافت کند که نمی شود.
-فرآیند توسعه و متدولوژی در پیش گرفته برای این نوع تولید با یک تولید کلاسیک متفاوت است، شاید در تولید یک بسته نرم افزاری بتوان فرآیند خطی، آبشاری و یا حتی توسعه تدریجی و یا مارپیچی را انتخاب نمود، اما به دلیل کمرنگ بودن و کند بودن ذاتی این فرآیند ها در ارتباط با مشتری برای منطبق سازی بسته نرم افزاری، باید به سراغ متدولوژی هایی با تعامل بالاتر مانند توسعه سریع نرم افزار (RAD) و یا روشهای چابک (Agile) مانند XP رفت.
- شتاب و تعدد این پروژه های کوچک، به تدریج تیم تولید را فرسوده می کند و تمرکز آنها از دست می رود بنابراین به تدریج بهره وری آنها در تولید پایین می یابد.
- به دلیل اینکه درآمد حاصل از منطبق سازی معمولا چندان بالا نیست، مدیران شرکتها و مدیران مالی اهمیت زیادی برای آنها قائل نیستند و این بی انگیزگی به واحد تولید نیز منتقل می شود.
-...

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

Ali Vahed | 9:34 AM

خدمات پشتیبانی محصولات نرم افزاری، قسمت چهارم، مشتری مطلقا راضی، مشتری نسبتا راضی

July 8, 2008 9:39 AM

در ادامه قسمت های 1و2و3 سلسه مطالب خدمات پشتیبانی محصولات نرم افزاری، در این نوشته طبقه بندی مشتریان در گروه های ناراضی و راضی بررسی می شود. دقت شود در این نوشتار رضایت و یا نارضایتی مشتری از "محصول" مورد نظر قرار می گیرد و نه خدمات و نحوه برخورد شرکت فروشنده در این زمینه.


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


همین!

Ali Vahed | 9:39 AM

وب یا ویندوز... جمع بندی نهایی

April 19, 2008 9:11 AM

سه نوشته قبلی را اگر دنبال کرده باشید بحث انتخاب برنامه سازی تحت وب و یا برنامه سازی تحت ویندوز را دنبال کرده بودیم، در آخرین مطلب، یک جمع بندی بر بحث صورت می گیرد. دقت کنید که چنانچه در نوشته اول هم اشاره کردم برخی تولید کننده ها و یا مشتری ها بعضا در یک حالت "جو گیر شده"! از روی ناآگاهی و یا به شکل احساسی روی یک محیط تعصب به خرج می دهند و  دیگری را به صورت کامل نفی می کنند، در حالیکه نمی توان هر کدام از این دو را به شکل کامل از رده خارج نمود، شاهد آنکه محیط های توسعه و ابزارهای برنامه سازی روی هر دو محیط هنوز هم در نسخه های جدید عرضه می شود و خواهد شد.
اگر بخواهیم در محیط های اداری انتخاب مناسبی داشته باشیم، به نظر می رسد باید به ملاک های زیر توجه کنیم:
- در محیط های با هدف تبادل اطلاعات نظیر سیستمهای اتوماسیون اداری، کارگروهی، مدیریت جریان کار، بولتن های الکترونیک و .... که نیاز به توزیع شدن روی بیشتر کامپیوتر ها را دارند و بیشتر به پردازش و به اشتراک گذاری متون و فایل ها می پردازند، برنامه های تحت وب روی شبکه اینترانت بهترین گزینه اند.
- در مسائلی که کاربر محدود به یک محدوده جغرافیایی خاص نیست و یا به صورت عام متقاضی اطلاعات و سرویس هستند برای مثال در سیستمهای تجارت الکترونیک، شهر الکترونیک، دولت الکترونیک، بانک الکترونیک و ... که خدمات و سرویسهای عام المنفعه ارائه می کنند و مشتری می تواند کاربر نهایی (End User) نیز باشد، برنامه های تحت وب روی شبکه اینترنت مناسب هستند.
- در مسائل کاربردی که نیاز به پردازش اطلاعات، تعامل زیاد کاربران با نرم افزار و امکانات مناسب و سرعت قابل قبول روی نرم افزارهستیم مانند نرم افزارهای پردازش تراکنش (TPS) و یا سیستمهای دانش فنی (KWS) سیستمهای تحت ویندوز (و یا به صورت کلی هر نوع Desktop Application) مناسب تر هستند.
- در مسائلی که دو وجه از مسائل فوق را داشته باشند، اگر مسائلی نظیر هزینه تولید و سختی کار را در نظر نگیریم  (که آنقدر مهم است که باید دیده شود) ترکیبی از این دو جواب گو است (win-web). برای مثال در یک سیستم مالی می توان اسناد را به صورت تحت ویندوز پیاده سازی کرد تا کاربران به سهولت اسناد را صادر و یا ثبت کنند و گزارشات مدیریتی را به صورت تحت وب در آورد تا مدیران بتوانند به گزارش مورد نیاز خود در داخل و یا خارج از سازمان به سهولت دسترسی پیدا کنند.
-...

طبیعتا در محیط های خانگی، دانشگاهی و یا .... نیز با توجه به کاربرد باید انتخاب مناسب را انجام داد.
نکته حائز اهمیت آنکه داشتن دو شکل برنامه سازی به صورت تحت وب و تحت ویندوز برای یک شرکت نرم افزاری کوچک و یا متوسط سخت است. این دشواری از تفاوت روش تفکر و تولید در هر دو روش، عدم توانایی استفاده از همه تیم در همه زمانها و آموزش توام دو روش می آید. راه حل آن است که :
- یک تیم قوی داشته باشید که توانایی پیاده سازی در هر دو محیط را داشته باشند. (سخت است، چون یک نفر فرصت کافی در کسب مهارت را در هر دو زمینه ندارد و نهایتا در مورد یکی قوی و در مورد دیگر متوسط خواهد شد)
- یک معماری لایه ای انتخاب کنید با تنوع برنامه نویسانی که 1- لایه های پایینی (داده و کاربرد) را بسازند، 2- لایه واسط کاربری را در محیط تحت ویندوز بسازند و 3- لایه واسط کاربری در محیط تحت وب را بسازند. (به دلیل مشترک دیدن لایه های پایین هر چند کم هزینه ترین روش است اما برنامه آن کارایی برنامه های مستقل را نخواهد داشت)
-دو گروه برنامه نویس جدا داشته باشید که هر یک در یک محیط کار کنند. در نهایت در پروژه های ترکیبی (win-web) تنها پایگاه داده را مشترک کنید و هر کس برنامه خود را بنویسد (هزینه تولید بالا می رود و مدیریت چنین تیمی و تقسیم زمان کار و بیکاری آنان مشکل می شود)
- بی خیال یکی از روشها بشوید! یا بگویید نمی توانم و یا از طریق برونسپاری (Out sourcing) عمل کنید. (که طبعات خاص خود را خواهد داشت)

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

Ali Vahed | 9:11 AM

تحت وب

April 17, 2008 3:28 PM

در اين نوشته برخي مشخصات عمومي برنامه هاي تحت وب (web based applications) بررسي مي گردد. دقت کنيد در اين نوشته ما دنبال برنامه هاي کاربردي هستيم که در محيط web و بر مبناي پروتکل هاي آن پياده سازي شده اند. بنابراين اين برنامه ها را از مفهوم web site مجزا سازيد. ممکن است ما يک وب سايت خيلي خوب داشته باشيم اما برنامه تحت وب خوب روي آن موجود نباشد. نکته ديگر آنکه بستر اجراي برنامه هاي تحت وب مي تواند متفاوت باشد، روش شبکه اينترنت براي کاربردهاي عمومي و يا توزيع شده، روي شبکه اينترانت يا اکسترانت براي کاربردهاي درون سازماني و يا برون سازماني. بنابراين در برخي بخشها و مزايا و معايب، اين خود برنامه نيست که مسبب اصلي است، بلکه اين بستر استفاده است که يا يک محدوديت و يا يک مزيت را براي ما به ارمغان مي آورد.
 - مشخصات کلي:
برنامه هاي تحت وب معمولا برنامه هاي هستند که در بيش از سه لايه پياده سازي شده و اصطلاحا در گروه (Multi Layer applications ) قرار مي گيرند. در اين برنامه ها حداقل سه لايه واسط کاربري (User Interface Layer) که مي تواند روي يک کامپيوتر بسيار سبک اجرا شود (thin client) و توسط نرم افزارهايي استاندارد استفاده شود (مرورگرها يا Browsers) ، يک لايه کاربردي Bussiness Layer که روي يک application server اجرا شده است و يک لايه داده Data Layer که روي يک Data server وجود دارد اجرا مي شوند. (دقت کنيد به لحاظ سخت افزاري لزومي به سه تا ديدن آن نيست.) اين برنامه ها با بهره گيري از پروتکل هاي وب و TCP/IP با يکديگر به مبادله اطلاعات مي پردازند.

-مزايا:
صرف نظر از يک نرم افزار خاص و به صورت عمومي براي برنامه هاي تحت وب مزاياي زير متصور است:
-يکپارچگي با محيط هاي جديد کاربري که کاربران را قادر مي سازد از طريق يک مرورگر مشخص هم به داده ها و اطلاعات و هم به برنامه ها و کاربردها تواما دسترسي داشته باشند.
-توزيع شدگي: در صورت اجراي اين برنامه ها روي شبکه اينترنت، کاربران مي توانند بدون محدوديت جغرافيايي و مکاني مشخص و صرفا با داشتن يک نشاني يا آدرس خاص، به سيستم متصل شده، در صورت نياز پس از تعيين سطوح دسترسي از امکانات اين سيستم ها استفاده نمايند.
- پشتيباني سهل تر: چون روي کامپيوتر هاي Client نرم افزار خاصي نصب نمي شود، به سادگي و با به هنگام کردن برنامه يا داده روي سرور ، مي توان از اينکه کاربران به آخرين داده يا برنامه دسترسي دارند مطمئن شد.
-نگاه متفاوت در طراحي واسط کاربري: به لحاظ حضور استانداردها يا تکنيک هايي نظير ابر متن (Hyper Link) ، XML، Ajax ، Comet و ... نگاه ديگري به انجام يک کاربرد مي شود که معمولا به سليقه کاربران جديد نزديک تر است. مخصوصا در محيط هاي پرتال (Portal servers) نگاه و معماري مبتني بر سرويس (Service Oriented) مي تواند جالب توجه باشد.
-عدم نياز به سخت افزار قوي و يا سيستم عامل خاص در سطح Client ها: همانگونه که اشاره شد به لحاظ تقسيم شدن پردازش در سطح Client و Server تنها بخش کوچکي در روي کامپيوتر هاي Clent اجرا مي شود (Clent Side) که بيشتر جنبه نمايشي و تنظيم واسط کاربري دارد و پردازش هاي اصلي که مرتبط با کار با داده و انجام پرس و جو ها را دارند بيشتر روي سرور (Server Side) صورت مي گيرد.
-...
- معايب:
- ساختار کند تر: به دو دلیل نرم افزار های تحت وب، نسبت به برنامه های تحت ویندوز کند تر هستند، یک دلیل آن نقش بازی کردن پهنای باند و سرعت تبادل اطلاعات روی شبکه است که با انتقال برنامه از محیط اینترنت به اینترانت و یا استفاده از اینترنت پرسرعت، می توان تا حدودی این مشکل را برطرف نمود. اما بحث دوم که خاصیت برنامه های تحت وب است، معماری Push و Pop رایج است که به دلیل ارسال مداوم درخواست ها از سمت Client به Server و Refresh شدن صفحات بر اثر دریافت پاسخ رخ می دهد. این مساله باعث می شود، در هر بار بازخوانی صفحه بخشی اطلاعات غیر ضروری مبادله شود و یا اینکه برای هر کاری نیاز به درخواست خاص خود و طرح آن با سرور باشد. در سمت Client در این سیستم ها معمولا به دلیل محدودیت Script ها تنها بخشی از عملیات نمایشی و تنظیمات صورت می گیرد. امروزه تلاش شده است با استفاده از تکنولوژی هایی نظیر Ajax همه صفحه بازخوانی نشود و صرفا آن دسته از اطلاعات مورد نیاز از سرور بارگذاری شود و یا از Comet برای ارسال خودکار اطلاعات بدون طرح تقاضای بازخوانی صریح از سمت Client برای رفع این نقص استفاده شود که هم هنوز به دلیل عدم پختگی کامل و وجود ابزارهای مناسب (هر چند این روزها مولفه های زیادی به صورت فروشی و یا متن باز در این زمینه وجود دارد) و هم به دلیل دانش برنامه نویسان قدیمی تر، استفاده محدود تر و پرهزینه تری دارند.
- نگاه ويژه به امنيت : در برنامه های تحت وب، شما باید نگاه ویژه تری به امنیت داشته باشید. اغلب مشاهده کرده ام که Data Layer و Application Layer روی یک سرور نه چندان مطمئن روی اینترنت و یا اینترانت قرار می گیرد که این مساله باعث می شود ریسک امنیتی و خطر حملات و نفوذها بیشتر شود. در وب باید بیشتر از ویندوز توجه نشان داد به این مساله، چون در تحت ویندوز، خود حضور یک برنامه خاص روی Client که می تواند صرفا درخواست های مجاز و محدود را به سمت سرور ارسال نماید بخشی از ریسکهای امنیتی ما را کاهش می دهد.
- سرور گران قيمت : چون اکثر حجم پردازش در سرور صورت می گیرد استفاده از سرورهای پرقدرت برای اینگونه برنامه ها پیشنهاد می شود. در برخی موارد که حجم تراکنش ها بالاست رعایت مواردی نظیر Load Balancing و توزیع کاربردها روی سرورهای مختلف، حائز اهمیت بوده که باعث می شود هم تهیه و هم نگهداری از اینگونه سرورها، مهم تر باشد.
- عدم توانايي کامل در ايجاد محيط هاي تعاملي : به لحاظ اینکه هنوز ابزارها و مولفه های واسط کاربری تحت وب برای کارکردن مداوم یک کاربر روی نرم افزار مناسب نیست. کاربرانی که به عملیات ورود اطلاعات و یا صدور و ثبت اسناد زیاد و حجیم در سیستم مشغول هستند معمولا نیاز به ابزارها، میانبرها و امکاناتی هستند که بتوانند به درخواست های خود بسیار سریع دسترسی پیدا کنند. در برنامه های تحت وب، پیشتر این امکان غیر ممکن بود اما این روزها، تلاشهای خوبی هم در سطح تولید ابزارهای مناسب و هم در سطح تغییر نگرش به یک کاربرد از Function به Service صورت گرفته است که هنوز به شکل کامل توسط برنامه نویسان ایرانی مورد استفاده قرار نگرفته است.
-نصب و راه اندازي دشوار تر : به لحاظ اینکه باید شما در روی سرور محیط و بستر مناسب برای اجرای یک برنامه تحت وب را آماده کنید، این کار سخت تر از زمانی است که شما یک برنامه تحت ویندوز را نصب می کنید. در اکثر برنامه های تحت ویندوز شما با یک برنامه Installation طرف هستید که یا به صورت کامل و یا به صورت حداکثری عملیات نصب و تنظیم برنامه را انجام می دهند در سمت سرور هم شما کافی است یک DBMS (سیستم مدیریت پایگاه داده) نصب کرده و بانک اطلاعات خود را بارگذاری نمایید. در برنامه های تحت وب جدید تر که مبتنی بر یک CMS یا یک Portal Server هستند، وجود ابزارهای گام به گام wizards برای تنظیم برنامه و پایگاه داده کمک خوبی است، اما کامل نیست.
-...

دقت کنید، همانطور که پیشتر گفته ام مواردی که در مزایا و یا معایب برنامه های تحت وب و یا تحت ویندوز ذکر شد، مواردی است که در اینگونه برنامه ها به صورت عمومی یافت می شود و گرنه نمونه هایی وجود دارد که بر اثر تلاش و هزینه برنامه نویسی و یا استفاده یا عدم استفاده از تکنولوژی های خوب، بهتر یا بدتر از اینگونه برنامه ها باشند. علاوه بر این رشد و توسعه محیط ها، ابزارها، استانداردها و تکنولوژی هایی نظیر NET Framework. ، یا Ajax و یا J2EE باعث غنای بهتر و یا استفاده مناسب تر هم برنامه های تحت ویندوز و هم برنامه های تحت وب شده است.
در پست بعد تلاش می کنم یک جمع بندی بر این مبحث داشته باشم.
همین!

Ali Vahed | 3:28 PM

تحت ویندوز

April 14, 2008 2:58 PM

نوشته قبلی بازخوردهای خوبی داشت، از Comment هایی که دوستان، نظرات خود را به درستی مطرح کرده بودند تا نوشته فراسان که با یک نگاه کارشناسی به این سوال پرداخته بود. برای اینکه بتوانم با کمک نظرات داده شده و داشته های خودم یک جمع بندی برای این پرسش داشته باشم در دو بخش به معرفی قابلیت ها و محدودیت ها و در نتیجه کاربردهای این دو محیط می پردازم تا در نهایت بتوانیم یک ارزیابی کامل نسبت به این دو داشته باشیم. در نوشته اول به برنامه های تحت ویندوز  (windows based application) و یا به طور کلی Desktop application ها خواهم پرداخت:
-مشخصات کلی:
نرم افزارهای این گروه یا به صورت تک کاربره (Single) و یا به صورت شبکه ای (معمولا به صورت Client/Server) فعال هستند که در گروه اول، همه اطلاعات و برنامه پردازشی روی یک دستگاه و در مدل دوم برنامه اجرای مجزا از بانک اطلاعاتی روی دستگاه های کاربری و بانک اطلاعات روی یک کامپیوتر سرور قرارگرفته است.

-مزایا:
به طور کلی مزایای عمومی این گروه از برنامه ها را صرف نظر از مزایا و یا معایب خاص یک نرم افزار در قیاس در مقابل برنامه های تحت وب می توان چنین برشمرد:
- رابط کاری قوی تر: در این نرم افزارها مجموعه ای توانمند از مولفه های نرم افزاری (Component) ها در سطح واسط کاربری وجود دارند که یک GUI قوی و با امکانات برای نرم افزار پدید می آورند و کاربر استفاده کننده معمولا به سادگی با بهره گیری از صفحه کلید و موس می تواند از همه صفحه نمایش استفاده مؤثر داشته و به نیازهای خود بپردازد.
-سرعت در پردازش اطلاعات: به لحاظ حضور در یک کامپیوتر و یا در یک شبکه محلی (Lan) معمولا ترافیک شبکه گلوگاه سیستم بشمار نرفته و درخواست ها همیشه در یک زمان قابل پیش بینی پاسخ داده می شوند.
- امنیت: به لحاظ استقلال سیستم از دنیای خارج و نیز پردازش دستور ها در سطح برنامه در Clent و پاسخگویی به پرس و جو ها (query) در server امنیت این سیستم ها ساده تر تامین می شود.
- نزدیکی به کار کاربران عادی: کاربران عادی در سازمانها معمولا کمتر با محیط اینترنت به عنوان یک محیط عملیاتی آشنا هستند و بیشتر با اینگونه نرم افزار ها چه در سطح سیستم عامل و چه در سطح نرم افزارهای امور اداری (نظیر Office) کار کرده اند و با این نرم افزارها راحت تر آموزش خواهند دید.
- پیاده سازی روانتر: به دلیل پختگی ابزارهای پیاده سازی تحت ویندوز (Win 32 or .NET) سرعت و روانی فرآیند تولید و خطایابی نرم افزار در این سیستمها ساده تر صورت می گیرد.
-ابزارهای گزارش گیری مناسب: معمولا ابزارهای گزارش گیری چه به صورت ایستا و چه به صورت پویا در سطح برنامه های تحت ویندوز بیشتر در دسترس بوده و قوی تر می باشند.(به جز ابزارهای مشترکی که در هر دو بخش وجود دارد) لذا استفاده از آنها در برنامه ها رایج تر بوده، گزارشات اینگونه سیستم ها معمولا قوی تر و پویا تر می باشند.
-استفاده مؤثر از امکانات سخت افزاری: به دلیل حضور برنامه روی Client و بانک اطلاعات روی Server ، از پهنای باند شبکه برای انتقال اطلاعات (برای مثال فرمها، آیکون ها و تصاویر و ...) از سرور به cleint استفاده نمی شود و از همه قابلیت های پردازشی Client ها استفاده می شود. و نیازی به قدرت زیاد server نمی باشد و بسته به تعداد Clent ها و حجم Transaction ها می توان از کامپیوترهای ارزان قیمت تر برای Server استفاده نمود.
-...

- معایب: معایب عمومی این مدل برنامه سازی را می توان در موارد زیر جمع بندی نمود:
- پشتیبانی دشوار تر: به دلیل وجود برنامه EXE روی Client های مختلف، در صورت ارتقاء نرم افزار و یا رفع خطا، شما باید از تغییر همه فایل های اجرایی مطمئن شوید.
-محدودیت جغرافیایی : به لحاظ استفاده از شبکه های محلی (LAN ) به عنوان بستر فعالیت نرم افزار، کاربران نمی توانند به صورت توزیع شده و یا از راه دور در محل دلخواه به سیستم متصل شده و از آن استفاده کنند. (برنامه های معدودی که از طریق سرویس های RAS امکان کار از راه دور مثلا از طریق اتصال با خطوط تلفن (نظیر برنامه های BBS) در این قسمت نادیده گرفته شده اند، چون هم از لحاظ تنوع و هم از لحاظ حجم استفاده امروزه در اقلیت به سر می برند.)
- توزیع نشدگی: معمولا این سیستم ها به صورت مرکزی Central بوده و چنانچه در یک سازمان در چند مرکز نیاز به استفاده باشد، باید اتصال از طریق خطوط اختصاصی (نظیر روشهای بیسیم Point-to-Point و یا خطوط استیجاری leased Line و یا به صورت Dial Up و یا نهایتا VPN) حداکثر در سطح بانکهای اطلاعاتی هماهنگ سازی صورت گیرد (Replication)
-محدودیت Client ها: کامپیوترهای کاربران در این سیستمها باید در حد قابل قبولی باشد و از لحاظ سیستم عاملی نیز محدود به سیستم عامل خاصی نظیر windows باشد و کاربران نمی توانند از سیستم عامل های دیگر نظیر Linux و یا Mac OS استفاده کنند و یا به صورت موبایل (GPRS) از سیستم استفاده نمایند.
-دور بودن از روشهای جدید: معمولا کاربران جدید و جوان بر خلاف کاربران قدیمی تر با فضای اینترنت آشنایی بیشتری دارند و استفاده از نرم افزارهای تحت ویندوز برایشان دلچسب نیست.

مورد استفاده: به نظر می رسد اینگونه سیستمها برای کاربردهای زیر مناسب تر باشند:
- کاربردهای خانگی تک کاربره: نظیر برنامه های کاربردی ساده (Office) ، بازی های گرافیکی قوی، ابزارهای مولتی مدیا، و نرم افزارهای فنی و مهندسی
- کاربردهای اداری محدود در سطح یک شبکه محلی
- کاربردهای نیازمند به ابزارهای ورود اطلاعات و یا گزارش گیری مناسب
- نرم افزارهای با پردازش اطلاعات زیاد و حجیم
- نرم افزارهای تعاملی (Interactive) که حجم بالایی از تعامل را با کاربر دارند و نیاز به یک واسط کاربری (User Interface) قوی تر دارند.

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

در مطلب بعد به برنامه های تحت وب خواهم پرداخت. اگر در فهرست های بالا نقصی دیدید مرا مطلع کنید، لطفا!
همین!

Ali Vahed | 2:58 PM

وب یا ویندوز، مساله این است!

April 5, 2008 10:57 AM

این روزها سوالی که اغلب مشتری از ما کامپیوتری ها می پرسند و یا در جمع های تخصصی در مورد آن بحث می کنیم، آن است که برنامه ها باید در چه محیطی ساخته شوند؟ به شکل Desktop Application  و در محیط ویندوز (Windows Based )  ویا بر روی بستر اینترنت و یا اينترانت (Web based Application).  اکثر مشتری ها در یک حرکت غیر منطقی و جو زده ترجیح می دهند به سمت برنامه های تحت وب بروند و تولید کنندگان هم به همین دلیل، سبک کار خود را بر اساس این نیاز قرارداده اند از سوی دیگر ماهیت خیلی از مسائل پیرامون الزاما، یا ترجیحا باید به صورت تحت ویندوز باشد. داستانی که تمامی ندارد: Trade Off
نظر شما در این زمینه چیست؟ تلاش می کنم در چند نوشته دیدگاه خودم  را در مورد این قضیه تشریح کنم بدون آنکه قصد رسیدن به یک نتیجه قطعی را داشته باشم که می دانیم چنین نتیجه ای وجود ندارد...
همین!

Ali Vahed | 10:57 AM

مدیریت پروژه

March 10, 2008 11:20 AM

"پروژه بخشی اساسی از تاریخ بشریت است." این جمله ای است که کتاب "Improving Your Project Managment Skills"  نوشته Larry Richman با آن آغاز می شود. پس از خواندن این جمله فکر می کنم هر کس حداقل یک بار تجربه شرکت در پروژه یا به عنوان عضو تیم و یا به عنوان مدیر پروژه شرکت کرده باشد، حداقل چند دقیقه ای به فکر فرو برود.اینکه چقدر در ساختن تاریخ مشارکت داشته است.
در ادامه این کتاب ذکری کرده است از پروژه های بزرگ تاریخ مانند ساختن اهرام مصر، دیوار چین و .... که ساخت برخی حتی 1000 سال طول کشیده است و هنوز هم پابرجایند. تا به حال به این آثار به عنوان یک "پروژه" نگاه نکرده بودم. وقتی آن را یک پروژه دیدم، متوجه شدم نه تنها طراحی و ساخت آنها کاری پیچیده بوده است، بلکه فرآیند مدیریت پروژه آنها نیز بسیار دشوار بوده است. منابع محدود، زمان طولانی، سلایق متفاوت امپراطور ها و یا حاکمانی که در طی پروژه زیسته اند، توانایی پرسنل و اجرای کار گروهی، زمان پایان محدود و .... که هر یک کار مدیر یا مدیران پروژه را بسیار سخت کرده است.
این روزها هر کس حتی یک پروژه کوچک یک ماهه را تولید کرده باشد، خود را مدیر پروژه می خواند، خواه در تولید نرم افزار باشد، خواه در صنایع، خواه در ساخت و ساز.... اگر ما مدیر پروژه هستیم، آنهاییکه در تاریخ چنین پروژه های عظیمی را ایجاد کرده اند، آنانی که این روزها، پروژه های بین المللی و جهانی را مدیریت می کنند، کیستند؟
پیشتر در مورد فرآیند مدیریت پروژه، مباحثی را جسته و گریخته مطرح کرده ام. تلاش می کنم در آینده منسجم تر و در قالبی چند قسمتی به برخی مشخصات، وظایف، ابزارها و تجربه های تلخ و شیرین برای کسی که فکر می کرده مدیریت پروژه را بلد است و حال می داند که هیچ نمی داند، صحبت کنم. شاید خودم بیش از همه یاد بگیرم...
همین!

Ali Vahed | 11:20 AM

نقش مشتری

February 16, 2008 11:27 PM

یکی از نقش های مهم در طراحی نرم افزارها، نقش مشتری (Customer Role) است. این نقش علی الخصوص در روشهای توسعه تدریجی (Incremental Methods) و روشهای چابک (Agile Methods) مانند برنامه نویسی کرانه ای (XP: Extreme Programming)  پررنگ تر و برجسته تر است. بازیگر نقش مشتری موظف است که در غیاب مشتری، نقش وی را به عهده داشته باشد و از دیدگاه وی به مساله فکر کرده، نیازها را به گروه طراحی و پیاده سازی مشتری منتقل کند
اغلب دیده ام در پروژه هایی که مشتری حضور فعال و مستمری ندارد و یا مدیر پروژه، برای این نقش پیش بینی نکرده باشد، محصول نهایی پروژه با نیاز مشتری انطباق نداشته و حجم تغییرات بعد از تحویل زیاد خواهد بود.این مساله حتی ممکن است به شکست پروژه و یا عدم استفاده از نرم افزار نهایی منجر شود.
در پروژه های عام که قرار است یک Package برای گروهی از مشتریان مورد استفاده قرار گیرد، پیدا کردن یک یا چند فرد برای بازی کردن نقش مشتری بسیار مهم است. چون معمولا در این پروژه ها به دلیل عدم وجود مشتری واقعی، امکان انحراف از مبانی طراحی پروژه وجود دارد.
نقش مشتری را چه کسی می تواند بر عهده گیرد؟ به جز خود مشتری واقعی به نظر من، اشخاصی که با فرآیند تولید نرم افزار و فرآیند ها و محیطی که نرم افزار قراراست در آن استفاده شود به خوبی آشنا باشند، دقیق و نکته بین بوده و بتوانند نیازهای مشتریان واقعی را حدس بزنند و یا از روی تجربه و یا از روی مشاهده عملکرد مشتری واقعی تشخیص دهند اشخاص مناسبی هستند(لزومی به متخصص بودن در زمینه تولید نرم افزار برای این نقش وجود ندارد). در یک پروژه بسته به دامنه و ابعاد پروژه ممکن است که بیش از یک نفر نقش مشتری را بر عهده بگیرد و یا در طی فرآیند پروژه این نقش به اشخاص متفاوتی محول شود.
به نظر من یک مدیر پروژه خوب باید افراد مختلف را برای اعطای این نقش آزمایش نموده و یک یا چند فرد مناسب را بسته به دامنه پروژه انتخاب نماید. همچنین وی می تواند  در یک نظام گردشی اعضای مختلف تیم طراح و پیاده ساز خود را در این نقش قرار دهد تا آنها بتوانند نرم افزار را نه از نگاه تولید کننده بلکه از نگاه مصرف کننده مشاهده کرده و نقاط قوت و ضعف آن را دریابند. این مساله به آنها کمک خواهد کرد که در ادامه پروژه در نقش تحلیل گر، طراح یا توسعه دهنده، نرم افزار مناسب تری را پیاده سازی نمایند. 


همین!

Ali Vahed | 11:27 PM

100 اصل در تولید نرم افزار

January 8, 2008 10:01 AM

نوشته "100 اصل در تولید و توسعه نرم افزار" را در ایتنا بخوانید، تجربیات و نکات مهم از دید یک «مدیر نرم افزار»  است و خواندنی.


همین!

Ali Vahed | 10:01 AM

توليد تحت فشار

December 17, 2007 9:32 PM

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

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

Ali Vahed | 9:32 PM

هر مشتري، يک پروژه جديد

December 6, 2007 9:23 AM

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

اگر بخواهم نگاه دقیق تري به مساله اختصاصي سازي نرم افزار داشته باشم بايد مروري بکنیم بر سير تحول توليد محصول نرم افزاري:
- در دوره هاي اول به دليل نيازهاي کم و رشد نيافته بودن تکنيک هاي مهندسي نرم افزار، هر مساله يک پروژه جديد بود و حجم فروش دوباره محصولات بسيار پايين بود.
- با رشد نيازها و وضع تکنيک ها، روشها و فرآيند هاي توسعه نرم افزار، مساله توليد يک بار، فروش چند بار از طريق ساخت بسته هاي نرم افزاري (Software Packages ) عام رواح پيدا کرد و توليد کنندگان، مصرفکننده را ملزم به استفاده از همان محصول ثابت مي کردند. مشتريان هم به دليل عدم تنوع در انتخاب ناچار به پذيرش اين واقعيت بودند.
- با بلوغ تکنيک هاي توسعه نرم افزار و افزايش سطح توقعات مشتريان، ديگر نمي شد محصول را بدون منطبق سازي مطرح کرد، اما تلاش مي شد اين منطبق سازي در حجم کم و يا در قالب نسخه هاي بعدي (Next Version ) حل و فصل شود.
در اين دوره با ساخت سيستمهايي نظير ERP تلاش شد همه فرآيند هاي سازمانها استاندارد و پياده سازي گردد تا يک محصول يا بخشي از آن بتواند نياز يک مشتري جديد را برآورده سازد، اما باز هم بحث Tailoring را براي منطبق سازي محدود سيستم با نياز هاي مشتري مطرح است و رايج. چنانچه مي بينيم متدولوژي هاي تحليل و طراحي سيستمها نيز به سمت روشهاي قابل انعطاف تري مانند متدولوژي هاي چابک (Agile) مانند روش برنامه سازي کرانه اي (XP) حرکت کرده اند که پذيرش تغيير از جانب مشتري را به عنوان يک اصل مي شناسند.

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

Ali Vahed | 9:23 AM

آنچه یافت می نشود آنم آرزوست، یا، کمبود ایده و تنوع در بازار محصولات نرم افزاری کشور

November 1, 2007 3:38 PM

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


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

به نظر من عدم وجود تنوع در میان محصولات و خدمات شرکت های نرم افزاری را می توانم در این موارد خلاصه کنم:
1- تقاضا برای محصولاتی مثل سیستمهای مالی/اداری و یا وب سایت و پرتال بالاست و طبیعی است شرکتها هم با توجه به این تقاضا جلو می روند.
2- کارکردن در زمینه های دیگرنیاز به سرمایه گذاری دارد که از عهده شرکتها خارج است. طرح هایی مانند تکفا نیز به دلیل ضعف در اجرا نتوانست این سرمایه را برای همه به شکل عادلانه فراهم کند و تنها در مواردی خاص و شاید نه چندان کامل مؤثر کمکی کرده اند.
3- تقاضا میان سایر فعالیت ها و زمینه های کاری وجود دارد، اما چون گروه متقاضی یا پول کافی ندارند و یا مجوز پرداخت آن را ندارند، نمی توانند هزینه واقعی آن تقاضا را بپردازند بنابراین شرکتهای بزرگ و پرهزینه، سراغ آن کار ها نمی روند و حداکثر گروهی از شرکتهای کوچک، آنهم به دلیل عدم توانایی کار دیگر سراغ آن می روند.
4- عدم وجود قوانین رعایت حقوق مؤلف (Copy Right) که باعث می شود شرکتها بسیاری از نرم افزار ها را در کشور نخرند، بلکه از نسخه های قفل شکسته و یا تکثیر شده استفاده کنند. نگاه کنید به اینکه همه از انواع سیستم عاملها، نرم افزارهای کاربردی مانند Microsoft Office ، نرم افزارهای سرور، مدیریت شبکه، سیستمهای بانک اطلاعاتی، نرم افزارهای سودمند، مانند انواع فشرده سازها، آنتی ویروس ها، تکثیر CD، نرم افرارهای گرافیکی، بازی ها، نرم افزارهای پردازش صوت و تصویر، نرم افزارهای مهندسی در هر زمینه ای اعم از CAD/CAM گرفته تا ابزارهای CASE و .... استفاده می کنیم بدون آنکه پول واقعی آن را بپردازیم. آیا حاضریم ویندوز یا آفیس چند صد دلاری را بخریم و یا ترجیح می دهیم یک نسخه از آن را با قیمت یکی دو هزارتومان از یک مغازه رسمی بخریم و تا دلمان خواست از رویش کپی کنیم و نصب کنیم. مشخص است که اغلب دومی را انتخاب می کنیم. پس طبیعی است که تولید کننده داخلی هم سراغ این گونه محصولات نرود و حداکثر برخی تلاششان را در فارسی کردن آنها و یا شکستن قفل آنها بگذارند.
5- ضعف تولید کننده در پیدا کردن ایده جدید: به نظرمی رسد در کشور های پیشرفته وقتی کسی یک چیز را ساخت، بقیه آن را نمی سازند و سراغ ایده های خلاقانه دیگر می روند. اما در ایران شما کافیست یک چیز بسازید و آن چیز مورد استقبال واقع شود. ناگهان مواجه می شوید با حجم گسترده ای از تولید کننده ها که عین همان چیز را می سازند و با کیفیت و قیمت نازل تر از شما وارد بازار می کنند. چرا؟ چون از خودشان ایده ندارند و به خودشان زحمت بررسی وضعیت نیازهای بازار را نمی دهند. شما موقفید پس لابد آنها هم با ساخت آن چیز موفق می شوند، غافل از آنکه هم خودشان شکست می خورند چون ایده دست دوم دارند هم شما را با مشکل مواجه می کنند که بازاری که ساخته اید را خراب می کنند، هم مشتری را دچار سردرگمی می کنند که فرق اینها در چیست و چرا؟
6-ضعف دانشگاه ها در تربیت نیروی متخصص: می شود گفت ما در کشور نیروی متخصص "تربیت" نمی کنیم، "تولید" می کنیم. در گروه های آموزشی که وارد می شوی ، اغلب تعداد زیادی دانشجو می گیرند و با هر مدرسی کلاس را برگرار می کنند، انواع دانشگاه های دولتی، آزاد، غیر انتفاعی، نمایندگی خارجی، پیام نور، علمی کاربردی و .... به بدترین شکل فقط دانشجو را وارد می کنند و پس از مدتی خارج می کنند. اغلب پروژه های تکراری و مشابه انجام می شود و دانشجویان یک شکل می شوند. نگاه کنید به نوع پروژه های کارشناسی دانشجویان که اغلب جنبه پایگاه داده ای دارند و طبیعی است که دانشجوی فارغ التحصیل شده به دلیل داشتن اطلاعاتی در این زمینه، همین راه را در بازار کار ادامه می دهد.
7- عدم شناخت از سایر توانمندی های مهندسین نرم افزار، آنجا که همه آنها را برنامه نویس می دانند و برنامه نویسی را کار با پایگاه داده. این می شود که خودمان هم همین را باور می کنیم و تا به یک همکار می رسیم از وی چند سوال می پرسیم، با چه زبانی برنامه می نویسی، با کدام بانک اطلاعاتی آشنا هستی و .... این می شود که فرهنگ کارهای دیگر به خوبی جا نمی افتد.
....

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

Ali Vahed | 3:38 PM

از لاک لاک پشت تا دم مارمولک، یا چگونه از نرم افزاری که ساخته ایم محافظت کنیم؟

October 20, 2007 11:40 PM

یکی از مسائلی که تولید کنندگان نرم افزار در کشور با آن روبرو هستند آن است که به دلیل ضعف قوانین کپی رایت (حقوق مولف) باید خود راسا از نرم افزار خود مراقبت کنند و برای محافظت از آن چاره ای بیاندایشند.
بحث مراقبت از نرم افزار شامل اقداماتی است که از دستکاری و یا کپی برداری غیر قانونی در مقابل افراد مجاز و یا غیر مجاز جلوگیری می کند. به عبارت دیگر به این می پردازیم که:
- چگونه نرم افزار از اجزاء خود به صورت یکپارچه مراقبت نماید. (مبحث جامعیت (Integrity)  از عوامل کیفی نرم افزار)
- افراد غیر مجاز نتوانند به درون نرم افزار نفوذ کنند (مبحث امنیت (Security) نرم افزار)
- افراد مجاز قادر نباشند با اقدامات غیر مسؤولانه و یا ورود اطلاعات غلط، به بخشی از سیستم آسیب برسانند. (مبحث توانمندی و یا استحکام (Robustness) نرم افزار)
- نتوان نرم افزار را بدون اجازه مالک آن کپی کرد و از آن استفاده مجدد داشت (رعایت Copy Right نرم افزار)

سه مورد اول جزء طبیعاتی است که یک نرم افزار تجاری باید به آنها مجهز باشد (عواملی که یک سیستم تجاری را از یک سیستم دانشگاهی یا آزمایشی جدا می کنند) اما همانگونه که گفتم ، آخری به ضعف قانون و یا ضعف اجرای قانون رعایت حقوق مولف بر می گردد.
هر تولید کننده ای با توجه به نوع محصولی که تولید می کند، فنآوری مورد استفاده، دانش و تجربه و قیمت نرم افزار، روشی را برای مدیریت مراقبت از نرم افزار خود به عنوان یک سرمایه خود بکار می گیرد. از قفل های نرم افزاری گرفته، تا قفل های سخت افزاری، رمزگذاری فایل ها، مخفی سازی اطلاعات حساس، استفاده از بمب های منطقی (Logical Bomb) ، قفل گذاری روی CD ، استفاده از مبحث Licensing یا لیسانس نرم افزار، ثبت وقایع، تهیه مداوم نسخه های پشتیبان یا Mirror از اطلاعات و یا برنامه ها، انواع قفل های تلفنی ، اینترنتی، فایل های کد کلید ، توکارکردن نرم افزار ها در داخل سخت افزارها، کارتهای هوشمند، مدیریت کاربران قوی، تغییر دوره ای رمز عبور، مکانیسم های تشخیص اثر انگشت، انواع سیستمهای هشدار دهنده سرقت و نفوذ (Hack) و یا حمله (Attack) و .....
اینکه شما از کدام استفاده می کنید همانطور که گفتم به شما و نوع و قیمت محصولتان بسته است.
در این نوشته می خواهم شروع کننده نظریه ای باشم که شاید بتوان در آینده آن را تکمیل کرد و به عنوان یک روش در محافظت از نرم افزارها بکار گرفت. آن اینکه از روی حیات وحش الگو گرفت، اینکه جانوران مختلف از خود چگونه مراقبت می کنند و در مقابل دشمنان خود چگونه ایستادگی نشان می دهند، آن را الگو بگیریم و با توجه به نرم افزار و ماهیت آن (و شناسایی عوامل آسیب رسان به آن) ، نرم فزار در موقع خطر به همان شکل از خود واکنش نشان دهد. بگذارید مثالهای ذکر کنم:

-لاکپشت: یک لاک سخت دارد و چند جای سوراخ برای خروج دست و پا و سرش، هر وقت خطری احساس کند، داخل آن لاک می رود.(لاک پشت که دیده اید!؟) خوب ما هم ترم افزاری بسازیم که در موقع دسترسی غیر مجاز، کپی کردن غیر قانونی و یا احساس خطر برای آسیب، خود را در داخل یک لایه محافظ (بخوانید Firewall) مخفی کند و اجازه همه دسترسی ها را قطع کند تا شرایط به شکل عادی تبدیل شود. برای مثال نوع برخورد دستگاه های پرداخت پول (ATM) و یا وب سایت های امنیتی را مشاهده کنید. به محض احساس خطر، خود را از کار انداخته، ورودی ها و خروجی های سیستم را غیر فعال می کنند.
-خارپشت: که در هنگام خطر ، خارهای پشتش (برخلاف سطح شکمی ضعیف و قابل نفوذش) به دردش می خورد و آن را به سمت عامل خطر پرتاب می کند. استفاده از بمب های منطقی، ویروس های هدفمند و یا آسیب زدن به سیستم عامل و یا فایل های کاربر سرقت کننده اطلاعات ایده جدیدی نیست، به نظر شما شبیه خارپشت نیسند اینگونه نرم افزارها.
-راسو (؟) : جانور شناس نیستم، اما فکر می کنم یک نوع راسو یا چیز شبیه آن است که به محض دیدن خطر، بوی بدی از خود متصاعد می کند! نمی شود نرم افزاری ساخت که اگر غیر مجاز کپی شد و یا نفوذی در آن صورت گرفت چنین واکنشی نشان دهد (منظورم آن نیست که بوی بد بدهد!) برای مثال نسخه های Shareware نرم افزار ها را نگاه کنید، پس از مدتی آنقدر ضدحال می زنند که ترجیح می دهید یا از شرشان خلاص شوید و یا بخریدشان، آنقدر اعلان های مختلف، فرمهای مختلف، کند شدن سیستم و .... می دهند که شما مجبورید این روش را خاتمه دهید. یک کم غلیظش کنید، می شود همان راسوی قصه ما.
-مارمولک: مشهور است که مارمولک در هنگام خطر دم خود را قطع می کند و فرار می کند. مهاجم گول می خورد که به هدف رسیده است، غافل از آنکه آن دم تله است و سمی و با خوردن آن .... می شود نرم افزاری ساخت که دزد را گول بزند، مثلا اجازه بدهد از نسخه قفل شکسته استفاده کند و یا تا حدی دسترسی غیر مجاز را فراهم کند اما در پس زمینه مانند یک اسب تروا (Trojan Horse) کاری کند و سازنده را مطلع سازد و یا خرابکاری نماید.
....
زیاد است از این دست، شاید سعی کردم یک نوشته یا یک کتاب بنویسم در این مورد، اینکه چطور از دیدن برنامه های رازبقا در توسعه نرم افزار تاثیر بگیریم ...!
باز هم در این مورد -محافظت از نرم افزار- خواهم نوشت.
همین!

Ali Vahed | 11:40 PM

شباهت سریال های ماه رمضان با برخی پروژه های نرم افزاری!

October 16, 2007 10:59 PM

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

Ali Vahed | 10:59 PM

جشن "آزادی نرم ا فزار" یا "نرم افزار آزاد"؟

September 8, 2007 9:58 AM

در وبلاگی به نام روزنت خواندم که روز دوشنبه 19/6 ، روز" آزادی نرم افزار" است، که کاربران می توانند در آن روز روی کامپیوترشان لینوکس رایگان نصب کنند (بیشتر ...)، سوالی که برای خودم پیش آمد این بود که این روز، نامش روز "آزادی نرم افزار" است، یا روز "نرم افزار های متن باز" (Open Source)؟
امیدوارم در ترجمه به فارسی اشتباه نشده باشد، نمی دانم.


همین!

Ali Vahed | 9:58 AM

خدمات پشتيباني محصولات نرم افزاري، قسمت سوم، پشتيباني يا خدمات پس از فروش؟ مساله اين است!

September 3, 2007 10:03 AM

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

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

Ali Vahed | 10:03 AM

خدمات پشتیبانی محصول نرم افزاری، بخش دوم، واجب تر از نان شب!

September 2, 2007 9:52 AM

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

Ali Vahed | 9:52 AM

نرم ا فزار جهاني، نرم افزار ساز جهاني، طرح پرسش

August 18, 2007 12:21 PM

چند وقت پيش برنامه اي بود در تلويزيون در مورد نقد فيلم، مجري از کارگرداني که دعوت کرده بود يک سوال پرسيد که به نظر من سوال مهم و جالبي است، اينکه ما آيا فيلمساز جهاني داريم (که همه جهان آن را بشناسند)، مصاحبه شونده، نام چند فيلمساز هنري ايران را آورد مانند کيارستمي يا مخملباف، پرسيد آيا بازيگر جهاني داريم؟ پاسخ دهنده، پاسخ منفي بود، پرسيد آيا فيلم جهاني داريم؟ بازهم در پاسخ ماند و فيلمهايي را نام برد که مورد توجه تماشاچي خاص سينما هستند نه عام و آنهم عده کمي هستند، فيلمهايي مانند توليدات هاليود يا باليود با آن قشر تماشاچي عظيم و گسترده در تمام دنيا را ما نداريم، پرسش کننده پرسيد چرا؟ چرا هند سينماي جهاني دارد اما ما نداريم؟ پاسخ دهنده پاسخ داد: .............
به پاسخ وي و نتيجه بحث کاري ندارم که وبلاگم يک وبلاگ سينمايي نيست، هر چند بين تهيه کنندگي سينما و مديريت پروژه نرم افزاري ارتباط زيادي مي دانم که در آينده در مطلبي به آن خواهم پرداخت.
مي خواهم امروز پرسشهايي مطرح کنم از خودم و از خوانندگان وبلاگ که:
- آيا ما محصول نرم افزار جهاني داريم؟ چو داني و پرسي سؤالت خطاست، معلوم است که نه، نرم افزاري مانند windows, Acrobat Reader, Delphi, photoshop, FIFA, warcraft و ...را اغلب مي شناسيم، نرم افزارهاي ديگر خواه سيستم عامل باشند، خواه نرم افزارکاربردي، محيط هاي برنامه سازي، ابزارهاي گرافيکي و يا بازي نيز در اين دسته وجود دارند، حضور يک محصول ايراني در اين بين خالي است، مگر نه؟
- آيا ما نرم افزار سازان جهاني داريم؟ بازهم پاسخ منفي است، شرکتهاي مانند Microsoft , Adob,SUN ,Symantec, Macromedia,EA Sport  و .... محصولاتي جهاني مي سازند، اما من در بين توليد کنندگانمان نمي شناسم چنين شرکتي را، حداکثر شرکتهايي هستند که در داخل کشور معروف هستند، اما حتي نمي شناسم توليد کننده اي را که در بازار منطقه يا خاورميانه شناخته شده باشد، نظر شما چيست؟
- پرسش اصلي اينکه با علم به منفي بودن پاسخ پرسش هاي فوق، نرم افزار جهاني و نرم افزار ساز جهاني نداريم؟
راجع به آن خوب فکر کنيد، من هم سعي مي کنم همين کار را بکنم و در مطلبي از ديدگاه خودم به آن پاسخ دهم، پس تا بعد ....
همين!

Ali Vahed | 12:21 PM

درسی در طراحی سیستم های نرم افزاری، "اندیشیدن از آخر به اول"

August 12, 2007 8:30 PM

1-در کتاب هفت عادت مردان مؤثر می خواندم که یک خصوصیت مهم برای مردمان مؤثر آن است که "از انتها به ابتدا بیاندیشند" بدین معنی که قبل از انجام هر کاری ابتدا به نتیجه آن خوب فکر کنند و سپس راهی برای رسیدن به آن پیدا کنند و به شرایط لازم برای تحقق هدف خود برسند.
2-از جای دیگری هم شنیده بودم که دلیل موفقیت صنایع چینی آن است که قبل از تولید هر محصولی به این فکر می کنند که برای چه محصولی با چه قیمتی و در چه بازاری و به چه تعدادی مایل به ورود می باشند. وقتی هدف را ترسیم کردند، کارخانه و شبکه توزیعی ایجاد می کنند که این هدف را محقق سازد.
3-در طراحی سیتسمهای جامع مدیریت منابع سازمانی ( ERP: Enterprise Resource Planning) یک نکته آن است که سیستم را به صورت فرآیند گرا (process Oriented) و یا به صورت مدرن تر (Service Oriented) نگاه کنند به شکلی که با در نظر گرفتن خروجی مورد توقع از یک سیستم و نیاز مشتری، اجزای یک سیستم را کنار هم قراردهند. به این شکل سیستم خروجی بهتر و کم هزینه تری تولید می کند و هدف سیستم که همان مشتری مداری است محقق می شود.
4- ...
به مشابهت موارد بالا و مانند هر تولید دیگری ، یک نکته مهم در طراحی هر سیستم نرم افزاری ، علی الخصوص یک بسته عام نرم افزاری (General Software Package) آن است که طراح یا کمیته محصول موظف به ایجاد طراحی ، از آخر به اول فکر کنند، قبل از شروع به طراحی جزییات ، اول سیستم نهایی را مدل کنند، قبل از پرداختن به فرمهای ورود اطلاعات، خروجی ها و گزارش های سیستم را ببینند،  قبل از نوشتن هر قسمت، ارتباط اجزاء محصول را با یکدیگر ببینند، تا بنا کننده یک دیوار کج نباشند.
وقتی هدف به طور شفاف مشخص شد، وقتی توانستند، یک نرم افزار را که ماهیتا یک موجود انتزاعی است و تصور آن وقتی وجود هم دارد سخت است، به عینه ببینند و تصویری فیزیکی از آن داشته باشند، اقدام به طراحی جزییات و انتخاب متدولوژی و فرآیند توسعه آن نرم افزار بنمایند.
اگر قرار است یک سیستم گزارشگیری مدیریتی تهیه کنند، ابتدا گزارشهای مورد نیاز مدیران را بدانند بعد فرم ها و کانالهای ورود اطلاعات را پیش بینی کنند، وقتی قرار است یک سیستم اطلاع رسانی بسازند، اول مخاطب و نوع اطلاعات را شناسایی کنند، وقتی یک سیستم پردازش تراکنش می سازند، ابتدا خروجی های سیستم را ببینند، وقتی .... آن وقت است که می توانند محصول خوبی توسعه دهند و جلوگیری کنند از آنکه محصولشان اجزاء خوبی داشته باشد اما کلیت خوب خیر، اینکه سیستمشان ناهماهنگ باشد، کارایی مورد نظر مشتری را نداشته باشد یا نیازش را تحقق نبخشد...
امیدوارم من و شما، خوب یاد بگیریم که در طراحی سیستم ها این درس را بکارگیریم و سیستمهای خوبی را تحویل مشتری بدهیم...


همین!

Ali Vahed | 8:30 PM

خدمات پشتیبانی محصول نرم افزاری، بخش 1، دستگیره در حمام!

July 25, 2007 9:59 AM

دو سه سال پیش در هنگام یک پروژه، بخشی از آن را out source کرده بودیم. در ابتدای آن جلسه ای داشتم با مدیر شرکت مجری، پرسید مگر شما خودتان برنامه نویس ندارید که این قسمت را به ما می دهید، گفتم مشکل  نداشتن برنامه نویس نیست. چون قسمتی است که می تواند به صورت مستقل کار شود و بقیه بخش های برنامه از آن استفاده می کنند ترجیح می دهم در خارج از شرکت کار شود، ضمن اینکه این قسمت را آنطور که می خواهیم و بدون خطا باید به ما تحویل دهید، پس زمان کلی پروژه هم کاهش می یابد. وقتی توافق نهایی را می کردیم، گفتم هر کاری در این قسمت نیاز بود باید انجام دهید و حرف بچه های ما را گوش دهید، قبول کرد.
از آن پس در طول چند ماهه پروژه، بچه ها مدام به آن شرکت زنگ می زدند و اگر خطایی بود و یا نیاز جدیدی بود به وی اطلاع می دادند، به شکلی که ممکن بود روزانه حتی نزدیک به 10 بار تماس گرفته شود، به عبارت دیگر تقریبا دو طرف دیوانه شده بودند، هم بچه های ما چون محصول آنها مشکلات و یا پیچیدگی هایی داشت، هم آنها که مشتریشان ما بودیم و نمی توانستند مانند مشتری عادی قضیه را ساده فیصله بدهند.  از قضا دستگیره در حمام شرکت که ما به جای انباری از آن استفاده می کردیم هم خراب بود و در به سختی باز می شد. در آن روزها کارآموزی داشتیم  که در این پروژه هم فعال بود. این کارآموز ما به شوخی تا کسی می  خواست با آن شرکت تماس بگیرد و یک مشکل را برطرف کند، می گفت به آنها بگو دستگیره در حمام ما خراب است، لطفا آن را هم درست کنید! این جریان "دستگیره در حمام" در شرکت یک اصطلاح شد و به مرور به اصطلاحی تبدیل شد برای بیان خواسته های نامعقول مشتریان شرکت. توقعاتی که می دانم همه شرکتهای تولید کننده نرم افزار با آن مواجه بوده اند. چه نرم افزار بزرگی داده باشند چه کوچک، مشتری توقعاتی دارد که در چارچوب هیچ قرارداد و تعهد خدمات پشتیبانی نمی گنجد. یادم می آید در مورد یکی از مشتریان شهرستان، صاعقه زده بود و اتاق کامپیوترشان در آتش سوخته بود. ما هم خبر نداشتیم، چند وقت تماس گرفتند که برای نصب مجدد برویم. تعجب کردم چون نسخه Installer را هم داشتند. پرسیدم خوب خودتان نصب کنید، گفتند نه شما بیایید، گفتم خوب باید هزینه ایاب و ذهاب کارشناس را طبق گارانتی متقبل شوید، شاکی شدند که یعنی چه؟ شما باید نرم افزارتان را پشتیبانی کنید! باید رایگان بیایید و کار را انجام دهید. گفتم، آیا ما مقصریم که اتاق شما در آتش سوخته؟ آیا ما تعهدی راجع به خطاهای خارج از چارچوب نرم افزار داریم؟ آیا .... اما کو گوش شنوا...؟
بگذریم.... همه ما به اندازه کافی از این خاطره های تلخ و شیرین داریم. مطلب را با یک خاطره شروع کردم که در طی چندین نوشته ، بحث خدمات پشتیبانی محصولات نرم افزاری را مروری کنم.... پس تا بعد....!
همین!

Ali Vahed | 9:59 AM

نگاهی به مشکلات قراردادهای نرم افزاری

July 21, 2007 1:04 AM

اینجا را کلیک کنید، اگر چه مطلب کوتاهی است، اما خواندنش ضرری ندارد، مطلبی تحت عنوان "نگاهی به مشکلات قراردادهای نرم افزاری" در ITanalyse.ir
همین!

Ali Vahed | 1:04 AM

مهندس نرم افزار حرفه ای کیست؟

June 16, 2007 1:57 PM

به مطلبی با همین عنوان در وبلاگ "یادداشت های یک دانشجوی مهندسی برق" برخوردم که مطلب جالبی است و خواندنش را به همه دوستان نرم افزاری توصیه می کنم.اگر چه بماند که این که این مطلب با عنوان این وبلاگ در مغایرت است، بماند!


همین! 

Ali Vahed | 1:57 PM

نرم افزارها هم می میرند.

March 14, 2007 11:27 PM

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


دلایل مرگ نرم افزار را می توان در موارد زیر برشمرد:
- تغییر نیازهای سازمان استفاده کننده
- عدم پشتیبانی سازنده
- ارتقاء تکنولوژی و فنآوری ساخت و یا محیط استفاده (نرم افزاری و یا سخت افزاری)
- نقص نرم افزار (علی الخصوص نقص های غیر قابل برطرف شدن)
- به بازار آمدن نرم افزار با قیمت مناسبتر و یا کیفیت برتر
- مشکلات قراردادی بین خریدار و فروشنده که گاهی به لغو پروژه ساخت و کنارگذاشتن محصول آماده شده می گردد.
-...
دقت شود در برخی موارد فوق نرم افزار به صورت کامل از بین نمی رود، بلکه زمان استفاده از آن برای یک مشتری خاص به پایان می رسد که می توان آن را به مرگ آن نسخه  خاص از نرم افزار تعبیر کرد. شاید بهتر باشد به جای لغت Software Death  از Software Shoutdown  برای این پدیده استفاده کرد. به هر حال، باید پذیرفت که نرم افزار هم روزی می میرد. اما نکته مهم آن است که در مورد مرگ نرم افزار چه باید کرد؟
باید پذیرفت، آنقدری که در مورد تولد نرم افزار کار شده است (در قالب فرآیندهای ساخت سیستم و متدولوژی های تحلیل، طراحی و پیاده سازی) و یا در مورد رشد و نگهداری نرم افزار(در قالب فرآیند های پشتیبانی و نگهداشت نرم افزار)، در مورد مرگ نرم افزار کار نشده است و متخصصان نظر نداده اند.
چرا برای مرگ نرم افزار باید فکر کرد؟ پاسخ روشن است، تاثیری که مرگ یک نرم افزار روی تولید کننده و یا مصرف کننده می گذارد. تاثیری که شاید اهمیتش کمتر از مرگ واقعی یک انسان برای آن مجموعه ها نباشد.

همانگونه که یک انسان پیش از مرگ باید وصیت کند و حساب خودش را با سایرین روشن کند (به اصطلاح حلالیت بطلبد) و پس از مرگ هم، نزدیکان باید مراحل کفن و دفن را به طور کامل انجام دهند، در هنگام مرگ یک نرم افزار باید عمل نمود!
به من ایراد نگیرید که اینها چیست می نویسم، صبر کنید، توضیح می دهم!
از پارامتر های که در کیفیت نرم افزار مود توجه قرار می گیرد بحث جامعیت یا Integrity است. این پارامتر به محافظت نرم افزار از اجزاء خود در مقابل دسترسی های مجاز و غیر مجاز بر می گردد. بدین شکل که یک نرم افزار باید مکانیزم های امنیتی (security) و ایمنی (Safety) مختلفی را برای مخفی سازی جزییات و ساختار داده های خود رعایت کنند.
این پارامتر در مدت زمان حیات نرم افزار منطقی است و رعایت آن توسط هر نرم افزار حسن آن محسوب می شود. چون باعث می شود نرم افزار در مقابل دسترسی ها مستحکم باشد و نتوان به سادگی آن به آن نفوذ کرد و ساختارهای اطلاعاتی و عملیاتی آن را کشف کرد.
اما زمانی که یک نرم افزار از چرخه کاری سازمان خارج می شود (به اصطلاح همان مرگ) تکلیف چیست؟ در آن موقع باید در صورت لزوم اطلاعات از نرم افزار خارج شده و در قالب جدید و یا نرم افزار جدید قابل بارگذاری بشود و در مواردی تکلیف الگوریتم های پیجیده روشن شده و روش کار آنها در اختیار کاربر قرار گیرد تا بتواند در سیستم جدید احتمالی آن ها را استفاده کند، از سوی دیگر چنین نرم افزاری باید به صورت کامل از سازمان کاری فعال حذف شود بدون آنکه آسیب جدی به فرآیندهای جاری وارد نماید. به عبارت دیگر همانگونه یک نرم افزار را از روی یک دستگاه Uninstall می کنیم و با اینکار همه اجزاء نرم افزار از روی کامپیوتر برداشته می شود. به همان شکل هم باید بتوان یک نرم افزار را از روی یک سازمان Uninstall نمود.
با این توضیح، بهتر است یک نرم افزار هنگام مرگ خود کارهای زیر را انجام دهد (تسویه حساب و وصیت کردن میت!) :
- افشای ساختارداده خود در حدی که بتوان داده را از سیستم به سیستم دیگر انتقال داد.
- ارسال اطلاعات به یک فرمت استاندارد (برای مثال XML ) برای فراهم سازی امکان Import/Export
-افشای متن برنامه و علی الخصوص الگوریتم های پیچیده در صورت عدم متن باز (Open Source) بودن برنامه در حدی که بتوان روابط علی و معلولی تراکنش ها و ورود اطلاعات تا تهیه گزارشات را شناسایی کرد.
-معرفی همه بخش های خود برای آنکه با Uninstall کردن آنها از روی سیستم های سرور و استفاده کننده
-از کار افتادن بخش ها به صورت تدریجی و نه مقطعی برای عدم اخلال در کارهای جاری سازمان
-...
و یک تیم متخصص تولید کننده بایستی موارد زیر را در قبل و بعد از مرگ یک نرم افزار مد نظر قراردهند:
- فراهم کردن امکانات ساختاری برای زمان مرگ نرم افزار (موارد فوق)
- ارائه خدمات پشتیبانی در زمان آغاز فرآیند از کار انداختن نرم افزار (فرآیند تجاری)
- انتشار کد نرم افزار به صورت عمومی و یا خصوصی در صورت خاتمه همه فعالیت ها روی آن نرم فزار
-فراهم ساختن امکاناتی برای افزایش طول عمر نرم افزار از جمله قابلیت های توسعه، گسترش، انعطاف و سازگاری
- ...
وبرای یک استفاده کننده در زمان حذف یک نرم افزار سازمانی از چرخه کاری توصیه می شود:
- عدم شیفتگی در مقابل فنآوری های نوین، لزومی ندارد با هر ارتقاء نرم فزار و سخت افزار، نرم افزاری سازمانی ارتقآء یابد و یا جایگزین گردد.
- دقت در زمان مرگ نرم افزار: سازمانها پس از مدتی استفاده از یک نرم افزار، به شدت به آن وابسته می شوند و عوض کردن آن هزینه زیادی تحمیل می کند. تشخیص زمان درست کنارگذاشتن یک نرم افزار و جایگزینی آن و محاسبه تاثیرات و هزینه های احتمالی آن بسیار مهم است تا سازمان به صورت آگاهانه اقدام به انجام این کار بنمایند.
- دقت در زمان خرید نرم افزار: چنانچه نرم افزاری حساس خریداری می شود، فقط به موارد زمان راه اندازی توجه نشود، این شرط لازم است ولی کافی نیست. بهتر است در مورد آنکه آن نرم افزار در صورت نیاز به حذف چگونه عمل می کند هم ی تواند به عنوان یک پارامتر تصمیم گیری مطرح شود (هر چند با وزن تصمیم گیری پایین تر از سایر موارد).
- بکارگیری یک متدولوژی و یک روش گام به گام برای حذف یک نرم افزار: با خرید یک سیستم جدید، در بسیاری از موراد نمی توان به صورت انقلابی سیستم جدید را جایگزین قدیمی کرد. بلکه باید در یک دوره زمانی و با اطمینان از صحت عملکرد سیستم جدید و انتقال اطلاعات به آن و تکمیل فرآیند آموزشی کاربران به مرور نرم افزار قدیمی را از کار بیاندازند.
- هر نرم افزاری بالاخره می میرد، منتظر مرگ آن نباشند، آن را نکشند و یا وادار به خودکشی نکنند!: اغلب دیده ام سازمانها نگاهشان به یک نرم افزار شبیه نگاه به یک آدم در بستر مرگ است، هر روز آرزوی مرگش را می کنند و یا با دستکاری آن، زمینه مرگش را ساده تر می کنند، حتی گاهی با ساخت دعواهای الکی یا بهانه گیری، کاری می کنند که یک فروشنده نرم افزار، خود دست به خودکشی نرم افزارش بزند و عطای سازمان را به لقایش ببخشد. همه اینها زمانی فاجعه است که نرم افزار بدون مشکل و یا با ایرادات جزیی کار کند، ایراداتی که بحرانی هم نیست و صرفا استفاده کننده به دلیل شرایط احساسی و یا علاقه به کم کاری و یا ارتباط با یک فروشنده دیگر، مایل به ادامه کار یک نرم افزار نیست. (این مورد را به وضوح در پروژه ای که چند ماه پیش مشاور و ناظرش بودم دیدم که یک مجموعه از طرف کارفرما، چون خودش مجری اصلی نبود، در کار پروژه اخلال ایجاد می کرد تا بتواند نرم افزاری که تازه کمتر از یکسال از بهره برداریش می گذرد را با یک سیستم جدید جایگزین کند)

و یک توصیه همدردانه با تولید کنندگان نرم افزار: هر نرم افزاری روزی می میرد، زیاد غصه اش را نخورید، به فکر تولد سایر نرم افزار ها و خلق نرم افزارهای جدید باشید!
همین!

Ali Vahed | 11:27 PM

بیمارستان نرم افزار

March 10, 2007 11:29 AM

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


1- همه ما نرم افزاری ها،  محصولاتمان را مانند بچه هایمان دوست داریم، چرا مانند مراقبت از اطفال برای پشتیبانی نرم افزار عمل نکنیم؟
2- هفته هایی که گذشت به خاطر یکی از آشنایان، گذرم به صورت مداوم به بیمارستان ..... افتاد، مطابق معمول کنجکاویم گل کرد و سری زدم به بخش های اطلاعاتی آنها و نحوه نگهداری از بیماران، سرویس های منظم و غیر منظمی که باید به بیمار بدهند و نحوه تبادل اطلاعات بین دو پرستار از دو شیفت مختلف و پرستار با پزشکش و .....[مطمئن هستم که بسیاری از شما متاسفانه  حداقل حضوری به عنوان یک بیمار ، همراه بیمار و یا یک ملاقات کننده به بیمارستان داشته اید و می توانید وضعیت را در ذهنتان شبیه سازی کنید.]

3- اگر چه می توان برای بدست آوردن الگوی مناسب برای پشتیبانی از صنایع نیز بهره بردای کرد (سیستم های تعمیر و نگهداری معروف به سیستمهای PM الگوی بسیار مناسبی برای پشتیبانی از یک محصول می باشند.) اما شاید ماهیت نرم افزار نیاز به نگهداری دقیق تر و حساس تری دارد.
با ذکر این سه نکته، شاید تشکیل یک بیمارستان نرم افزار برای محصولات تولیدی یک شرکت و یا در ایده کلی برای یک سری محصولات معروف ایده بدی نباشد. این بیمارستان می تواند به بخش های زیر تقسیم شود:
- بخش CheckUP : در این بخش طی یک سری بازدیدهای مشخص (به صورت متناوب و طی یک الگوی زمانبندی و یا به صورت مداومی) سیستم نرم افزاری چک می شود تا از سالم بودن آن اطمینان حاصل شود. این چک شدن از طریق آزمایش های مختلف صورت می گیرد، بررسی رفتار نرم افزار در مقابل ورودی های مختلف و بررسی LOG File های عملکرد نرم افزار، بررسی رفتار گذشته نرم افزار، شبیه سازی حالات خطا و سنجش عملکرد نرم افزار نسبت به آن، سنجش میزان حافظه استفاده شده و پیش بینی میزان مورد نیاز در آینده برای جلوگیری از بروز خطا در آینده، سنحش قدرت سخت افزار مورد نیاز از طریق گزارشهای مورد نیاز و ارائه به صاحب نرم افزار برای تقویت احتمالی سخت افزار، بررسی استفاده های غلط از نرم افزار و ارائه راهنمایی های لازم برای کاربری صحیح و ....
- بخش اورژانس: در این بخش برای نرم افزارهای بحرانی در زمان بروز خطاهای بحرانی ، پیش بینی لازم صورت می کیرد. ارائه خدمات پشتیبانی به صورت ONline ، مراجعه به محل استفاده نرم افزار و رفع خطای بحرانی آن، وجود متخصصان کشیک برای فراخوانی به صورت Oncall در هنگام بروز خطا و معرفی به سایر بخش های بیمارستان نرم افزار پس از رفع خطاهای بحرانی و تثبیت فعالیت های جاری نرم افزار برای انجام اصلاحات اساسی تر
- بخش های نگهداری: این بخش ها می تواند شامل بخش های متفاوتی باشد، اما نکته یکسان در همه آنها، نگهداری و رفع عیب اصولی نرم افزار در صورت بروز خطا می باشد. در این بخش ها با سرکشی منطم، وضعیت نرم افزار در یک بازه زمانی سنجیده می شود و نواحی بحرانی شناسایی می شود و قبل از بروز خطای جدی اصلاح می شوند. (علاج واقعه قبل از وقوع) نرم افزارهای معرفی شده از بخش های دیگر ، در این بخش (ها) مورد مطالعه جدی تر قرار گرفته و اشکالاتشان از طریق اصلاح ساختاری نرم افزار (درست مانند یک عمل جراحی و یا پیوند) و یا غیر ساختاری (مانند دارو ها و جراحی های سرپایی) برطرف می شود.
- بخش زایمان[!]: خدا را شکر بیمارستان ما فعلا این بخش را ندارد!

نکته مهم در این بیمارستان تهیه یک CPR از نرم افزارهاست. CPR مخفف Clinical Patient Record است که حاوی اطلاعات بالینی بیمار است که به دفت و با نظم خاصی تهیه می شود و به عنوان عاملی برای هماهنگ سازی خدمات بالینی بیمارستان استفاده می شود. به نحوی که هر خدمتی که بیمار دریافت نمود و یا هر تغییر وضعیتی که در بیمار رخ داد در آن ثبت می شود تا همه افراد مسؤول -برای مثال پزشک برای پرستاران و یا افراد یک شیفت کاری برای شیفت دیگر- از آن مطلع شوند و از انجام دوباره کاری و یا تجویز های غلط جلوگیری نمایند.
با تشکیل این پرونده و راه اندازی یک HIS: Hospital Information System می توان وضعیت بیمار را به صورت online بررسی نمود و از گم شدن و یا اشتباه شدن ورود اطلاعات جلوگیری نمود.
راه اندازی چنین سیستمی برای بیمارستان نرم افزار ما هم بسیار راهگشا است. هر چند می دانم که بسیاری از شرکتها برای ارائه خدمات پشتیبانی به نرم افزارهای خود، چنین پرونده ای را برای هر مشتری تشکیل داده اند، اما متاسفانه در بسیاری از موارد خیلی خوب پرونده ها تشکیل نمی شود و یا به روز نمی شود و یا به اشتراک گذاشته نمی شود.
به نظر من در بخش پشتیبانی، نگاه انسانی به نرم افزار، نگاه مناسب تری است نسبت به نگاه صنعتی. یادتان باشد پیشتر در مورد تولد، حیات و مرگ نرم افزار نوشته بودم. این نگاه شاید جدی تر و حساس تر به مساله پشتیبانی نگاه کند و استفاده کنندگان نرم افزار هم راحت تر با آن کنار بیاییند.
این ایده هم مانند ایده Software FastFood نیاز به کار بیشتری دارد تا پخته شود. شاید هم ماننده همان قبلی، قبلا کسی رویش کار کرده باشد، هنوز جستجو نکرده ام، به هر حال دوست دارم روی مساله پشتیبانی نرم افزار بیشتر کار کنم. شاید به زودی یک دسته بندی جدید به همین نام در وبلاگ تشکیل دادیم، شاید ....
همین!

Ali Vahed | 11:29 AM

ایرانی، جنس ایرانی بخر!!، نرم افزار ایرانی .... ؟

February 26, 2007 10:52 AM

خدا را شکربه جز برخی وب سایت ها، تقریبا از رسانه های خبری کشور، تنها رادیو پیام را گوش می دهم، آن هم به خاطر آن است که موقع کار، رادیو روشن است![درست عین مسافر کش ها] این روزها، به صورت مداوم تبلیغ خرید محصولات ایرانی پخش می شود و تحلیل های مختلفی برای ترغیب مردم به اینکار ارائه می شود. احتمالا در رسانه های دیگر اعم از شبکه های تلویزیونی و یا رادیویی دیگر کشور هم همین وضع است. در اینکه مردم توصیه شوند به خرید کالای داخلی هیچ شکی ندارم و کار صداوسیما را می پسندم، اما سوالی که دارم آیا در مورد نرم افزار هم همین وضع است، آیا می توانیم مردم و سازمانها را تشویق کنیم که نرم افزار تولید داخل را بخرند  و آیا اصلا چنین توصیه ای درست است؟
سوال اول از آن جنبه است که آیا آیا در همه زمینه ها تولید داخلی مشابه داریم و سوال دوم از آن جنبه که آیا توصیه به خرید نرم افزار داخلی، توصیه درستی است؟
در مورد سوال اول، بدیهی است که در بسیاری زمینه ها ما مشابه داخلی نداریم، برای مثال سیستم عامل -از بحث پروژه سیستم عامل ملی که الان نمی دانم در چه وضعیتی است- گرفته تا بسیاری از نرم افزارهای سیستمی و یا کاربردی، مشابه نرم افزارهای مجموعه office ، نرم افزارهای گرافیکی، محیط های برنامه سازی، ..... اینها صرفا یا نمونه خارجی دارند و یا نمونه داخلیشان بسیار ضعیف و سطحی است.
در مورد سوال دوم هم اگر برای یک نرم افزار خارجی مشابه داخلی داشته باشیم، کدام انتخاب درست است؟ بگذارید مزایای هر یک را بررسی کنیم.

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

بنابراین مهمترین نکته آن است که در مورد یک نیازخاص، ابتدا بررسی کنیم که آیا نرم افزار ایرانی برای آن وجود دارد یا نه و اگر بین سیستم های موجود بین نسخه خارجی و داخلی آن تفاوت چندانی نیست، اولویت را به خرید محصول ایرانی بدهیم.
همین!

Ali Vahed | 10:52 AM

Software Fast Food 2

January 18, 2007 10:31 AM

ديروز مطلبي نوشته بودم در مورد اداره يك شركت نرم افزاري و توليد نرم افزار به شيوه يك رستوران با غذاهاي آماده و سريع. خواننده گرامي با نام مهدي لينك مطلبي بود نوشته آقاي Robert  با عنوان


How Software Development is Like Fast Food Restaurants


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


همين!

Ali Vahed | 10:31 AM

Software Fast Food

January 17, 2007 3:08 PM

به بحث معیارهای کیفی در تولید نرم افزار بارها اشاره کرده ام، همچنین لزوم سرعت بخشیدن به تولید، این مطالب را هم در ادامه آن مطالب بخوانید. منتها از زاویه دید دیگر، ممنون!
به جای مقدمه :
1- در مهندسی نرم افزار، با الگو برداری از صنایع و معماری سعی کردند روند تولید را مهندسی کرده و فرآیند ها را بهبود بخشند، ورود مبحث معماری به طراحی نرم افزار ، توسعه نرم افزار مبتی بر مؤلفه ها (CBSD: Component Based Software Development)  ، مهندسی همزمان و .... از جمله مطالب وارداتی است.
2- طرح مباحثی نظیر کارخانه نرم افزار (Software Factory)  و سوپرمارکت نرم افزار (Software Supermarket  ) باعث تغییر نگرش تولید کنندگان و مصرف کنندگان نرم افزار شد. لزوم تحویل سریع، اعطای حق انتخاب، بهره گیری از قطعات پیش ساخته، ایجاد خط تولید و ... از جمله این مفاهیم است.


اما Software FastFood چیست و ایده اش از کجا آمد؟


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

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

این جریان گذشت، منتها مدام این مساله ذهن من را مشغول کرده بود که آیا می شود همین مدل را در یک شرکت تولید کننده نرم افزار هم تجربه نمود....

فکر که کردم دیدم می شود. فقط باید ماژولی آماده کرد که از کامپوننت بزرگ تر باشد -برای مثال یک Bussiness Component- و شناختی داشت از نیاز مشتریان. یک جوری مدل توسعه یافته ای از Component Based. مدلی که در آن به جای آن که هدف کیفیت و تولید همه مدل نرم افزار نمود، توجه کرد به سرعت تولید و یکنواختی تولید نرم افزار، همراه با منطبق سازی با نیاز های مشتری. یک جوری شاید ترکیب متدولوژی Agile با CBSD.
طبیعتا این مدل برای یک شرکت تولید کننده بسته های نرم افزاری همه منظوره (Package ) و یا مجری پروژه های نرم افزاری اختصاصی بایستی به درستی اجرا شود. مدیریت همچین شرکتی مسائل خاص خودش را دارد، لزوم توجه به سرعت در تحویل همزمان با تنوع در محصول، با رعایت کیفیت در تولید.
اما طبیعتا می تواند به یک طیف خاص مشتریان، سرویس خوبی بدهد.
در هنگام تولید در چنین شرکتی، پیش بینی میزان فروش بسیار مهم است، تا بتوانند پرسنل مناسب برای تولید و منطبق سازی سریع آماده کنند.
در مورد نیروی فنی هم می توان پرسنل فنی اینچنین شرکتی را در دو گروه Backend و Frontend اماده کرد. در گروه پشت صحنه یا Backend ، هدف آماده سازی ماژول های نیمه آماده است. طبیعتا این گروه زمان بیشتری برای تولید دارد و هدفش تولید ماژول با رعایت پارامترهای کیفی است. اما در گروه پیشرو Frontend هدف ترکیب درست ماژول ها و منطبق سازی سریع با نیاز های مشتری است. در هر موردی هم که امکان داشت ماژول نیمه آماده از طریق یک تولید کننده عمده خریداری شود ( مانند سیب زمینی نیمه آماده!) که همان بهره گیری از کارخانه نرم افزار است.
.....

این ایده هنوز جای کار دارد، خیلی هم دارد، شاید فرصت کنم و یک کمی کامل تر روی آن کار کنم و پخته اش کنم. شاید یک مقاله شود، نمی دانم.

همین!

Ali Vahed | 3:08 PM

تفکر چینی

December 25, 2006 1:52 PM

مقدمه: در این نوشته، نگاهی خواهم داشت به بحث تغییر نگرش کیفیت در تولید نرم افزار.


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


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

سوم. کیفیت نرم افزار، تفکر ژاپنی، تفکر چینی: آیا همین اتفاق(تغییر نگرش از تولید با کیفیت ولی گران و کند به تولید سریع و ارزان اما بی کیفیت) رایج شده است (از تفکر ژاپنی به چینی)؟
به نظر می رسد تغییر دید در متدولوژی ها و فرآیند های تولید نرم افزار همین را نشان می دهد. متدولوژی ها از نمونه سازی و الگو سازی و یا مبتنی بر مولقه تبدیل شده است به مدل های کرانه ای (XP) و چابک (Agile). در نگرش های قبلی با تحیلی مداوم ریسک، با ایجاد الگوها (Prototype) و تفکر معماری در نرم افزار در متدولوژی هایی نظیر RUP هدف ساخت یک نرم افزار خوب بود. اما حالا همه آنها را کنار گذاشته ایم و هدف را تولید سریع و ارزان نرم افزار قرار داده ایم. در Agile می گوییم در دوهفته اول باید یک تحویل محصول داشته باشیم، می گوییم نیاز مشتری را در همه زمانها گردن می گیریم. این یعنی نادیده گرفتن خیلی از پارمترهای کیفی.
واقعیت را هم ببینید شرکتهای بزرگ باعث شدند که کاربران مدام با سیستمهای سخت افزاری، سیستم عامل های جدید و پروتکل های شبکه متفاوت مواجه باشند. این عوض شدن مداوم بسترهای نرم افزاری و سخت افزاری باعث شده است، عمر نرم افزارها به شدت کاهش یابد و سازگاری نرم افزار های قدیمی با شرایط جدید از بین برود. از سوی دیگر هم ابزارهای توسعه نرم افزار و محیط های برنامه نویسی هم مداوم در حال تغییر و به روز رسانی هستند اینکار باعث می شود شرکتهای تولید کننده هم به خاطر کاهش هزینه های تولید و پشتیبانی، به صورت پیوسته نرم افزارهای تولید شده خود را ارتقاء دهند. عامل دیگر هم گسترش کاربرد نرم افزارهاست. دیگر خریداران نرم افزار یک گروه از شرکتهای بزرگ و سازمانها نیستند. نرم افزارها در سطح شرکتهای کوچک، مغازه ها و خانه ها گسترش عجیبی پیدا کرده است، به همین دلیل حس نو خواهی کاربران عام هم در تولید تاثیر گذاشته است.
بدین ترتیب است که به نظر من امروز دیگر کیفیت مانند قبل ارزش ندارد. مهم آن است که سریعتر و ارزان تر بسازی، در نهایت مشتری خیلی سریع نیازش تغییر می کند و باز می خواهد خرید جدیدی داشته باشد، پس بحث های معماری و کنترل کیفی گران قیمت دیگر جایگاه ندارد.
لازم می دانم این نکته را ذکر کنم که این استدلال جنبه عمومی دارد. هنوز مشتریان مهمی هستند که به خاطر سیستمهای حیاتیشان پول کیفیت را بپردازند، بانک ها، سازمانهای بزرگ و .... هنور مشتری سیستم گرانتر اما با کیفیت تر هستند.
با این قضایا، تولید کنندگان ایرانی نرم افزار چه راهکاری را باید انتخاب کنند تا در شرایط جدید بازار دوام داشته باشند؟ به این مطلب در آینده خواهم پرداخت
همین

Ali Vahed | 1:52 PM

اندازه گیری 5- سازمانها، کلیات

December 10, 2006 2:32 PM

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


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


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

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

فارغ از این سطح بندی، مدل هایی وجود دارد که با بهره گیری از آن می توان کلیت سازمان را در همه سطوح و یا در سطوح مشحصی مدل سازی نموده و با تعریف معیارهای کمی، پارامترهای کیفی سازمان را بهبود بخشید.
مدلهایی نظیر TQM ، EFQM و یا BSC از اینجمله اند. مدلهایی که بسیار کاربرد دارند و فارغ از جنبه تخصصی هر سازمان، عمومیت دارند. از سوی دیگر مدل هایی نظیر PAEM نیز که یک مدل داخلی است قابل تعریف است.
دقت کنید که همانگونه که در اصول اندازه گیری گفتیم، یک معیار منفرد برای اندازه گیری یک چیز نداریم و مدلهای فوق هر یک از جنبه های مختلف، معیارهایی را تعریف و اندازه گیری می کنند.
در نوشته های بعدی برخی از این مدل ها را معرفی می کنم...
همین!

Ali Vahed | 2:32 PM

اندازه گيري 4- اصول اندازه گیری

December 9, 2006 6:39 PM

آقای گودمن در کتاب خود، 6 اصل را برای اندازه گیری-خصوصا در مورد معیارهای نرم افزار- نام برده است که ذکر آن در ادامه سلسه مطالب اندازه گيری خالی از فایده نیست.


اصول اندازه گیری:
1- مصالحه و مصلحت گرایی (Pragmatism & compromise) :  تعیین دقیق محدوده اندازه گیری، نه کم (عدم دقت) و نه زیاد (اثر مخرب)
2-اندازه گیری آدم ها، هرگز! (!Measuring Peaple-Dont) : اندازه گیری افراد باعث کاهش بهره وری و ایجاد تفرقه می شود.

3-مدل سازی= ساده سازی (Modeling=Simplification) : یک معیار برای اندازه گیری همه چیز وجود ندارد. پس باید مدل سازی کرد و معیار های مختلف را روی آن تعریف کرد. در سطح ساده سازی باید دقت کرد.
4- نپرسید برای چه کسی، به پرسید چرا؟ (Ask not for whom the bell tolls ask Why) : اندازه گیری زمانی خوب است که بعد از آن با جمع آوری اطلاعات دیگر تحلیلش کنیم و دلایل را بفهمیم.
5-مجموع کل بزرگتر از هر جزء است. (The sum of whole is greater than the constituent parts) : کنارهم گذاشتن چند معیار اندازه گیری (تشکیل یک نمایشگر)، اطلاعات بیشتری از مشاهده تک تک معیار ها به ما می دهد.
6-شک فرهنگی (Culture Shock) : اندازه گیری معیارها باعث تغییر در رفتار و کار آدمها می شود.
برای کسب اطلاعات بیشتر مراجعه کنید به

Goodman,Paul, "Software Metrics: Best Pracices for Successfull IT Management",Rothstein Associates,2004

ادامه دارد ....
همین!

Ali Vahed | 6:39 PM

اندازه گیری 3- معیار های نرم افزار

December 7, 2006 4:21 PM

Software Metrics


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


اما بعد ...


معیارهای نرم افزار (Software Metrics)  را می توان چنین تعریف کرد: "کاربردی پیوسته از تکنیک های اندازه گیری در فرآیند توسعه نرم افزار در فراهم کردن به موقع اطلاعات مدیریتی معنادار به همراه بکارگیری این تکنیک ها در بهبود فرآیند و محصولاتش"


با این تعریف محدوده کاربردی معیارهای نرم افزار ترسیم می شود:

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

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

در مورد هر کدام از این موارد می توان نمایشگر ها یا شاخص هایی تعیین نمود تا دیدگاهی مناسب برای هر محدوه تعیین نمایند. این دیدگاه می تواند در تصمیم گیری های مدیران پروژه نرم افزاری مؤثر باشند. اما باید در اندازه گیری اصولی را رعایت کرد...
به این اصول در مطالب بعد اشاره خواهم کرد.
همین!

Ali Vahed | 4:21 PM

اندازه گیری 2- تعاریف اولیه

December 6, 2006 3:52 PM

چند واژه یا اصطلاح است که قبل از ورود به بحث اصلی اندازه گیری نرم افزار و سازمانها بایستی تعریف شوند:
-اندازه یا سنجه ، Measure : یک نمایشگر یا شاخص کمی برای یک اندازه ، مقدار، سایز ، حجم یا .... به که به صورت عددی در یک واحد خاص نمایش داده می شود.
-اندازه گیری، Measurement : فرآیند تشخیص یک اندازه
-معیار، Metric:  یک اندازه کمی برای نمایش درجه دارا بودن یک صفت برای یک سیستم، مؤلفه یا پردازش
-نمایشگر یا شاخص، Indicator : یک یا ترکیبی از چند معیار که با یک دیگر یک دیدگاه از یک فرآیند، پروژه، نرم افزار، محصول و .... را ایجاد می کنند.
-میانگین وزنی: ترکیبی از معیارهای مختلف با درنظر گرفتن ضرایب خاص هر کدام که نسبت تاثیر آن معیار را در میانگین وزنی بدست آمده روشن می کنند.

پرسمن (Roger S. Pressman ) در کتاب مهندسی نرم افزار خود، چهار دلیل برای اندازه گیری بیان می کند:
1- برای مشخص سازی (to Characterize) : برای فهم یک موضوع (فرآیند، محصول، منبع یا ... ) و ایجاد یک مبنا و پایه برای بررسی های بعدی
2- برای ارزیابی (to Evaluate) : تشخیص وضعیت جاری نسبت به برنامه ریزی ها و اندازه گیری های اولیه و تعیین میزان انحراف
3- برای پیش بینی (to Predict) : برای ایجاد امکان برنامه ریزی
4- برای بهبود (to Improve) :ارتقاء هر چیز و تشخیص کاستی های یک چیز و حرکت در جهت اصلاح آنها
در مطلب های بعدی این موضوع تکمیل می گردد.
همین!


admin | 3:52 PM

اندازه گیری - 1

December 5, 2006 4:27 PM

"اگر بتواني چيزي را اندازه گيري کني مي تواني آن را مديريت کني!"
(!If you can mesure it you can manage it)


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

Ali Vahed | 4:27 PM

سوالی برای جواب ندادن...!

November 21, 2006 8:03 PM

"آیا زمان تولید کنندگان کوچک در نرم افزار به پایان رسیده است؟"


قرار بود جمله بالا تیتر یکی از نوشته هایم شود. اول به جای تیتر نوشتمش. جند دقیقه ای صبر کردم، نتوانستم به عنوان تیتر بگذارمش.نمی دانم چرا؟شاید چون هنوز نمی دانم جواب درستی به آن می دهم یا نه؟
پس بگذارید فقط طرح سوال کنم:" آیا زمان تولید کنندگان کوچک نرم افزار به پایان رسیده است؟"


یک کمی راهنمایی هم که اشکالی ندارد! پس :



  • می توان جواب داد، بله ! چون در زمینه نرم افزارهای کاربردی شرکت های بزرگ با طرح سیستمهای ERP و نظریات کارخانه نرم افزار و سوپرمارکت نرم افزار، عملا تمام آنچه می شد ساخت را می سازند. سیستم عامل ها هم به قدری توسعه پیدا کرده اند که عملا بازار نرم افزارهای سودمند (utility)  کساد شده است. توسعه سیستمهای کوچک، مانند وب سایت ها و یا نرم افزارهای ساده هم که با ابزارهای نسل چهارم حل شده است، فقط با یک مجموعه نرم افزار Office بدون آنکه برنامه نویسی بدانید می توانید همه نیازهای یک شرکت کوچک و یا متوسط را به  بهترین شکل پیاده سازی کنید.
  • می توان جواب هم داد خیر! چون هنوز تولید برای  تولید کنندگان کوچک مقرون به صرفه است، چون هزینه سربار کم تری دارند، قیمت تمام شده محصول کمتر و کیفیت در مواردی بالاتر می رود، هنوز اختصاصی سازی جای خود را از دست نداده است. زمینه های جدید هنوز هم جایگاه تولید کنندگان منعطف تر است تا شرکتهای بزرگی که در مقابل تغییرات مقاومت تر است.

قضاوتش باشد با خود شما، من جواب سوال را نمی دانم، باید صبر کرد و دید... مگر آنکه کسی از آینده خبری بگیرد. کجاست مردی که زیاد می دانست!؟


همین!

Ali Vahed | 8:03 PM

توليد نرم افزار، تفاوت ها با ديگر توليد هاي صنعتي

October 28, 2006 8:07 PM

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

فرآیند مدیریت پروژه (سازماندهی، برنامه ریزی و نظارت) به عنوان یک اصل جدانشدنی از هر پروژه ای در همه صنایع (منجمله نرم افزار) هم وجود دارد.
اما نرم افزار به لحاظ عوامل ماهیتیش چنان با بقیه کالاهای صنعتی متفاوت است که می بینیم در روشهای توسعه آن تنوع زیادی وجود دارد و هر روز یک مدل جدید برای توسعه نرم افزار می بینیم. این تفاوت ها را به طور خلاصه می توانیم شامل موارد زیر بدانیم:
1- نرم افزار پیچیده است (Complexity): به تعبیری "کاهش پیچیدگی قلب توسعه نرم افزار است." یک برنامه کوچک گاهی هزاران خط فرمان می شود و توسعه آن به هر نحو مشکل است. روشهایی مانند ماژول بندی و .... آمده است، اما هنوز هم پیچیدگی یکی از مهمترین اجزاء جدانشدنی نرم افزار ها و فرآیند تولید آن است.
2- نرم افزار انتزاعی است (abstraction) : شما نمی توانید به شکل فیزیکی آن را لمس کنید و نشان دهید. نه خودتان واقعا می توانید همه آن را یکجا در دست بگیرید و مشکلتر آنکه مشتری ها عقلشان به چشمشان است! و شما عاجز از نمایش کار خود. نرم افزار انتزاعی ترین جزء تولید است.
3- نیازها کامل نیست. (Uncomplete Requirements) : اغلب موراد، پیش از ساخت واقعی نرم افزار، همه نیازهای مشتری یا استخراج نشده و یا هنوز معلوم نیست. در پایان پروژه، تازه مشتری می فهمد که واقعا چه می خواهد.
4- فنآوری به سرعت تغییر می کند (Technology Changes Rapidly): سرعت تغییرات در فنآوری های ساخت نرم افزار فوق العاده سریع است. هر روز بستر و سیستم عامل جدید، هر روز تغییر سخت افزار، تغییر زبانهای برنامه سازی و .... کدام فنآوری را می شناسید که به این سرعت تغییر کند.
5-تجربه های موفق بالغ نشده اند. (Immature Best Practices): به خاطر رشد سریع، اغلب تولید کنندگان به خوبی مهارت های تولید را کسب نکرده اند. معمولا در پروژه ها عوامل کیفی کمتر دیده می شود و بنابراین تجربه های موفق کمتر بدست می آیند.حتی در صورت وجود، به دلیل تغییرات سریع فنآوری، کمتر در پروژه های بعدی می توانند الگو باشند.
6- فناوری اطلاعات بسیار گسترده است. (Technology is a Vast Domain): در این که شک ندارید! کسی نیست در این زمینه که همه فن حریف باشد (علامه دهر در نرم افزار نداریم!) بنابراین کسی نمی تواند به تنهایی به همه قسمت های یک پروژه اشراف داشته باشد.
7-تجارب فنآوری ناقص هستند. (Incomplete Technology Experience) : فنآوری های جدید و نسخ های جدید ابزارها اغلب آنقدر با نسخه قبلیشان تفاوت دارد که به سرعت تجربه افراد در این زمینه خارج از رده می شود. تجارب اکثر در موقع کار بدست آمده و بعد از آن کمتر به درد می خورند.
8- توسعه نرم افزار اکتشافی است. (Software Development is Research) : به دلیل عدم شناسایی نیازها و عدم دانش مشتریان نرم افزار با آن، فرآیند تولید اغلب ماهیت تحقیقاتی و یا اکتشافی به خود می گیرد. ابزارها نیز جدیدند و توسعه دهنده باید آموزش استفاده از آنها را کسب کند. بنابراین فرآیند توسعه نرم افزار فقط ساخت آن نیست، یادگرفتن آن است که با چه راهی می توان به نتیجه رسید.
9- کارهای تکراری خودکار هستند. (Automated Repetetive works) : در نرم افزار و تولید آن، به حدی از خودکار سازی برای فرآیند های تکراری رسیده ایم که در تولید های دیگر هنوز بحث آن هم مطرح نشده است، حجم بالای استفاده مجدد (reuseability) از قطعات آماده، برون سپاری تولید (Outsourcing) و.... نمونه هایی از این خودکار سازی است.
10-ساختن در واقع طراحی است . (Construction is Actually Design) : همه فرآیند های صنعتی مراحل مشخصی دارند (تحلیل، طراحی و اجرا : یک مدل خطی خوش تعریف) اما نرم افزار چنین نیست، در مرحله پیاده سازی و اجرا، نیازها به مرور تشخیص داده می شوند و این باعث می شود طراحی تا پایان ادامه پیدا کند. حتی در زمان نگهداری و پشتیبانی نیز، فرآیند طراحی به شکل جدی مطرح است.
11- تغییرات راحت پنداشته می شوند. (Changes Considered easy) : تغییر نیاز در فرآیند های تولید دیگر توسط مشتری بسیار سخت دیده می شود و وی سختی تغییر طراحی را در پایان پیاده سازی می فهمد و بنابراین آن را مطرح نمی کند و یا اگر مطرح کرد هزینه آن را می پذیرد. اما در نرم افزار به خاطر ماهیت انتزاعی بودنش این تغییرات ساده فرض می شوند. چون نرم افزار به سادگی قابل توسعه است، مشتری متوجه نیست که چیزی که می خواهد واقعا چه هزینه ای برتولید کننده تحمیل می کند تا آن را اجرا کند. اغلب تغییرات ساختاری نیز بسیار ساده فرض می شوند و تولید کننده را وادار به ساخت آن.
12- تغییرات اجتناب ناپذیرند. (Inevitable Changes) : ایا در نرم افزار موقعیتی هست که تغییر نکند. همه چیز از فنآوری تا نیاز مشتری تا تیم تولید تغییر می کند و این تغییرات بسیار سریع و غیر قابل اجتناب می باشند. گریزی نیست که آنها را در نظر بگیریم.به قولی تنها چیز "ثابت" در نرم افزار خود مفهوم "تغییر" است. هیچ نرم افزاری در ابتدا کامل نیست و این تغییرات است که باعث می شود مطابق نیاز در بیاید.

این دوازده مورد و موارد دیگری از این دست، تفاوت های ماهوی و سختی و پرخطر بودن تولید نرم افزار را نسبت به سایر تولید های صنعتی نشان می دهد. نتایج یک تحقیق که در سال 2000 انجام شده است نشان می دهد که تنها 28 درصد پروژه های نرم افزاری موفق بوده اند، 23درصد متوقف شده اند و الباقی (یعنی 49%) با مشکلات جدی نظیر تاخیر تحویل، افزایش بودجه و یا عدم برآورده کردن نیازها مواجه بوده اند.
این مشکل است، اما راه حل کجاست؟ طبیعی است در "مدیریت پروژه"! در آینده به بحث مدیریت پروژه به صورت جدی تری خواهم پرداخت.
همین!

در نوشتن این مطالب، کمک زیادی گرفته ام از کتاب "Software Project Secrets: Why Software Projects Fail" . گرچند هنوز کامل نخواندمش، خواندنش را به همه توصیه می کنم. مخصوصا کسانی که تجربه کار در پروژه های مختلف را دارند و مسائل آن برایشان ملموس است.

George Stepanek, "Software Project Secrets: Why Software Projects Fail" , Apress, 2005

Ali Vahed | 8:07 PM

Extreme Programming (قسمت اول)

October 15, 2006 12:19 PM

"XP يا Extreme Programming در واقع يک فرآيند توسعه نرم افزار عميق و منظم مي باشد. اين روش از سال 1990 توسط شخصي به نام Kent Beck  به همراه  Ward Cunningham اين فرآيند را براي توسعه آسان نرم افزارها ايجاد و در سالهاي بعد آن را تکميل کردند به نحوي که از سال 1996 به عنوان يک روش مناسب کاربردهاي خود را نشان داد و هم اکنون در شرکتهاي مختلفي با سايز هاي متفاوت مورد استفاده مي باشد. يکي از دلايل موفقيت اين روش تاکيد آن بر رضايت مشتري است. اين متدلوژي براي ارائه چيزي که واقعا مشتري نياز دارد طراحي شده است. همچنين اين روش کمک مي کند که نيازهاي مشتري را حتي در پاياني ترين مراحل توليد در سيستم اعمال کنند. از ديگر تاکيد هاي روش توجه به کار گروهي است و اين کار را با ساده ترين و مؤثرترين راه انجام مي دهد.. مديران، مشتريان و توسعه دهندگان همه اعضاي تيمي هستند که مختص تحويل يک نرم افزار خوب (با کيفيت) ايجاد شده است.
XP يک پروژه نرم افزاري را در چهار وجه ، ارتباطات (Communication) ، سادگي (Simplicity) ، بازخورد ها (Feedback  ) و شجاعت (Courage ) بهبود مي بخشد: 1-برنامه نويس XP ابتدا با مشتري ارتباط بر قرار مي کند، سپس برنامه سازي را دنبال مي کند. 2- آنها طراحي خود را ساده و تميز نگه مي دارند. 3- با آزمايش نرم افزارهاي خود ار روز اول بازخورد مي گيرند. 4- سيستم را در اولين فرصت به مشتري تحويل مي دهند و تغييرات را به محض پيشنهاد دادن انجام مي دهند. بر پايه XP، برنامه نويسان قادر خواهند بود که شجاعانه به تغييرات نيازها و فنآوري پاسخ دهند.
XP شامل اجزا زیاد کوچکی است که در نگاه اول هر کدام معنی خاصی نمی دهد اما وقتی بایکدیگر ترکیب شدند یک تصویر کامل می سازند. این یک فاصله اساسی با توسعه سنتی نرم افزارها ایجاد می کند. در یک کلام XP متفاوت است."


مطلب بالا خلاصه است از ادعاهایی که طراحان XP در مورد روش خودشان مطرح کرده اند. در سلسله مطالبی، به مرور این روش خواهیم پرداخت.  سپس Agile را بررسی می کنیم  و به تغییرات اساسی که در فرآیند توسعه نرم افزار اعمال می کند اشاره می کنیم.


همین!

Ali Vahed | 12:19 PM

ده فرمان مدیریت پروژه

October 13, 2006 3:56 AM

نوشته ای خواندم از آقای James M. Kerr  در سایت ComputerWorld . زیبا بود و مختصر. بد ندیدم ترجمه اش کنم و برای شما هم  بگذارم. ترجمه ای همراه با تلخیص. اصلش را بخوانید بهتر است. از من گفتن بود!


ده فرمان مدیریت پروژه
"آنها شرکت شما را به سمت سرزمین موعود فرهنگ مبتنی بر پروژه  (پروژه محور) رهنمون می سازند!"



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

2- به یک تیم بزرگ (چاق) تن درندهید.
بهترین راه برای شروع آن است که از مناسب بودن سایز تیم اجرای پروژه مطمئن شوید. تیم های بزگتر سخت تر برانگیخته یا مدیریت می شوند و مدیریت پرسنل برای شما یک کار می شود. هیچ سایز بهینه ای به صورت پیش فرض برای پروژه وجود ندارد اما یک قانون خوب آن است که در تیم پروژه هر شخص یک نقش داشته باشد و برای هر نقشی هم یک شخص، اما اگر نیاز باشد که هر شخص چند نقش داشته باشد مشکلی نیست! . اگر در تشخیص تعداد خطا کنید، به سوی کوچک کردن تیم باشد بهتر است.

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

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

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

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

7- تیم پروژه را تقویت کنید.
از تیم پروژه ای که برای رسیدن به مهلت زمانی پایان پروژه در تلاش است نباید انتظار داشت که کارهای مقدماتی نظیر پرکردن جدول های زمانی کار و یا شرکت در جلسات سازمانی را انجام دهند. در عوض، آنها را باید برای انجام هر کار با ارزشی که در جهت انجام پروژه در زمان و بودجه مقبول لازم است تقویت کرد. افراد در محیط های امن که انتظارات بدرستی تعریف شده و به خلاقیت افراد ارزش داده شود پرتلاش تر کار می کنند.

8- از ابزارهای مدیریت پروژه استفاده کنید.
مدیریت پروژه های این دنیا را می توان خودکار نمود! بدنبال ابزارهایی باشید که پیگیری پروژه، مدیریت وظائف، مدیریت جریان کار و تحلیل نیاز به منابع را در یک بستر اینترانت که در آن به اشتراک گذاری اطلاعات و ارتباطات فراهم است را انجام می دهند. اما به یاد داشته باشید بهره گیری از فنآوری که یک لایه جدید از پیچیدگی را اضافه می کند در یک پروژه مشکل دار، ایده خوبی نیست.

9- موفقیت ها را پاداش دهید.
همه اعضای تیم پروژه باید در جهت مثبتی برای زحمات و فداکاریهایشان مشخص شده، پاداش گیرند. پاداش نیازی نیست که خارق العاده باشد. گاهی اوقات یک توصیه نامه صمیمی از رئیس شرکت کافیست. سپاسگذاری های موثر تر نظیر دعوت به یک مهمانی، تئاتر ، اعطای یک زمان تفریح و مرخصی اضافی و یا جایزه مالی در مواردی که نتیجه می دهد در نظر گرفته شود.

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

همین!

Ali Vahed | 3:56 AM

اخلاق حرفه ای 3

October 9, 2006 12:11 AM

قول داده بودم در ادامه مطلب اخلاق حرفه ای نظرات ACM/IEEE را ترجمه کنم و در این وبلاگ بگذارم که نشد. اجالتا به دلیل اهمیت این مطلب، خلاصه مورد به مورد این اصول را که در کتاب مهندسی نرم افزار آقای sommerville آورده شده است را ذکر می کنم:

اصول  مهندسی نرم افزار:
- مهندسین نرم افزار به نفع عموم کار می کنند(Public).
-مهندسین نرم افزار طوری عمل می کنند که به نفع کارکنان و مشتریان باشد و با نفع عمومی سازگاری داشته باشد. (Client & Employer)
-مهندسین نرم افزار تضمین می کنند که محصولات و اصلاحات آن ها از بالاترین استاندارد تخصصی پیروی می کند. (Product)
- مهندسین نرم افزارجامعیت و استقلال را در قضاوت تخصصی خود حفظ می کنند. (Judgement)
-مدیران و رهبران مهندسین نرم افزار، توسعه و نگهداری نرم افزار را بر اساس اصول اخلاقی انجام می دهند. (Management)
-مهندسین نرم افزار جامعیت و شهرت را مطابق با منافع عموم گسترش می دهند. (Profession)
- مهندسین نرم افزار حامی همکاران خود هستند و با آنها با عدالت برخود می کنند(Colleagues)
-مهندسین نرم افزار سعی در آموزش بیشتر در حرفه خود دارند و اخلاقیات را نیز رعایت می کنند.(Self)

همین!

بعد از نوشتار:خیلی وقت است که نشده که بنویسم، چرایش بماند. ترم جدید که شروع شد، فرصتش باز فراهم است.

Ali Vahed | 12:11 AM

تولد، رشد و مرگ نرم افزار!

May 2, 2006 7:29 PM

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

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

Ali Vahed | 7:29 PM

اخلاق حرفه ای 2

October 2, 2005 4:34 AM

در ادامه راستای مطلب اخلاق حرفه ای ، به صورت کاملا تصادفی و در هنگام مرور یک کتاب، به مطلبی بر خوردم در خور تقدیر که واقعا از خواندن آن لذت بردم و بد ندیدم ارجاعی بدهم خوانندگان را به این مطلب خوب. این مطلب در مورد اخلاق حرفه ای در کامپیوتر است و قواعد اخلاقی لازم برای اعضاء ACM.
امیدوارم به زودی بتوانم ترجمه این مطلب را به صورت سریالی در وبلاگ بنویسم اما قبل از آن توصیه می کنم با مراجعه به متن اصلی به آدرس http://www.acm.org/constitution/code.html از خواندن آن لذت ببرید.
پیشنهاد می کنم درنگ نکنید و روی آدرس بالا کلیک کنید، ضرر نخواهید کرد...!
همین!

Ali Vahed | 4:34 AM

اخلاق حرفه ای

July 10, 2005 3:17 PM

چندی پیش در کلاس مبانی کامپیوتر یکی از دانشگاهها، یکی از دانشجویان از من پرسید آیا به ما نوشتن ویروس و یا روشهای حمله (Attack)  و یا نفوذ (Hack) و یا شکستن قفل ها (crack) را آموزش می دهید؟ در جواب به وی گفتم نوشتن ویروس های ساده و یا انجام کارهای خرابکارانه بالا کار زیاد سختی نیست. آنقدر روش، مدل و ابزار برای اینکار وجود دارد و آنقدر کاربران ایرانی چه در سطح مدیریتی، مسوولین کامپیوتر و کاربران عادی مسائل امنیتی را رعایت نمی کنند که به سادگی می شود به سیستم نفوذ کرد و یا در آن اختلال ایجاد نمود. اما به یک دلیل، انجام این کار را صلاح نمی دانم و آن رعایت اخلاق حرفه ای در نرم افزار است. پرسید اخلاق حرفه ای رشته ما چیست؟ جوابش را به اختصار دادم اما بد ندیدم جوابی که به وی دادم را به صورت کاملتر اینجا ارائه کنم.
پزشکان هنگامی که فارغ التحصیل می شوند سوگندنامه ای (معروف به سوگند بقراط) را امضاء می کنند که در آن آنها متعهد به رعایت شئون رشته خود می باشند و تضمین می کنند که از هر امکانی که در اختیار دارند در جهت انجام کار خود استفاده کنند و حقوق بیماران خود را محترم بشمارند.
مهندسان عمران و ساختمان به یک نظام مهندسی متعهد می شوند که به اصول حرفه ای را در کار خود احترام گذاشته و به آنها التزام داشته باشند. وکلا نیز وضعیت مشابهی دارند. اما درنرم افزار جای چنین چیزی خالی است. اما این اخلاق حرفه ای در رشته ما چیست؟

1- رعایت قوانین حقوق مولفین (Copy right) در نرم افزار ها: اینکه خود را متعهد بدانیم نرم افزار دیگران را بدون اجازه آنان استفاده نکنیم.(حتی نرم افزارهایی خارجی که با قیمت ارزان در بازار موجود است چه برسد به نرم افزارهای تولید داخل که می دانیم حاصل دسترنج یکی مثل خود ماست.) این فقط شامل نرم افزار نمی باشد، انواع فیلم ها و موسیقی ها، نوشته ها، مستندات و ..... نیز که متعلق به یک شخص حقیقی و یا حقوقی هستند نیز شامل این قانون می گردند. (*)
2- عدم بکارگیری تخصصی که داریم در کارهای خرابکارانه: در اخبار همیشه می خوانیم که ویروس ها و یا هکر ها چقدر آسیب و ضرر به اقتصاد جهانی می زنند (در داخل با وجودیکه وضع بسیار خراب است اما چون هیچ ارگان مسوولی نداریم آمار این تخریب ها نداریم.) اینکار نه تنها به اقتصاد صدمه می زند بلکه باعث می شود که مشتریان نسبت به نرم افزار ها و کلا فنآوری اطلاعات و ارتباطات (ICT) بی اعتماد شوند، هزینه تولید نرم افزار بالا رود و اقبال به مکانیزه کردن سیستم ها کم شود.
3- رعایت محرمانگی اطلاعات: برخی از قدیمی ها اصطلاحی دارند تحت این عنوان که "پزشکان محرم بیماران هستند". این بدان معنی است که پزشکان در کارشان بایستی سعی کنند ضمن رعایت اخلاق شرعی در طبابت، اطلاعات بیمار خود را در اختیار دیگری قرار ندهند. در مورد نرم افزاری ها با توجه به اینکه به ریز اطلاعات یک سازمان در هنگام تجزیه و تحلیل آن و یا در هنگام پیاده سازی نرم افزار و یا بعد از آن در زمان پشتیبانی دسترسی دارند، رعایت این مساله مهمتر است. این که بدانیم اطلاعاتی که در اختیار ماست کاملا محرمانه است و نباید آن را در اختیار سایرین قرار دهیم (مخصوصا رقبای آن سازمان) و یا از این اطلاعات سوء استفاده کنیم. اهمیت این امر را در جمله معروف "اطلاعات قدرت است: Information is power" نمایان است.
4- انجام تعهدات به صورت کامل: برخی مواقع به دلیل تعریف نشدن ملاک های کیفی می توان برخی قسمت های نرم افزار را به صورت دیگری از تعهد اولیه و با مشکلاتی پیاده سازی کرد. با این امید که مشتری نفهمد! به دلیل نرم افزاری بودن اینگونه سیستمها که شخص دیگری به جز تولید کننده نمی تواند به سادگی از کار و خطوط برنامه تولید شده آگاه شود ، خود تولید کننده باید این تعهد را داشته باشد که خوب عمل کند. در غیر این صورت به جز زیان رساندن به مشتری و کم فروشی، اعتماد عمومی به یک نرم افزار را کاهش می دهیم.
5- عدم سوء استفاده از برخی روشها در نرم افزارها: نرم افزارها بایستی دقیقا آن چیزی که تعهد شده است را انجام دهند. استفاده از کد های مخفی (Hiden Code)، بمب های منطقی (Logical Bomb) برای دسترسی خارج از کنترل به نرم افزار و یا از کار انداختن ان در زمان مشخص و یا مواردی نظیر آن نباید توسط یک نرم افزاری متعهد، صورت گیرد.
6- عدم انتشار اطلاعات غلط: به دلیل اینکه نرم افزارها به خصوص نرم افزارهای تحت اینترنت و وب سایت ها می توانند توسط اشخاص مختلف مورد استفاده قرار می گیرند. بایستی از انتشار اطلاعات ناقص، شایعات، اطلاعات گمراه کننده و یا نادرست در این وب سایت ها اجتناب نمود. این دقیقا به شکل تعهد یک خبرنگار، رزنامه نگار و یا نویسنده است در انتشار اطلاعات کامل و صحیح.
7- عدم در اختیار قراردادن دانش خود به افراد تبهکار: یک نرم افزاری نباید تخصص خود را به هر شکلی که باشد در اختیار افراد و گروههای تبهکار و یا کلاهبردار قرار دهد تا زمینه سوء استفاده آنان را فراهم کند.
8- رعایت قوانین کشور و نظام های اجتماعی: یک نر م افزاری بایستی به قوانین و مقرارت محل زندگی خود تعهد داشته باشد و برخلاف آن عمل نکنند.
9- رعایت محرمانگی اطلاعات شرکتها: یک نرم افزاری که در یک شرکت کار می کند باید بداند همچنان که به محرمانگی اطلاعاتی مشتریان تعهد دارد بایستی نسبت به حقوق شرکتی که در ان کار می کند نیز احترام بگذارند و از بیرون بردن کد ها، اطلاعات، ابزارها و سایر اطلاعاتی که در اختیار وی قرار می گیرد به بیرون از محیط شرکت و یا ارائه آنان به دیگران خود داری کنند. اغلب دیده ام وقتی یک نیرو از یک شرکت به هر دلیلی خارج می شود ، بدون رعایت این مورد ، کد برنامه ها، مولفه ها و مدل ها را نیز از شرکت قبلی بیرون می برد که کار صحیحی نیست.
و مواردی از این دست که می توان در رشته های مختلف کاری به صورت عمومی تعریف کرد.

همین!

پانوشت:
(*) در این زمینه داستانی را مایلم نقل کنم که ترجیح می دهم در مطلبی دیگر به صورت جداگانه به آن بپردازم.

Ali Vahed | 3:17 PM

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

May 10, 2005 4:21 PM

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


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


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

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

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

در بخش هاي بعدي اين مطلب ادامه پيدا خواهد کرد.
همین!

Ali Vahed | 4:21 PM

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

March 11, 2005 8:56 PM

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


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


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


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

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

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

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

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 Development) : توسعه به صورت یک فرآیند سیستماتیک و مرحله بندی و لیبل گذاری هر بخش در هر مرحله. تقسیم سیستم به بخش های مختلف و تقسیم نیروها در بین پروژه های مختلف برای اجرای این بخش ها به صورت همزمان

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

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

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

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

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

همین!

Ali Vahed | 8:56 PM

فروشگاه تلفني، محمد ايزدي و چرخه تکاملي نرم افزار!

March 10, 2005 11:34 AM

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

اين دوست عزيز ما مدام فکر تازه و نياز تازه به ذهنش مي رسد و به ما مي گويد که سيستم فروشگاه تلفنيش را گسترش دهيم. صبر هم ندارد. ايده که مطرح مي شود بايد به سرعت انجام هم بشود. شرمنده اش هستيم که به دليل تعدد فعاليت ها و پروژه هاي همزمان گاهي (درست تر بگويم اغلب و اگر بخواهم صادق تر باشم هميشه!) نيازش را دير تر از زمان پيش بيني شده در نرم افزارش پياده کرده ايم! خدا ما را ببخشايد! خيلي دلم مي خواهد به وي بگويم که مرد مومن فعلا کافيست! همين سيستم را عملياتي کن بعد در ويرايش هاي بعدي سيستم را توسعه مي دهيم. حيف که آنقدر با انرژي و پر از انگيزه پيگير کارش است که دلم نمي آيد اين چرخه تکاملي را متوقف کنم! انصافا ايده هاي خوبي هم دارد! هر چند املايش همچين خوب نيست! (مثل خودم که هنوز نمي دانم کجا بايد از "ز" استفاده کنم کجا از "ذ"!؟)
همه اينها را گفتم که تاکيد کنم بر تکاملي بودن توليد يک نرم افزار. نبايد انتظار داشت يک سيستم کاملا کامل شود بعد از آن استفاده کرد. چون اين زمان هيچوقت فرا نخواهد رسيد. مايکروسافت با آنهمه عظمتش ويندوز و ساير نرم افزارهايش را در غالبي تکاملي و به صورت نسخه هاي متعدد ارائه مي کند . (حرکت ويندوز را ببينيد از ويندوز 3.1 به 95 به 97 به 98 به 98 ويرايش دوم به 2000 به XP به NET. , ....) چه برسد به ما که رادمانيم!
همين!

Ali Vahed | 11:34 AM

طرح يک مساله در سيستمهاي توزيع شده

February 17, 2005 6:05 PM

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

- سيستم هاي تک کاربره: در اين سيستمها نرم افزار و بانک اطلاعاتي روي يک کامپيوتر قرار مي گيرند. اين سيستم ها معمولا از نظر عملياتي ساده و با منظور هاي خاصي استفاده مي شوند. نمونه اين سيستمها مانند سيستم هاي عملياتي تک کاربره و يا اکثر سيستمهاي نظير تلفن گويا است.
- سيستم هاي چند کاربره روي يک شبکه محلي: در اين سيستمها که در يک محدوده جغرافياي کوچک که قابل شبکه بندي محلي است، داده ها در يک پايگاه اطلاعاتي با معماري (Client/Server) نگهداري مي شود و کاربران از طريق ايستگاههاي کاري خود و از طريق شبکه محلي (LAN) به سرور متصل مي شوند. در اين سيستمها برنامه کاربردي روي ايستگاههاي کاري و پايگاه داده روي سرور نصب مي شود. نمونه اي از اين سيستمها اکثر سيستمهاي اتوماسيون اداري، سيستمهاي عملياتي چند کاربره و شبکه اي است.
- حالت سوم زماني است که کاربران از نظر جغرافيايي با يکديگر فاصله داشته باشند و نتوان يک شبکه محلي بين کاربران ايجاد کرد. در اين مورد چه بايد کرد؟
براي مثال زماني که مي خواهيم يک سيستم را در تمام يک کشور و در مراکز مختلف استفاده کرد و بين مراکز تبادل اطلاعاتي انجام داد چه بايد کرد؟
اينجاست که مساله پيچيده مي شود و جايگاه سيستمهاي توزيع شده مطرح مي شود. براي حل اين مساله پارامترهاي مختلفي را بايد در نظر گرفت. نوع اطلاعات، سطح امنيتي، حجم تبادل اطلاعات، يک طرفه، دو طرفه و يا چند طرفه بودن تبادل اطلاعات، داراي سرور مرکزي بودن يا نبودن مدل اطلاعاتي، نوع کاربران، امکانات سخت افزاري هر محل، امکانات تبادل اطلاعات بين طرفين، تعداد کاربران و ......
يک مهندس نرم افزار بايستي با در نظر گرفتن همه اين پارامتر ها راه حل خود را ارائه دهد. براي توسعه يک سيستم با چنين توزيع شدگي مي توان حداقل 6 الي 7 راه حل فني مختلف بر اساس پارامترهاي ذکر شده ارائه نمود.
براي مثال سعي مي کنم در حد امکان مساله مورد ذکر براي آن سازمان و راه حل هاي پيشنهادي رادمان را توصيح دهم تا به عنوان يک مورد مناسب روشن کننده ابعاد انتخاب مدل در سيستمهاي توزيع شده باشد.
سازمان مورد نظر يک مرکز در تهران دارد و در استانهاي مختلف کشور هم مراکزي دارد که به انجام ماموريت هاي منطقه اي در حوزه جغرافيايي خود مي پردازند.
هر منطقه اطلاعات خاص خود را توليد و در سيستم خاص خود وارد مي نمايد. اين اطلاعات نه تنها مور استفاده مرکز بلکه مورد استفاده ساير مناطق نيز مي باشند. بنابراين اين اطلاعات بايد به نحوي در کل کشور توزيع مي گردد.
حجم اين اطلاعات و نيز ترافيک بالاي انتقال اطلاعات بين استانها و مرکز انتخاب روشهاي مبتني بر انتقال اطلاعات از طريق خطوط تلفن (Dial Up ) را غير منطقي مي نمايد.
از سوي ديگر عدم وجود يک شبکه مطمئن و پر سرعت بين مراکز امکان استفاده از برخي روشهاي نرم افزاري که بر روي شبکه هاي WAN کار مي کند را از بين مي برد.
حال چه بايد کرد؟ مساله اساسی در این طرح ایمنی و امنیت ،قابلیت اطمینان، سرعت ، گسترش پذیری، قابلیت انتقال و ... می باشد.
.
.
.
...
پيشنهاد رادمان اين است که ....... {قبل از اینکه راه حل را ارائه کنم یک مقدار فکر کنید!! اگر شما جای رادمان بودید چه می کردید!؟ لازم به ذکر است راه حل بهینه ای که ضامن مسائل کمی و کیفی این سیستم توزیع شده باشد توسط رادمان تهیه شده و به سازمان مورد نظر ارسال شده است. }


همین!

Ali Vahed | 6:05 PM

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

November 9, 2004 12:58 PM

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

نرم افزار ها را بسته به شيوه توليد مي توان به دو گروه تقسيم نمود: نرم افزارهاي سفارشي و بسته هاي نرم افزاري
1- نرم افزارهاي سفارشي
2- بسته هاي نرم افزاري (Package)

در نرم افزارهاي سفارشي تمام عمليات تحليل، طراحي و پیاده سازی به شیوه مرسوم آن اجرا می شود و سیستم بر اساس شرایط موجود و نیازهای مشتری استفاده کننده ساخته می شود. در حالیکه در بسته های نرم افزاری ، تولید کننده با نیاز سنجی عمومی از کل بازار و در نظر گرفتن نیازهای مشتریان متفاوت اقدام به توسعه سیستمی می نماید که بتواند نه الزاما همه بلکه اکثر نیازهای مشتریان را پوشش دهد. در نرم افزارهای سفارشی، سیستم تولیدی منطبق بر نیازهای یک مشتری است در حالیکه در بسته های نرم افزاری این مشتری است که باید نیازهای خود را با سیستم جدید منطبق نماید. با این وجود یک بسته نرم افزاری خوش ساخت این امکان را برای مشتری فراهم می کند که بتواند تا حدودی نیازهای خود را در سیستم اعمال نماید. به عبارت دیگر با به کار گیری ابزارهای عمومی و ساخت قسمت های پویا در بسته های نرم افزاری این امکان فراهم می شود که هر مشتری با نیاز خود سیستم مورد نیاز خود را یا خود شخصا تنظیم نماید و یا این کار توسط فروشنده صورت می گیرد.
اما چه زمانی تولید کننده موظف به ارائه سورس برنامه به مشتری است؟ در هیچ زمانی مگر آنکه در قرارداد فروش مشخص شده باشد. به عبارت دیگر در حالت فروش سیستم به صورت یک بسته نرم افزاری عمومی طبیعتا سورس همراه آن نست چون اگر چنین باشد یعنی شما عملا به خریدار این امکان را داده اید که نرم افزار شما را در جای دیگری هم به فروش برساند. حتی در حالتی که نرم افزار به شکل سفارشی هم تولید می گردد، تولید کننده الزامی به تحویل سورس ندارد. تولید کننده صرفا موظف است که سیستم را مطابق نیازهای فنی و اطلاعاتی مشتری تولید کند. اما با این وجود در زمانی که در قرارداد صریحا مشخص شده باشد که سورس برنامه نیز بایستی به خریدار تحویل گردد فروشنده و یا تولید کننده می تواند با دریافت مبلغ بیشتری نسبت به فروش فقط سیستم این کار را انجام دهد. اما این مبلغ آنقدر زیاد است که عملا خریدار رغبت چندانی به خرید سیستم ندارد!
نکته حائز اهمیت دیگر آنکه معمولا سورس یک برنامه را نمی توان به صورت کامل به مشتری تحویل داد. با توجه به روشهای رایج تولید نرم افزار اکثر تولید کنندگان از کتابخانه ها (Library) و یا مولفه ها (Component) هایی استفاده می کنند که یا توسط خودشان تولید نشده است و از تولید کننده دیگری خریداری کرده اند که طبیعتا طبق قانون رعایت حق مولف (Copyright) صرفا در موارد مشخصی مجاز به ارائه آن به سایرین می باشند و یا توسط خودشان ساخته شده است که محصولی به جز محصول نهایی فروش رفته محسوب می شود و مشتری باید به صورت جداگانه آنها را خریداری نماید.
از طرف دیگر حتی اگر سورس کد برنامه به صورت کامل در اختیار مشتری قرار بگیرید این کد بدون مستندات آن عملا به یک چیز بی ارزش تبدیل می شود. معمولا سیستمهای نرم افزاری از تعداد خطوط برنامه زیاد و یا شیوه های پیچیده برنامه نویسی تشکیل شده اند و پر هستند از تکنیک ها، ساختمان داده ها و الگوریتم های متنوع. و این در حالی است که مستند سازی در اکثر پروژه های نرم افزاری به ندرت صورت می گیرد و حتی اگر چنین شود مستندا معمولا بی فایده و صرفا برای خالی نبودن عریضه تولید شده اند.
تنها در پروژه هایی که با یک متدولوژی خوب استاندارد و توسط Case Tools های مناسب تولید شده باشند حاوی مستنداتی هستند که برنامه را برای اشخاص دیگری به جز تولید کنندگان و حتی برای خود آنها در مراجعات بعد خوانا می کند.
حتی اگر سورس پروژه به صورت کامل و همراه مستند سازی به خریدار عرضه شود تجربه نشان داده است که هزینه تغییر سیستم تولید شده توسط شخصی دیگر کمتر از تولید مجدد یک سیستم جدید نیست!
بنابراین با جمع کردن همه این موارد می توان به چنین نتیجه گیری رسید که در هنگام خرید نرم افزار حتی اگر فروشنده حاظر به فروش سورس کد خود

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

داستانی است که در مواقعی که مشتری چنین نیازی دارد همیشه مطرح می کنم :"در زمانهای قدیم و در ایام برده داری ، یک روز شخصی را دیدند که مادر خود را به بازار برده دار ها می برد. گفتند مادرت را کجا می بری؟ گفت می برم برای فروش!! گفتند : آخر آدم حسابی چه کسی مادر خود را فروخته است؟ این چه کاری است که تو می کنی؟ گفت: یک قیمتی روی مادرم می گذارم که هیچکس نخرد!!!" حال ما هم چنین عمل می کنیم. شما سورس کد برنامه ما را می خواهید مشکلی نیست. الساعه تقدیم می کنیم ولی قیمتش می شود 100 میلیون تومان! اگر خواستید بخرید. من نه تنها قول می دهم سورس را با مستندات و با آموزش به صورت کامل به شما عرضه کنم بلکه قول می دهم آن را از روی کامپیوترهای خودمان هم پاک کنیم! اصلا قول می دهیم دیگر هیچ نوع نرم افزاری تولید نکنیم و از این بازار خارج شویم!!

همین!


Ali Vahed | 12:58 PM

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

October 31, 2004 6:02 PM

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


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


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


همين!

Ali Vahed | 6:02 PM

وضعیت پروژه های نرم افزاری در ایران

October 8, 2004 11:43 PM

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

Ali Vahed | 11:43 PM