گذاشتن محدودیت برای برنامه نویسان… اما به چه قیمتی!

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

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

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

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

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

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

محدودیت ساعت ورود و خروج

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

محدودیت صحبت با تلفن شخصی

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

محدودیت زمان استراحت

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

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

محدودیت گوش دادن به موزیک

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

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

نتیجه

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

farasun.wordpress.com

خواندن مطلب مرتبط : یک محیط سفارشی شده; تمام چیزی که یک برنامه نویس می خواهد!

Subcribe to Farasun feedمشترک فراسان شويد

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

حداقل مهارت های یک برنامه نویس دات نت!

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

1 : دید شیء گرا داشته باشد و با قوانین Objected Oriented Programming به خوبی آشنا باشد. دات نت به صورت پیش فرض برنامه نویس را درگیر مباحث شیء گرایی می کند. به همین دلیل اگر کسی با شیء گرایی آشنایی نداشته باشد نمی تواند برنامه های خوبی بنویسد یا در دات نت پیشرفت کند. یک برنامه نویس دات نت باید بتواند برنامه خود را توسط کلاس ها و با استفاده از مفاهیم کپسوله سازی، ارث بری، چندریختی و اینترفیس ها بنویسد تا توسعه و تغییر آن در دراز مدت ساده و کم هزینه باشد. بر همین اساس او باید :

  • با namespace و scope کلاس ها آشنایی داشته باشد
  • تفاوت یک کلاس Partial و یک کلاس معمولی را بداند
  • مفهوم کلاس های abstract را درک کند و توانایی نوشتن interface را داشته باشد
  • بتواند با استفاده از کلمات کلیدی private، public، protected، internal و internal protected دسترسی به کلاس ها را کنترل کند
  • فرق کلاس و متد استاتیک و غیر استاتیک را بداند
  • با مفاهیم overload و override در تعریف متدها آشنایی داشته باشد

2 : با ویژگی های یکی از زبان های برنامه نویسی دات نت به خوبی آشنا باشد. دانستن ویژگی های یک زبان برنامه نویسی هم در تسریع کدنویسی و هم در استاندارد کد نوشتن به یک برنامه نویس کمک زیادی می کند. بر همین اساس او باید :

  • با تمام data typeهای یک زبان آشنا باشد و به موقع از آن ها استفاده کند
  • بتواند مفاهیم شیء گرایی را با استفاده از ویژگی های زبان پیاده سازی کند
  • با مفاهیم Boxing و Unboxing و Type Casting آشنا باشد
  • با روش های مستند سازی کد در آن زبان آشنا باشد

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

  • مفهوم اسمبلی (Assembly) در دات نت را بداند
  • با ساختار فایل های اجرایی دات نت آشنا باشد
  • با کلاس های پایه دات نت آشنایی لازم را داشته باشد
  • با Garbage Collector و نحوه مدیریت حافظه در دات نت آشنا باشد
  • با قابلیت Reflection در دات نت آشنایی داشته باشد
  • بداند GAC چیست و چه کاری انجام می دهد

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

  • با پنجره های مختلف ویژوال استادیو و مفاهیم آن ها آشنایی کامل داشته باشد
  • بتواند یک پروژه موجود را کامپایل و اجرا کند
  • بتواند فایل های جدیدی را به پروژه اضافه کند
  • بتواند از Toolbox ویژوال استادیو کنترل های مورد نیاز خود را پیدا کند و کنترل های جدیدی را به آن اضافه کند
  • بتواند با ادیتور کد ویژوال استادیو کار کند و کدهای مورد نظر خود را پیدا کند
  • بتواند یک برنامه را با استفاده از ابزارهای ویژوال استادیو Debug کند (منوی Debug)
  • تفاوت میان اجرا در حالت Debug و اجرا در حالت Release را بداند
  • تفاوت ساختار پروژه های Windows Application، Console Application، Class Library، ASP.NET Web Application و ASP.NET Web Service Application را بداند
  • تفاوت Solution و Project را بداند و بتواند چند پروژه را در یک Solution مدیرت کند

توسعه دهندگان برنامه های مبتنی بر دیتابیس باید :

  • بر روی مفاهیم و نحوه پیاده سازی دیتابیس و رابطه های میان جدول های اطلاعاتی و زبان SQL تسلط داشته باشد
  • با معماری ADO.NET و کلاس های پایه آن آشنا باشد
  • بداند ORM چیست و چه مشکلاتی را حل می کند
  • حداقل با یکی از ORMهای دات نت مثل LINQ to SQL، NHibernate یا Entity Framework آشنا باشد
  • با DataSet و نحوه استفاده ازکنترل های مربوط به دیتابیس مثل DataGrid آشنا باشد
  • با ساختار فایل های XML آشنایی داشته باشد و بتواند یک فایل XML را پردازش کند

توسعه دهندگان برنامه های مبتنی بر وب (ASP.NET) باید :

  • تفاوت های عمومی یک برنامه دسکتاپ و یک برنامه تحت وب را بداند
  • بداند PostBack چیست و چه کاربردهایی دارد
  • بداند متدهای استاندارد POST و GET در ASP.NET چگونه پیاده سازی شده اند
  • با ViewState آشنایی داشته باشد، وظیفه آن را بداند و بداند چه مواقعی کاربرد دارند
  • با ساختار فایل web.config آشنایی لازم را داشته باشد
  • تفاوت میان کنترل های تحت سرور و کنترل های HTML و تحت کلاینت را بداند
  • با زبان جاوا اسکریپت آشنایی لازم را داشته باشد
  • Lifetime یک برنامه ASP.NET را درک کند
  • با کوکی ها آشنا باشد و بتواند از آن ها استفاده کند
  • بتواند با استفاده از Session یک سیستم لاگین طراحی کند
  • بتواند تفاوت یک وب سرویس و یک وب اپلیکیشن را توضیح دهد

farasun.wordpress.com

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

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

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

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

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

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

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

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

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

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

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

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

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

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

farasun.wordpress.com

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

پروژه دات نت شما چه وابستگی هایی دارد؟

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

یکی از ساده ترین راه ها برای یافتن فایل های وابسته به پروژه، نگاه کردن به پوشه References موجود در پنجره Solution Explorer در ویژوال استادیو است. یا اینکه یک پروژه Setup بسازید و پوشه Detected Dependencies موجود در آن را بررسی کنید. اما متاسفانه این راه های ساده همیشه ما را به جواب قطعی نمی رسانند. زیرا ممکن است همین فایل های موجود در ارجاع های پروژه شما نیز وابستگی هایی به فایل های خارج از پروژه شما داشته باشند.

در اینجا به بررسی 3 ابزار برای یافتن وابستگی های یک پروژه یا اسمبلی دات نت می پردازیم.

x.NET Reflector

یکی از بهترین راه ها برای یافتن تمام وابستگی های یک پروژه دات نت، استفاده از ابزار سودمند x.NET Reflector است. این ابزار می تواند تمام محتویات یک کامپوننت دات نت مثل یک اسمبلی را شناسایی، تحلیل، جستجو و مرور کند و اطلاعات باینری را به فرم قابل خواندن تبدیل نماید. هنگامی که یک کامپوننت دات نت را با این ابزار باز می کنید، تمام اجزای آن را که شامل کلاس ها، ارجاع ها و منابع می شود به شما نشان می دهد. با زدن Ctrl+R یا انتخاب گزینه Analyze از منوی Tools پنجره جدیدی به برنامه اضافه می شود که وابستگی های کامپوننت دات نت مورد نظر شما را نشان می دهد.
این برنامه دارای ویژگی های فوق العاده دیگری مانند Decompile کردن اسمبلی های دات نت و تبدیل کدهای سی شارپ به ویژوال بیسیک و بالعکس نیز هست که در مطلب دیگری به آن خواهیم پرداخت.

.NET Reflector

NDepend

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

متاسفانه نسخه حرفه ای NDepend رایگان نیست اما نسخه Trial آن را می توانید برای کارهای غیرتجاری به صورت رایگان از اینجا دریافت کنید.

NDepend

Dependency Finder

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

<p style=»text-align: justify;»><span style=»color: #ffffff;»>farasun.wordpress.com</span></p>

<a href=»http://feeds.feedburner.com/Farasun»><img class=»size-full wp-image-163″ title=»feed» src=»https://farasun.files.wordpress.com/2008/07/feed.jpg&raquo; alt=»Subcribe to Farasun feed» width=»16″ height=»16″ /><strong>مشترک فراسان شويد</strong></a>

<span style=»color: #ffffff;»>farasun.wordpress.com</span>

farasun.wordpress.com

Subcribe to Farasun feedمشترک فراسان شويد

همچنین بخوانید :

عنوان های دیگر این مطلب : یافتن وابستگی های یک پروژه دات نت| چطور فایل های وابسته به یک پروژه دات نت را پیدا کنیم ؟

عنوان انگلیسی این مطلب : How to find your .NET project dependencies?

برای ثبت در بلاگبان : 086bf5178eb810a4c46acf3e709a87ab