به شخصه همیشه فکر می کردم چه دلیلی دارد که برای یک پروژه کوچک یا حتی بزرگ بیام وقت بزارم و داکیومنت سازی کنم ؟ شاید شما هم همیشه این فکر را در ذهن خودتان دارید , البته خیلی ها هم این چنین فکر نمی کنند .
ولی اگر شما این چنین فکری را در سر دارید باید به شما بگویم که مهندسی نرم افزار را با برنامه نویسی شروع کردید و یا آکادمیک به دنبال آموزش آن نرفته اید. خیلی از موارد این ذهنیت وجود دارد که یک پروژه باید از یک پروسه کوچک شروع شود و مرحله به مرحله بزرگ شود و به قسمت های دیگر ارجاع گردد. حتی این چنین پروسه کاری تا جایی پیش می رود که برنامه نویس به سمت ایده پردازی هایی که خارج از پروژه هست هم سوق داده می شود که خوب هم هزینه و هم زمان بیشتری را طلب می کند.
ولی به نظر من یک بار هم شده شما باید از برنامه نویس بودن به سمت مهندس نرم افزار یا مدیریت پروژه هدایت شوید تا متوجه این موضوع بشوید که داکیومنت سازی چه فوایدی برای شما دارد و چه امکاناتی را برای شما فراهم می کند .
توجه : مراحل یادگیری با ساخت پروژه واقعی به صورت کامل تفاوت دارد پس این بخش را با یادگیری برنامه نویسی و پروژه اول خود اشتباه نگیرید
در ترم تحصیلی جاری بلخره این امکان ایجاد شد تا من به اجبار پروژه پایان ترمم یک تحلیل نرم افزاری از یکی از سیستم هایی که تاحالا ساختم داشته باشم البته به علت مشکلات قانونی و قراداد هایی که برای این سیستم بسته شد مجبور به ناقص سازی سیستم در تحلیل های خودم و همیطور بیان نمونه کوچیک شده از پروژه شدم که از ارزش این تحقیق کوچک کم نمی کند.
در این مقاله کوچک من سعی کردم مراحل داکیومنت سازی های متفاوتی که همیشه مورد استفاده قرار می گیرد را توضیح بدهم . تمام سعی من این بود که این داکیومنت سازی هم برای یک برنامه نویس کاربرد داشته باشد هم برای اینکه مشتری را راضی نگه دارد و با زبان خودش تفهیم گردد.
اما داکیومنت سازی چه امکاناتی را برای شما فراهم می کند :
- توضیحات اولیه پروژه مطرح می گردد
- به صورت سیسماتیک تحلیل می شود
- مشکلات پروژه بیان می گردد
- ارائه راه حل می گردد
- مزایای راه حل ها بیان می شود
- نیازمندی های سیستمی و انسانی اشاره هایی می شود
- چشم انداز ها و بیان معموریت می گردد
- محدوده پروژه تعریف می شود
- موقعیت فعلی دوباره تحلیل می شود
- به روز رسانی ها تعریف می شوند
- شاخص های ارزیابی باز نشر می شود
- سطوح دسترسی و پروفایل استفاده کننده
- مشخص کردن نیازمندی های عملیاتی - کاربری و ...
- ریسک های پروژه
خوب این همه امکان برای شما فراهم می گردد آیا ارزش زمان قرار دادن برای این مورد وجود ندارد ؟ با توضیح کوچک در این زمینه متوجه این موضوع می شویم که اصل این پروسه برای خود شرکت سازنده سیستم می باشد . هم به آن کمک می کند تا مشترک را راضی کند و هم جلوگیری می کند از دوباره کاری و مشکلاتی که بعد از تحویل پروژه به مشتری داده می شود .
هیچ وقت یک قرارداد متنی بدون تحلیلی نرم افزاری بدون مشکل نخواهد بود پس بهترین راه برای یک برنامه نویس یا مدیر پروژه تحلیل و ایجاد حالت های شماتیک می باشد.
خوب بیشتر از این صحبت کردن فایده ای ندارد فقط باید به این نکته اشاره کنم که در این تحلیل ساده من از UML و DFD و ... استفاده کرده ام . (در نسخه کوچیک شده )
لازم به ذکر هست که در تمام مقاله دیدگاه سیستمی پیاده سازی شده است فقط برای درک بهتر یکی الی دوتا از زیر سیستم ها تحلیل مدل سازی کوچک شده اند . به صورت خلاصه دیدگاه سیستمی به صورت کل به یک سیستم اشاره دارد.
اگر دوست داشتید به بلاگ من سر بزنید: ترانگل