کیفیت در نرم افزار واقعاً به چه معناست!؟

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

پرسمن «کیفیت نرم افزار» را در مهندسی نرم افزار به صورت زیر تعریف کرده است :

In the context of software engineering, software quality measures how well software is designed (quality of design), and how well the software conforms to that design (quality of conformance)

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

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

نیازمندی ها

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

طراحی

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

پیاده سازی

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

تست

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

توزیع و استقرار

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

آموزش و پشتیبانی

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

farasun.wordpress.com

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

(1) : IEEE 610.12-1990 Standard Glossary of Software Engineering Terminology

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

Advertisements

فریم ورک های تست واحد برای دات نت

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

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

NUnit : یک فریم ورک خوش ساخت کدباز است که از دنیای جاوا و با پورت کردن پروژه JUnit به دات نت بوجود آمد و با استفاده از Resharper و TestDriven.NET می توان از تمام قابلیت های آن در ویژوال استادیو بهره برد. مستندات خوبی دارد و مثال های بسیار زیادی برای آن در وب وجود دارد.

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

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

xUnit : فریم ورک کدباز جدیدی است که به توسعه دهندگان اجازه می دهد تا از TDD به سادگی هر چه تمام تر برای توسعه نرم افزار خود استفاده کنند. شامل ابزار GUI و خط فرمان برای اجرای تست هاست و می توانید با استفاده از TestDriven.NET یا Resharper در ویژوال استادیو از آن بهره ببرید.

Visual Studio Unit Testing Framework : راه حل مایکروسافت برای انجام آزمایش های واحد در دات نت است که در نسخه های Team System ویژوال استادیو 2005 به بعد وجود دارد. تست های واحد ساخته شده با این فریم ورک می توانند به صورت مستقیم درون ویژوال استادیو اجرا شوند یا با ابزار MSTest.exe از خط فرمان اجرا شوند.

farasun.wordpress.com

اگر به مبحث Unit Testing علاقه دارید پیشنهاد میکنم سری نوشته های آقای وحید نصیری در این مورد را حتماً بخوانید.

Visual Studio Unit Testing Framework : راه حل مایکروسافت برای انجام آزمایش های واحد در دات نت است که در نسخه های Team System ویژوال استادیو 2005 به بعد وجود دارد. تست های واحد ساخته شده با این فریم ورک می توانند به صورت مستقیم درون ویژوال استادیو اجرا شوند یا با ابزار MSTest.exe از خط فرمان اجرا شوند.

مستندات نیازمندی ها و نقش آن در موفقیت یک پروژه نرم افزاری

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

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

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

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

نیازمندی ها در سیستم های نرم افزاری به دو دسته نیازهای عملکری (Functional) و نیازهای غیر عملکردی (Non-Funcitonal) تقسیم می شوند. نیازهای عملکردی همان نیازهایی هستند که سیستم نرم افزاری برای برآورده کردن آن ها بوجود می آید. نیازهای غیر عملکردی آن هایی هستند که برای تضمین کیفیت نرم افزار بوجود می آیند. به نیازهای غیر عملکردی، نیازمندی های کیفیت نیز گفته می شود. مثالی از نیازمندی های غیر عملکردی می تواند ظاهر زیبای رابط کاربری، سرعت بالا، امنیت و استفاده آسان باشد.

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

چطور مستندات نیازمندی های یک نرم افزار را تهیه کنیم؟

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

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

مشکلات پیش روی جمع آوری نیازمندی های یک پروژه نرم افزاری

  • مشتری دقیقاً نمی داند چه می خواهد یا به چه چیزهایی برای رسیدن به هدفش نیاز دارد
  • مشتری یا کاربران نمی توانند نیازمندی های نرم افزار خود را مشخص کنند
  • ارتباط مداوم با مشتری و کاربران معمولاً پروسه زمان بری است
  • مشتری ایده ای از نحوه کارکرد سیستم های نرم افزاری ندارد
  • مشتری از تکنولوژی های توسعه نرم افزار خبر ندارد
  • مشتری همه نیازهایش را یکجا و به یکباره ذکر نمی کند و معمولاً پس از تولید نرم افزار یکسری نیازهای جدید پیدا می کند!

و مشکلاتی که شما می توانید در قسمت نظرت با ما به اشتراک بگذارید!

farasun.wordpress.com

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

تخمین هزینه های یک پروژه نرم افزاری

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

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

  • تخمین هزینه تا انتهای پروژه به تاخیر انداخته شود
  • بر اساس پروژه های مشابهی که قبلاً انجام شده، تخمین هزینه کنیم
  • از روش های تجربی و سلسله مراتبی استفاده کنیم

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

حالت دوم تا حد قابل قبولی خوب عمل می کند، اما اگر پروژه جاری کاملاً شبیه پروژه های انجام شده قبلی باشد. که معمولاً اینطور نیست. تجربه گذشته همیشه نشان دهنده راه خوبی برای نتایج آینده نیستند.

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

اندازه پروژه

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

پیچیدگی پروژه

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

زمان انجام پروژه

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

منابع انسانی

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

farasun.wordpress.com

حتماً عوامل دیگری در تخمین هزینه دخیل هستند که در این نوشته کوتاه به آن ها پرداخته نشد. سختی این کار اینجاست که برای تخمین مناسب هزینه های یک پروژه، شما بایستی ابتدا بتوانید اندازه، پیچیدگی و زمان مورد نیاز برای انجام پروژه را تخمین بزنید.

شما هم می توانید تجربه خود را با ما توسط فرم نظرات به اشتراک بگذارید.

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

مطالب مرتبط :

چگونه يک پروژه نرم افزاري را با موفقيت انجام دهيم!؟

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

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

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

حتماً قرارداد ببنديد

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

پروژه را تحليل کنيد

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

فاز طراحي را جدي بگيريد

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

پياده سازي

اگر فازهاي قبلي را به درستي انجام داده باشيد، در پياده سازي با مشکل حادي برخورد نخواهيد کرد. مستندات دو فاز قبلي مشخصات پياده سازي را تعيين مي کنند. اگر پروژه شما نياز به يک پايگاه داده براي ذخيره اطلاعات دارد (که در اکثر پروژه ها همينطور است)،ابتدا داده هايي که قرار است ذخيره کنيد را بر اساس مستندات فازهاي قبلي شناسايي کنيد. اگر مي توانيد نمودار روابط بين موجوديت ها يا ERD و Data Model را براي درک بهتر بانک اطلاعاتي سيستم رسم کنيد. براي بانک اطلاعاتي خود يک RDBMS مناسب انتخاب کنيد. وقتي به طور مثال SQLite يا Access نياز شما را برطرف مي کنند، بيخودي خود را درگير پيچيدگي هاي SQL Server يا Oracle نکنيد.

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

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

در آخر

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

اگر سئوال یا ابهامی دارید در کامنت های همین مطلب ذکر کنید تا به آن پاسخ داده شود.

چگونه یک رابط کاربری مناسب و استاندارد طراحی کنیم؟

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

به علت طولانی بودن مطلب، این مقاله را می توانید در قالب PDF دانلود کنید +
برای داشتن یک طراحی خوب در زمینه رابط کاربری، ابتدا باید کاربران نرم افزار را شناسایی کنید، سن، سطح سواد، نیازها و کارهایی که می خواهند با نرم افزار انجام بدهند را در نظر بگیرید. به طور مثال وقتی می خواهید نرم افزاری برای گروه سنی کودکان تولید کنید باید طراحی را با توجه با سن کاربران انجام دهید. پس از مشخص کردن کاربران و مشخصات آنان، سناریوهای هر کاربر را که در بخش تحلیل ایجاد شده اند را مورد بررسی قرار دهید و Use caseهای هر کاربر را در نظر بگیرید تا مجموعه ای از اشیاء و اعمال مربوط به آن ها مشخص شوند. این اجزاء معمولاً مبنایی برای ایجاد صفحات (منظور از صفحه، هر جزئی از رابط کاربری است که یکسری اجزای مربوط به هم را در کنار هم قرار می دهد، نه فقط صفحات وب) رابط کاربری می شوند که شامل طراحی گرافیکی، آیکون ها، متن ها، توضیحات صفحه و منوها می باشد.

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

  • استفاده از عنوان های با معنی برای اجزای صفحه : برای اجزای رابط کاربری خود عنوان های مناسبی انتخاب کنید تا کاربر منظورتان را با یک نگاه بفهمد. برای منو ها و دکمه ها عنوان های با معنی بگذارید که کاری که انجام می دهند را در یک یا دو کلمه توصیف کند. عنوان های بی معنی و طولانی برای کاربران ناخوشایند هستند.
  • استفاده از آیکون های مناسب و با معنی : هرجایی که قرار است از آیکون استفاده کنید، به جز زیبایی ظاهر آن، به اندازه آن در واحد پیکسل و با معنی بودن آن هم توجه کنید. آیکون ها باید نماد مشخصی از تابعی باشند که قرار است آن را صدا بزنند. هرجا که می توانید به جای منوها از شکلک ها استفاده کنید، چون کاربران ارتباط بهتری با شکلک ها برقرار می کنند تا منوهای تو در تو.
  • جزئیات تکنیکی از دید کاربر پنهان باشد : شما نباید کاربر را درگیر مسائل تکنیکی کنید، حتی اگر این مسایل از نظر شما مسایل راحت و پیش پا افتاده ای باشند. به طور مثال شما نباید کاربر را مجبور کنید که یک کلید خاص را در رجیستری ویندوز انتخاب کند!
  • در هر صفحه پیش فرض هایی داشته باشید : در هر صفحه باید چند عمل پیش فرض برای کاربر تعریف کنید. اگر در حال گرفتن اطلاعات از کاربر هستید، باید دکمه پیش فرضی برای کاربر قرار دهید که با کلیک روی آن تمام اطلاعات آن فرم پاک یا به اصطلاح Reset شود. یا به طور مثال دکمه های تایید یا OK در خیلی از فرم ها به عنوان پیش فرض آن فرم قرار داده می شوند تا کاربر با زدن دکمه Enter قادر به اجرای تابع مورد نظر باشد.
  • کاهش بار فکری کاربر : هر چه کاربر بیشتر مجبور باشد بخاطر بسپارد، ارتباط او با نرم افزار دارای خطای بیشتری خواهد بود. یک رابط کاربری مناسب به حافظه کاربر متکی نیست. هر زمانی که لازم شد، نرم افزار باید اطلاعات مورد نیاز را ذخیره کند و به هنگام نیاز آن اطلاعات را به کاربر یادآوری کند.
  • تعریف کلیدهای میانبر : سعی کنید کلیدهای میانبر مناسبی برای توابع پرکاربرد موجود در نرم افزار ایجاد کنید. این کلیدهای میانبر باید با اعمالی که قرار است انجام دهند به گونه ای مرتبط شوند که بخاطر سپردن آن ها توسط کاربران آسان باشد. برای مثال کلید Ctrl به علاوه حرف اول عنوان تابع مورد نظر. اگر برای کاری کلید میانبر استانداردی وجود دارد (مثل Ctrl+C برای کپی)، همان را استفاده کنید، چون عوض کردن این گونه کلیدها باعث سردرگمی کاربران می شود.
  • رابط کاربری را بر اساس دنیای واقعی مدل کنید : به طور مثال برای ثبت فاکتور در یک سیستم فروش، سعی کنید صفحات شبیه به فاکتورهای واقعی طراحی شوند. این کار باعث می شود که کاربر احساس راحتی با نرم افزار شما کند.
  • اطلاعات را به تدریج نمایش دهید : اگر قرار است اطلاعات گوناگون و حجیمی را به کاربر نمایش دهید، ابتدا آن را در بالاترین سطح مجردسازی به کاربران نمایش دهید. جزئیات بیشتر باید به علاقه کاربر و با دستور او ارائه شوند.
  • فراهم نمون ارتباط قابل انعطاف : چون کاربران مختلف علایق گوناگون و سطح آشنایی متفاوتی با کامپیوتر دارند وجود انتخاب نحوه ارتباط ضروری است. نرم افزار باید به کاربر امکان دهد که از ماوس، صفحه کلید، قلم دیجیتالی یا حتی دستورات صوتی برای اجرای کارهای مختلف بهره بگیرد.
  • کارهای طولانی باید وقفه پذیر باشند : کاربر باید بتواند اعمال در حال اجرای طولانی را متوقف کند. کاربر باید از زمان اجرای یک کار آگاهی داشته باشد تا بتواند بهتر در مورد اجرا یا عدم اجرای آن کار تصمیم بگیرد. مثال ساده این عمل را در کپی کردن فایل ها دیده اید، کاربر از زمان اجرای عمل باخبر است و هرگاه که تصمیم بگیرد می تواند آن را متوقف کند.
  • کارهای حساس باید برگشت پذیر باشند : ممکن است کاربر عملی را به اشتباه انجام دهد و نیاز داشته باشد آن عمل اشتباه را لغو کند. نرم افزار باید چنین امکانی را در کارهای حساس به کاربر ارائه کند. به طور مثال در ویرایشگرهای تصویر، اگر به اشتباه جایی از تصویر را خراب کنید، به راحتی با یک عمل Undo می توانید اشتباه خود را جبران کنید.
  • رابط کاربری باید یکنواخت باشد : علاوه بر رعایت استانداردهای معمول یک رابط کاربری، شما بایستی استانداری برای طراحی رابط خود تعریف کنید تا تمام صفحات رابط شما از یکنواختی مشخصی برخوردار باشند. رابط کاربری شما باید اطلاعات را به صورت یکنواخت نمایش دهد یا دریافت کند. این کار باعث می شود تا کاربر با صفحات جدیدی که برایش باز می شوند نا آشنا نباشد و با آن ها راحت کار کند.

gmail-web

حتماً عوامل موثر دیگری هم در ایجاد رابط کاربری مناسب و استاندارد وجود دارند که در این مطلب به آن ها اشاره نشد. موضوع مهمی که حتماً باید در نظر بگیرید، پلت فرمی است که قرار است نرم افزار شما روی آن کار کند. به طور مثال اگر نرم افزار شما تحت وب است طراحی شما شرایط متفاوتی با یک نرم افزار تحت دسکتاپ دارد. هر چند که مسایل بالا هم در نرم افزارهای تحت وب قابل پیاده سازی است و هم در نرم افزارهای تحت دسکتاپ. همچنین طراحی رابط کاربری در سیستم عامل های مختلف نیز تفاوت های زیادی با هم دارند. در این مطلب ما به صورت Abstract و جدا از پلت فرم به مسئله طراحی رابط کاربری نگاه کردیم.
مثال هایی از رابط کاربری استاندارد در نرم افزارهای امروز را می توان Gmail در وب، Office 2007 در ویندوز و فایرفاکس در لینوکس عنوان کرد.

دریافت این مقاله در قالب PDF

مطالب مرتبط :

می توانید برای مطلع شدن از مطالب جدید فراسان، مشترک فید آن شوید!

Oslo ; پلت فرم مدل سازی مایکروسافت

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

Oslo نسل بعدی پلت فرم توسعه مایکروسافت

محصول جدید مایکروسافت با کد نام «Oslo» قصد دارد تا توسعه دهندگان را در ساخت نرم افزارهای پیچیده و بزرگ مبتنی بر دیتابیس بوسیله ابزارهای مناسب یاری کند. مدل سازی در اینجا یعنی بیشتر مشخصات و تعریف های نرم افزار با داده ها پیاده سازی شوند به طوری که پلت فرم و شما بتوانید هر چه آسانتر با استفاده از یک کوئری به مقصود اصلی خود برسید. تکنولوژی های مایکروسافت چند وقتی است در این مسیر حرکت می کنند، برای نمونه XAML, .NET metadata attribute, COM type libraries همگی روی نوشتن مشخصات به عنوان داده و اجتناب از کد کردن آن ها در سطوح پایین (مثل دستورات IL در دات نت) تاکید دارند. پلت فرم Oslo میخواهد این راه را ادامه دهد.

Microsoft Oslo

اجزای تشکیل دهنده Oslo

پلت فرم مدل سازی Oslo با استفاده از اجزای زیر موارد بالا را در اختیار شما قرار می دهد :

  • ابزار طراحی بصری با کد نام «Quadrant» که به شما در پروسه طراحی قوانین تجاری اپلیکیشن ها کمک می کند. این ابزار با استفاده از شکلک های گرافیکی فلوچارت مانند به شما در طراحی مدل های یک اپلیکیشن کمک می کند.
  • یک زبان مدل سازی به نام «M» که شما بایستی برای توسعه مدل های خود از آن استفاده کنید. زبان M زبانی اعلانی (Declarative) برای کار کردن با داده ها و ساختن مدل هاست. M به برنامه نویسان اجازه می دهد تا ساختار داده های خود را تعریف کنند و کوئری های متناسب با نیاز خود ایجاد کنند.
  • مخزن Oslo که یک دیتابیس SQL Server است و مدل ها را به عنوان اشیاء و نمونه (Instance)های مدل ها را به عنوان سطرهای یک جدول (Table) برای پیاده سازی شمای آن، در SQL Server ذخیره می کند. مدل ها و نمونه هایی از مدل ها به صورت بصری یا با استفاده از M یا هر API دسترسی به SQL دیگری (مثل ADO.NET) ایجاد می شوند.

در هر صورتی که شما داده های مدل ها را ایجاد کنید یا تغییر دهید (با استفاده از ابزار بصری، استفاده از M یا هر API دسترسی به SQL)، تمام اطلاعات مدل سازی در یک دیتابیس رابطه ای (Ralational Database) که به آن Oslo Repository گفته می شود، در هنگام اجرا (Runtime) در دسترس اند.

شرکت مایکروسافت فعلاً قصد ارائه Oslo را به عنوان بخشی از ویندوز یا دات نت فریم ورک ندارد. این شرکت نسخه CTP پلت فرم مدل سازی Oslo را برای دانلود عمومی روی سایت خود قرار داده است که می توانید از اینجا SDK آن را دریافت کنید. مدل سازی چند وقتی است در کانون توجه مایکروسافت قرار گرفته و آنچه مسلم است در آینده ای نه چندان دور در مورد Oslo بیشتر خواهیم شنید.

ویدئوی بررسی Oslo

در ویدئوی زیر Paul Vick که چندی قبل در تیم طراحی زبان Visual Basic مایکروسافت همکاری میکرده است، و حالا بر روی زبان مدل سازی M و پلت فرم Oslo کار می کند، در مورد Oslo اطلاعات خوبی به شما خواهد داد. در این ویدئو آقای Vick در مورد پلت فرم Oslo و اهداف آن، زبان مدل سازی M، ابزار Quadrant و مخزن رابطه ای Oslo صحبت می کند. توصیه می کنم برای تکمیل این مطلب ویدئوی زیر را حتماً مشاهده کنید.


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

سایت رسمی Oslo

برای تکمیل مطلب و مشاهده مثال عملی می توانید مطالب آموزشی آقای وحید نصیری در مورد Oslo و زبان M را در اینجا مطالعه کنید.