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

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

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

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

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

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

همین!

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

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

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

در اين نوشته برخي مشخصات عمومي برنامه هاي تحت وب (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 باعث غنای بهتر و یا استفاده مناسب تر هم برنامه های تحت ویندوز و هم برنامه های تحت وب شده است.
در پست بعد تلاش می کنم یک جمع بندی بر این مبحث داشته باشم.
همین!

نوشته قبلی بازخوردهای خوبی داشت، از 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) که در آنها کاربر صرفا یا یک تقاضای مشخص را مطرح می سازد و یا به حجم محدودی از اطلاعات دسترسی دارد.

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

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

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

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

همین!

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

همین!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

همین!

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

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

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

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

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

همین!

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

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

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

همین! 

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

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

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