Fahim 9563 اشتراک گذاری ارسال شده در 16 شهریور، ۱۳۹۰ نویسنده : دن اورلاندو منبع: IBM Developer Works، سپتامبر 2009 ترجمه : کیومرث سلطانی اشاره: ماهنامه شبكه - نرمافزار به عنوان سرویس یا SaaS (سرنام Software as a Service) دیگر چندان مبحث نوینی در عرصه نرمافزار بهشمار نميرود، بلکه تعدد برنامههای ساخته شده با این روش و افزایش روز افزون محبوبیت آنها، روش مورد نظر را به یکی از متدهای اصلی در طراحی نرمافزار تبدیلکرده است... نرمافزار به عنوان سرویس یا SaaS (سرنام Software as a Service) دیگر چندان مبحث نوینی در عرصه نرمافزار بهشمار نميرود، بلکه تعدد برنامههای ساخته شده با این روش و افزایش روز افزون محبوبیت آنها، روش مورد نظر را به یکی از متدهای اصلی در طراحی نرمافزار تبدیلکرده است. این مقاله نیز با هدف روشنتر ساختن طراحی این مدل از برنامهها نوشته شده است. مؤلف در توضیحی کوتاه مقاله را این گونه توصیف میکند: «تواناییهای اساسی برای اطمینان از اینکه پروژههای نرمافزار به عنوان سرویس سر وقت و طبق بودجه کامل شوند.» اورلاندو در این مقاله سعی کرده تا ده نکته اساسی را برای ایجاد برنامههای SaaS بیان کند. نکاتی که شاید در طراحی نرمافزارهای مبتني بر دسکتاپ نیز مفید واقع شوند. محبوبیت نرمافزارهایی که به جای برنامههای مبتني بر دسکتاپ بهصورت سرویسهای آنلاین تهیه میشوند، روزبهروز و با نرخی نمایی افزایش مییابد. من با تعدادی از کسب وکارهایی که حول SaaS متمرکز شدهاند، در ارتباط بودهام و توانستم در طول این مدت، ده المان کلیدی را در توسعه نرمافزار گردآوری کنم. این موارد میتوانند مشخص کنند که یک برنامه SaaS موفق، در بسیاری از موارد قابل رسیدن به مرحله عرضه است یا خیر. هدف از این توصیهها فراهم کردن یک دید جامع و روشن نسبت به توسعه مبتني بر SaaS است. 1- UXD را ارزشمندترین داراییتان سازید. با اختراع اینترنت توجه به تجربه کاربری(User Experience) عملاً از دستور کار خارج شد. اما در سالهای اخیر، دوباره موجی از علاقهمندی به این ویژگی مهم نرمافزارهای موفق SaaS به راه افتاده است.نمونه بارز و طلایه دار این بازگشت مفهومی است که در ابتدا با نام وب 2 نقل محافل شد و پس از آن با واژه پرمعناتر RIA (سرنام Rich Internet Application) مورد خطاب قرار گرفت. من بهعمد UXD (سرنامUser-Experience Design) را در شماره یک قرار دادم، زیرا تجربه کاربري تنها ویژگی قابل تشخیصی است که باعث میشود تا یک کاربر بی درنگ برنامهای را به برنامه دیگر ترجیح دهد. شکل 1 و 2 دو تکنیک جالب UXD را نشان میدهد. شکل 1 مفهومی را بیان میکند که با عنوان «روی صفحه بمان» شناخته میشود. البته، از آنجا که برنامه نشان داده شده، یک برنامه RIA کلاینتی سبک است که با استفاده از Adobe Flex ساخته شده است، بهطور مشخص در اینجا صفحهای وجود ندارد. اما به هر حال، تکنیک مذکور هنوز قابل استفاده است. سناریوی به کار رفته در این مثال، کاربری است که میخواهد تنظیمات حساب شخصی خود را تغییر دهد. به جای ترککردن حالت (یا صفحه) فعلی برنامه، یک پنجره رویی نمایش داده شده که به کاربر اجازه میدهد پس از انجام تغییرات لازم، پنجره را بسته و به کار قبلی خود برگردد. برای مشاهده این محتوا لطفاً ثبت نام کنید یا وارد شوید. ورود یا ثبت نام شكل 1- مثالی از تکنیک UXD با عنوان «روی صفحه بمان» شکل 2 نمایی نزدیکتر از پنجره باز شده در شکل 1 را در دو حالت نشان میدهد. این مثال، اختصاصاً فرض میکند که کاربر میخواهد اطلاعات مربوط به شرکت را تغییر دهد و به همین دلیل نوار عنوان مرتبط را انتخاب کرده است. پنجره 1 حالت پنجره را در ابتدای نمایش آن نشان میدهد. شکل2 نیز حالت پنجره را بعد از کلیک روی نوار Company Information نشان میدهد. این تکنیک به دلیل شیوه بالا و پایین رفتن پنلها بعد از انتخاب نوار عنوان های مربوط به هریک با نام منوهای آکاردئونی شناخته میشوند، این خصوصیت باعث تقویت و بهبود تجربه کاربری ميشود، زیرا انتخاب و تغییر مقادیر مختلف را در حالتی که تعداد زیادی از تنظیمات دستهبندی شده موجود هستند برای کاربر ساده میسازد. برای مشاهده این محتوا لطفاً ثبت نام کنید یا وارد شوید. ورود یا ثبت نام شكل 2- پنلهای آکاردئونی 2- با تغییر الزامات هماهنگ شويد. وقوع یک چیز در توسعه نرمافزار حتمی و غیرقابل اجتناب است: مشتریان، خریداران یا مالکان محصول، الزامات و اهداف پروژه را تغییر خواهند داد. بسیار مرسوم است که بعد از انجام تمام مراحل طراحی، برنامهریزی، رسمنمودار و ساخت نمونه اولیه، به شما گفته شود که انتظارات آنها از پروژه تغییر یافته است. بيشتر مدیران پروژه به شیوههای سنتی تعلیم یافتهاند و بخشی از این تربیت شامل مقاومت در برابر تغییر است. این موضوع باعث میشود تا هر چه قدر به تاریخ عرضه رسمی محصول نزدیکتر میشویم، به طرز خطرناکی سطح «کتککاریها» نیز افزایش یابد. توسعه نرمافزار آنقدر سریع تغییر میکند که تغییر چندباره متدولوژی مدیریت پروژه در مدت زمان توسعه نمونه اولیه آن، اصلاً چیز عجیبی نيست. پس بهتر است تا برای پیادهسازی متدولوژیهای توسعه جدید یا انواع دیگری از متدولوژی موجود آماده شويد. تعامل انسان با کامپیوتر در مطالعهای که توسط Forrester Research روی تعامل انسان با کامپیوتر انجام شد، پاسخهای سوژههای مورد بررسی نشان داد که قابل استفاده بودن اصلیترین دلیلی است که آنها یک برنامه را به دیگری ترجیح میدهند. در هر پروژه SaaS موفقی که من میشناسم، آزمایش«قابل استفاده بودن» چیزی است که همواره در جلوی فرآيند اصلی طراحی برنامه قرار داشته است. حتی بعضی شرکتها تا جایی پیش رفتهاند که پرسشنامههایی را از تصاویر استاتیک برنامه در اختیار یک جمعیت نمونه قرار میدهند. این کار به این دلیل است که انجام بازبینیهای عمده در نرمافزار میتواند بسیار پرهزینه باشد. در نظر گرفتن چند معیار اضافه هنگام طراحی یا در فاز نمونه اولیه باعث ميشود تا شرکت میلیونها دلار صرفهجویی کند. گروه توسعه همچنین میتواند گرایشها، خصایص، ویژگیها، علاقهمندیها و مشکلات مرتبط با تعامل کامپیوتر و انسان را در بازاری که آنها برای آن توسعه را انجام میدهد، مشخص سازد. 3- استانداردهای باز را بپذیرید. شرکتهایی که بر پایهSaaS بنا شدهاند باید پذیرش استانداردهای باز را در دستور کار خود قرار دهند، زیرا سازگاری با دستگاهها، پلتفرمها، سرویسها و برنامههای وب دیگر، رابطه مستقیمی را با نوشتن کدهای کمتر در آینده و پذیرش بیشتر محصول توسط مصرفکنندگان به دنبال دارد. کاربران نسبت به برنامههای SaaS که به آنان اجازه میدهد تا چندین کار را به انجام برسانند، گرایش بیشتری نشان میدهند.بهعنوان مثال، برنامه TweetDeck يک برنامه چند پلتفرمي است که از APIهاي مختلف شبکههاي اجتماعي و به اشتراکگذاري عکس در يک رابط استفاده ميکند(شکل 3). TweetDeck سریعاً به یکی از محبوبترین کلاینتهای نوع خود تبدیل شد، عموماً به این دلیل که کاربران میتوانند وضعیت دوستان خود را بدون تغییر برنامه مشاهده کنند. در صورت استفاده از ابزارهایی که براساس استانداردهای باز بنا شدهاند، هزینههای مالی کاهش قابل توجهی پيدا ميکند. دلیل این امر نیز حذف هزینه مجوزها و کاهش هزینه منابع است. دليل مورد دوم شروع اولیه از جایگاهی جلوتر از صفر مطلق است. بهاین ترتیب، شما میتوانید منابع را به تغییر سورس کد برای برآورده ساختن نیازهای کسب و کار خود اختصاص دهید. برای مشاهده این محتوا لطفاً ثبت نام کنید یا وارد شوید. ورود یا ثبت نام شكل 3- برنامه محبوب TweetDeck از API های باز Facebook و Twitter بهصورت همزمان استفاده میکند. بهعنوان مثال، سازندگان TweetDeck میتوانند به جای کار روی API های مورد استفاده که بسیار طاقتفرسا است، تجربه کاربري غنیتری را به برنامههاي خود بيافزايند. در نظر بگیرید که اگر شبکههاي اجتماعي مورد استفاده برای API های خود از مردم پول طلب میکردند، چه اتفاقی میافتاد؟ TweetDeck احتمالاً مجبور میشد تا از مردم ماهیانه مبلغی را بابت استفاده از این نرمافزار طلب کند تا بهاين وسیله بتواند به سايتهاي خدماتدهنده مبلغ استفاده از API های خود را بپردازد یا شاید کاربران مجبور میشدند تا به این دو، پولی را بابت استفاده از TweetDeck بپردازند. اثرات این موضوع میتوانست برای سايتهاي خدمات دهنده TweetDeck زیان فراوانی را به همراه آورد و البته بهيقينTweetDeck دیگر بهعنوان یک برنامه SaaS محسوب نمیشد. 4- قبل از طراحی WireFrame را انجام دهید. وایرفریم(WireFrame) یک تجسم مفهومی از حالتی خاص در رابط بصری یک برنامه از نقطه نظر کارکرد است (شکل 4). دقت کنید که هیچ طراحی تجملیاي در آن مطرح نيست. این کار برای منحرف نشدن از مسیر اصلی و تمرکز روی وظایف اساسی برنامه انجام میگیرد. بهاين ترتیب، سعی میشود تا در مرحله اول المانهای طراحی در نظر گرفته نشود. هنگاميکه کارکرد اصلی برنامه برقرار شد، گروه طراحی میتواند به کاملکردن طرح بپردازد. اما نرمافزار باید قبل از جذاب بودن بتواند کار کند. برای مشاهده این محتوا لطفاً ثبت نام کنید یا وارد شوید. ورود یا ثبت نام شكل 4- وایرفریم میتواند تصوری مفهومی از رابط بصری را فراهم سازد. این شیوه ارتباط بسیار نزدیکی با UXD، نخستين المان یک SaaS موفق دارد. تفاوت در اینجا است که برای موفقشدن یک نرمافزار در قالب سرويس، UXD باید بخشی از چرخه حیات کلی توسعه نرمافزار باشد، یعنی از مفهوم تا تولید. وقتی نوبت وایرفریم کردن میرسد، با دو مشکل مواجه ميشويم که باعث موفق نشدن SaaS میشوند: - گروه به سرعت به سراغ طراحی میرود و بهاين ترتیب، ناگهان تم طراحی برنامه به عنوان بخشی از فرآيند وایرفریمینگ در میآید. این موضوع شاید عمدتاً به خاطر علاقه سرمايهگذاران به مشاهده چیزی زیبا و جذاب در مقایسه با برنامهای در حال کار و عملیاتی باشد. - در برنامه وضعیتهای کلیدی از کلکسیون وایرفریم کردن جا میمانند (یعنی تنها بخشهایی از برنامه وایرفریم میشوند). نکته جالب توجه اين است که دلیل دوم بیشترین خسارت را به پروژههای SaaS وارد میسازد. جذاب ترین نکته در مورد وایرفریمینگ این است که شما میتوانید از آنها برای نمایانکردن حفرههایی که در درک خواستههای محصول وجود دارد، استفاده کنيد. آنها برای نمایان کردن نقصهای مرتبط با معماری هسته، قبل از شروع توسعه مورد استفاده قرار میگیرند. با در نظر داشتن این موضوع، درک اینکه چگونه فرآيند وایرفریمینگ میتواند صرفه جوییهای فراوانی را از نظر زمان و منابع در کسب و کار انجام دهد، چندان دشوار نیست. یک مجموعه کامل از وایرفریمها ممکن است بیش از صد سند را شامل شود. هر کدام از آنها باید با توضیحی یک یا دو صفحه ای(دستکم) همراه شود. این توضیحات به سهامداران کمک میکند تا با مشاهده آنها از کلیت موضوع آگاهي مييابند. دقت کنید که این وایرفریمها قبل از اینکه از زیر دست سهامداران بیرون بیایند به بازبینی نياز خواهند داشت. بهتر است اختلافات در خلال وایرفریمینگ، نه پس از پايان کدنویسی بدنه اصلی برنامه حل شود. 5- SaaS را با زیرساختهای کلاود مجهز کنيد. در نگاه اول بیان این موضوع که زیرساختهای شبکه یک SaaS را ميسازد یا تخریب ميکند، ممکن است کمی سادهانگارانه به نظر ميرسد. اما اکثر برنامههای SaaS موجود در وب، روی سخت افزارهایی نامناسب که به شبکه هایی با زیرساخت های غیر قابل گسترش متصل اند، بنا شدهاند. ما بهعنوان توسعهدهندگان، به سيستمهاي کلاود با قابليت مقياسپذيري خودکار دسترسی داریم که معمولاً با عنوان زیرساخت به مثابه سرویس یا IaaS شناخته میشوند. با این حال پذیرش فناوريهای ممتاز این چنینی برخلاف تصور، بسیار کند پیش میرود. این درک تدريجي شاید بتواند به نبود دانش در مورد موضوع نسبت داده شود. بهعنوان مثال، Amazon EC2(سرنامAmazon Elastic Compute Cloud) پتانسيل زيادي براي فراهم کردن صرفهجوهاي فراوان براي شرکتهايي که از SaaS استفاده ميکنند، دارد. اما فقدان دانش کلی در مورد زیرساخت وب سرویس آمازون باعث میشود تا بسیاری در همان سیستمهای قدیمی گیر بیفتند. زیرا این سیستمهای قدیمی همان چیزی است که آنها میشناسند و با آن آشنا هستند. با این حال، افزایش ثابت پهنای باند ارائهشده توسط ISPها میتواند تضمینی برای این موضوع باشد که هر برنامه SaaS موفقی باید به امکانات شبکهای پیشرفته در زمینه گسترش خودکار منابع بر مبناي تقاضا مجهز باشد. قدرت جامعه وقتی یک پروژه نرمافزاری تمام میشود و شرکت و یا افرادی که نرمافزار را توسعه دادهاند، با جامعه اپنسورس همکاري ميکنند. این همکاری میتواند بهصورت کتابخانههای کدی باشد که برای دست یابی به یک امکان منتشر میشوند یا مجموعهای از کامپوننتهای نرمافزاری قابل استفاده دوباره که میتوانند در جاهای دیگر استفاده و تغییر یابند. این همکاری همیشگی با ابزارهای اپن سورس باعث رشد محیطی شده است که در آن فناوري بتواند بهصورت آزاد و با نرخی سریع و پیوسته ارتقا یابد. ادامه دارد ... لینک به دیدگاه
ارسال های توصیه شده