تو نوشته های قبلیم در مورد مراحل ساخت یک برنامه گفتم. اولین مرحله ارتباط و قرارداد با مشتری بود. اون را بعدها براتون میگم. ولی اولین مرحله فنی تحلیله.
چجوری تحلیل کنیم؟ تحلیل چیه؟ چه خبرتونه؟
تحلیل کردن در اصل ترجمه کردن حرفای مشتریه به زبان فنی. مشتری از چیزای زیادی حرف میزنه، ازآرزوهاش برای شرکتش، از هدفاش، از آیندش، از همسر و عیالش، از کارهای مسخره ای که همکارا کردن، از طریقه کسب و کارش، از دفترهایی که توش حساب و کتاباشا مینویسه و هزار چیز دیگه.
وسط این همه حرفی که میزنه کلی چیز بدست میاد که ما بهش میگیم نیازمندی های پروژه. و البته به منابعی که داده های مورد نیاز سیستم از اونجا بدست میاد هم اشاره هایی میشه که بهش میگیم جریان داده. و همچنین روند کار و شرط هایی که توی کار اعمال میشه و تصمیم گیری میکنه که بهش میگیم بیزینس.
دقت داشته باشید که خود مشتری نمیدونه چی میخواد. فقط میدونه که برای سر و سامون دادن به کسب و کارش نیاز به یه سیستم نرم افزاری داره.
خیلی مهمه که هدف ما سر و سامون دادن باشه. ساده سازی باشه. نه اینکه تازه خودمون باعث بشیم کار سخت بشه یا یه چیز جدید به چیزهای قبلی اضافه بشه. کمک کنیم که سنگی از جلوی پای مشتری برداشته بشه. به این معنی نیست که به مشتری برای بهبود پیشنهاد ندیم یا کارش را بهتر نکنیم. ولی شرط اصلی بهتر شدن کار ساده شدن اون کاره.
حالا که اینها مشخص شدن باید چیکار کنیم؟ آفرین!! مستند سازی کنیم. روند کاری و داده های مشتری را بنویسیم. به چه زبانی؟ به زبان مادری! بنویسیم که چه داده ای را از کجا میگیریم و چه شرایطی را اعمال میکنیم و به چه شکلی اون داده ها را تبدیل میکنیم به چیزی که مشتری میخواد. مشخص میکنیم که به چه داده و چه امکانی کدوم کاربرها دسترسی دارند و کدوم کاربرها دسترسی ندارند. قدیمتر ها توی مهندسی نرم افزار مباحثی در مورد Use Case ها وجود داشت و روند کارهایی که کاربر انجام میداد را به ترتیب نمایش میداد.
بستر ارائه سیستم را مشخص کنید. تحت وب یا موبایل یا سرور یا دسکتاپ. روی هر بستری یه سری امکانات وجود داره و یه سری محدودیت ها. برای هر بستری هم یک زبان برنامه نویسی وجود داره و در هر زبان برنامه نویسی برای هر بستری فریم ورکهایی تعریف شدند. سازوکار گرافیکی نرم افزار هم وابسته به بستر انتخابیه. تکنولوژی و معماری نرم افزاری که میخواید استفاده کنید هم وابسته به همه موارد گفته شده خواهد بود. بخش مهمی از تحلیل باید بر اساس این موضوعات باشه. مثلا نمیتونید امکاناتی که روی نرم افزار تحت وب هست را برای نرم افزار موبایل درنظر بگیرید.
روی هر بستری یه سری امکانات وجود داره و یه سری محدودیت ها.
داده هایی که داریم درموردش حرف میزنیم را باید یه جایی ذخیره کنیم. بستری که انتخاب کردید و به طبع اون زبان و معماری مشخص شده ای که دارید، حجم داده ای که در سیستم وجود خواهد داشت، تعداد کاربرانی که در یک زمان از سیستم استفاده میکنند، جدولی یا سندی بودن داده ها(SQL/NOSQL)، وابسته به تراکنش بودن یا نبودن جریان داده ها و ... باعث میشه که دیتابیس شما انتخاب بشه. بسته به نوع دیتابیس و ساختاری که داره نمودار اتصالات بین داده ها را رسم کنید. این هم یکی از بخش های اصلی داده خواهد بود. باید بتونید به داده های مورد نیازتون در سریعترین زمان ممکن و با کمترین تعداد مراجعه به دیتابیس دسترسی داشته باشید.
درسته که میگن ظاهر بین نباشید ولی اون مال جای دیگه ایه. اینجا باید ظاهر هم دیده بشه. ظاهر از دو لحاظ مهمه: اول اینکه رنگ و لعاب برنامه چه جوری باشه که کاربر سیستم از کار کردن باهاش لذت بصری ببره(خارجی ها به این میگن UI). و دوم اینکه جای هر چیزی توی صفحه کجا باشه تا کاربر با کمترین تلاش به هدفش برسه(خارجی ها برای این هم اسم گذاشتن و بهش میگن UX). مواظب باشید که برای راحتی زیاد کاربر خودتون زیادی ناراحت نشید. محدودیت های بستری که قراره نرم افزار روی اون ارائه بشه هم در نظر بگیرید.
البته مرسومه که اول و آخر مستندات هم فهرست و مقدمه و معرفی تیم و اینها میذارن. اونها را میتونید با یه سرچ ساده ببینید.
حالا شما مستندات فنی و بیزینسی لازم را دارید. به این چیزی که میبینید میگن تحلیل.
من محمد(سروش) محمدی هستم و سالهای زیادی هست که درحال کار در حوزه برنامه نویسی هستم. میخوام وقتی باز کنم و برای خودم و شما از برنامه نویسی بنویسم.
