5. انواع نرم افزار های تجاری


هنگامی که صحبت از این می‌‌شود چگونه یک نرم‌‌افزار تجاری را طراحی کنیم و از چه الگوهایی استفاده کنیم، این مهم است که تشخیص بدهیم نرم‌‌افزارهای تجاری همگی متفاوت هستند و این مشکلات متفاوت نیازمند برخوردهای متفاوت هستند. من تعدادی زنگ هشدار دارم و هنگامی که مردم می‌‌گویند "همیشه این را انجام بده” به صدا در می‌‌آیند. برای من بیشتر چالش (و علاقه‌‌مندی) در طراحی، دانش درباره جایگزین‌‌ها و قضاوت در مورد استفاده از یک جایگزین به جای دیگری است. تعداد زیادی از جایگزین‌‌ها برای انتخاب از بین آن‌‌ها وجود دارد، اما من در بین تمام این جایگزین‌‌ها سه گزینه را انتخاب خواهم کرد.
    یک B2C (business to costumer) فروشگاه آنلاین در نظر بگیرید: مردم با کمی شانس و یک کارت خرید برای خرید جستجو می‌‌کنند. برای چنین سیستمی ما نیاز به این قابلیت داریم که تعدادی زیادی از کاربران را مدیریت کنیم بنابراین راحل‌‌مان را نه تنها باید عاقلانه موثر باشد. در مورد منابع استفاده شده باید بصورتی باشد که برای باگذاری بیشتر بتوان با افزایش منابع مشکل را حل کرد. منطق دامنه‌‌ها برای یک نرم‌‌افزار باید کاملا قابل فهم باشد: سفارش گرفتن، برخی از محاسبات ساده قیمت گذاری حمل نقل و اطلاعیه‌‌های حمل و نقل. ما می‌‌خواهیم هرکسی قادر به دسترسی آسان به سیستم باشد بنابراین این مفهوم بدست می‌‌آید که بوسیله یک وب‌‌سایت عمومی ارائه بشود که می‌‌تواند با طیف وسیعی از مرورگرها مورد استفاده قرار گیرد. منابع داده شامل یگ پایگاه داده برای نگهداری درخواست‌‌ها و شاید چندین ارتباط با سیستم لیست برای کمک به موجود بودن و ارائه اطلاعات می‌‌باشد.
    مقایسه کنید این را با یک سیستم که بصورت اتوماتیک پروسه قرارداد اجاره را انجام می‌‌دهد. از بعضی جهت‌‌ها این سیستم بسیار ساده‌‌تر از یک فروشگاه B2C است به این علت تعداد کاربران در یک لحظه زمانی بسیار کمتر از صد نفر است. در حالی که از لحاظ منطق تجاری پیچیده‌‌تر است. محاسبه ماهانه پرداخت‌‌ها در یک قرارداد، مدیریت کردن مواردی مانند پرداخت‌‌های پیش از موعد و قبل از موعد و بررسی اعتبار یکسری از اطلاعات همانند اینکه آیا یک اجاره از قبل رزرو شده است. تمام این‌‌ها وظایف پیچیده‌‌ای هستند. از آنجایی که بیشتر رقابت در صنعت اجاره از تنوع محدود قراردادهایی که در گذشته بسته شده‌‌اند شکل می‌‌گیرد. یک مدل تجاری پیچیده مانند چیزی که گفته شد بسیار چالش برانگیز است، زیرا قوانین بسیار دلبخواه هستند.
    چنین سیستمی پیچیدگی بیشتری در رابط کاربری (UI) دارد. حداقل به این معنا می‌‌باشد که از HTML بیشتری استفاده شده است که نشان دهنده یک صحفه پیچده‌‌تر است. معمولا  سیستم‌‌هایی که دارای UI با پیچیدگی بالاتری می‌‌باشند درخواست‌‌های بیشتری از کاربر دارند که شاید یک با HTML ساده نتوانیم به شکل دلخواه خود در سمت کلاینت برسیم. هرچه تعامل کاربر با سیستم بیشتر شود شرایط برای انجام تراکنش‌‌های پیچیده‌‌تر مهیا می‌‌شود. رزرو یک اجاره ممکن است یک یا دو ساعت طول بکشد در این مدت کاربر در یک تراکنش منطقی قرار دارد. ما همچنین یک طرح پیچیده از پایگاه‌‌داده که می‌‌تواند شامل دویست جدول و اتصالاتی به بسته‌‌ها برای ارزش‌‌گذاری دارایی و قیمت گذاری است می‌‌بینیم.

 


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

 


نظرات

8. ساختار الگو های طراحی

ساختار الگو ها در طراحی سیستم های نرم افزاری و مسائل پیاده...

ادامه مطلب

7. الگو های طراحی نرم افزار

هر الگویی یک مشکل را تعریف می کند که به طور مرتب...

ادامه مطلب

6. کارایی نرم افزار های تجاری

تاملی درباره کارایی سیستم های نرم افزاری و تصمیماتی که بخاطر کارایی...

ادامه مطلب

5. انواع نرم افزار های تجاری

نرم افزارهای تجاری همگی متفاوت هستند و این مشکلات متفاوت نیازمند برخوردهای متفاوت هستند


مقالات بیشتر در زمینه طراحی سیستم

پیشنهادهای فروش را شخصی‌سازی کنید و یک تجربه بهتری از مشتریان...

نرم افزار مدیریت ارتباط با مشتریان (CRM)

امکانات درخواست دمو

به سرعت سفارشات و فروش‌های خود را با ابزارهای تصویری ببندید...

نرم افزار مدیریت فروش و بازرگانی (OMS)

امکانات درخواست دمو