تحلیل یک پروژه--فاز آلفا--
در این پست تیم چهار نفره ی ما می خواد یه پروژه کوچولو رو مورد بررسی قرار بده که البته هنوز اشکالات زیادی داره که ما اون رو در فاز آلفا و بتا رو وبلاگ می گذاریم .
فاز آلفا قبل از بررسی نهایی استاد گرامی است و فاز بتا که شامل پروژه تایید شده و نهایی است و عاری از هر گونه اشکال (انشا...) در پست های بعدی به حضور شما دوستان عزیز قرار داده خواهد شد.
البته می تونید تصاویر رو با کیفیت بالا از این قسمت دانلود کنید...
دانلود حجم : 898.8 k
پروژه مربوط به یک کارخانه است که از قرار معلوم بعد از بررسی یک مهندس سیستم گرامی تایید شد که لازم است این کارخانه کلیه کارهای برگه ای و سنتی خود را به صورتی سیستمی و کامپیوتری با اطلاعات معلوم زیر به روز رسانی کند.
بعد گروه تحلیل گر وارد کار شده و اطلاعات زیر رو از کارخانه مطروحه دریافت کرده اند.
اين پروژه براي اتوماسيون شركتي تعريف شده است كه از نظر جغرافيايي، بخشي از آن در دفتر مركزي و بخشي از آن در كارخانه قرار دارد. مديريت فروش در دفتر مركزي، مديريت انبار ها و مديريت توليد در كارخانه قرار دارند. بخشي از مديريت فروش در كارخانه مستقر بوده و به نام مديريت فروش كارخانه ناميده مي شود. ارتباط بين كارخانه و دفتر مركزي از طريق مودم برقرار مي گردد
---ویژگی سیستم
...تصدیق هویت و اعتبار کاربران
هر کاربر برای استفاده از این سیستم، دارای یک شناسه کاربری و کلمه عبور است که برای وی تعریف شده است و باید با آن وارد شود. با توجه به حقوق مشخصی که هر کاربر دارد، قادر به انجام کارهایی در این سیستم می باشد.
...ثبت پیش فاکتور
پیش فاکتور در دفتر فروش در دفتر مرکزی با مراجعه مشتری ثبت می شود. کارشناس فروش، مسئول ثبت و ویرایش پیش فاکتور ها می باشد.
...ثبت حواله
پس از ثبت پیش فاکتور، به دنبال تایید مشتری و با ارائه پیش فاکتور، حواله برای وی صادر می گردد. این کار توسط کارشناس فروش انجام می گیرد. باید توجه داشت که سیستم ثبت حواله را از روز پیش فاکتور صادر شده انجام می دهدو
...تایید حواله
پس از ثبت حواله، حواله با تایید مدیر فروش رسمیت خواهد داشت.
...ارسال درخواست تولید یا صدور دستور بارگیری
پس از آنکه حواله به مدیریت فروش کارخانه ارسال شد، در آنجا مورد بررسی قرار می گیرد.در صورتی که به تعداد کالای مورد درخواست در حواله،در انبار موجود بود ، از موجودی انبار کاسته و برای ارسال کالا، سند دستور بارگیری ثبت می شود. سند دستور بارگیری بخشی از سیستم انبار می باشد.سند دستور بارگیری توسط انبار دارد در انختیار حمل و نقل قرار گرفته تا کالا را به مشتری برساند.
در صورتی که کالا به تعدا مورد نیاز در حواله ، در انبار موجود نباشد، برای کالای با مشخصات مذکور و به تعداد مشخص شده در حواله، سفارش تولید ثبت می گردد. سند سفارشتولید ، بخشی از سیستم تولید می باشد. پس از اتمام تولید ، مدیر تولید، سند دستور بارگیری را مشابه بالا برای انبار صادر می نماید تا کالا در اختیار مشتری قرار داده شود.
در این مرحله تحلیل گران بعد از مطالعه کامل وضعیت کارخانه حتی بطور دقیق تر مطالب فوق به طراحی نمودار های ERD می پردازند، که در واقع همان مدلسازی داده ها می باشد. که در چند گام ترسیم می شود .(دوستانی که واحد ساختمان داده ها را پاس کرده باشند با این قسمت کاملا آشنا بوده و انشاءالله به درستی می توانند این نمودار را ترسیم نمایند.)
در اولین گام از ترسیم ERD یا همان Enterprise Relation Dieagram باید انواع موجودیت های موجود در فضای مسئله را شناسایی نمود.
در این پروژه موجودیت های قسمت دفتر فروش مرکزی ؛ مشتری، کارشناس فروش ، مدیر فروش، نام کاربری و رمزعبور، پیش فاکتور/حواله و صورت حساب می باشد.
بعد در گام بعدی از ترسیم ERD باید ارتباط میان هر دو زوج با بررسی نمود. به عنوان مثال در شکل مربوطه ارتباط میان کارشناس فروش و صورتحساب از نوع صدور می باشد. همچنین ارتباط میان کارشناس فروش با مشتری و پیش فاکتور/حوله از نوع ثبت.
در مرحله بعدی باید بررسی نمود که نوع ارتباط میان دو موجدیت به چه گونه است در مسئله فوق چنین ارتباطی را نمی توان یافت ولی به عنوان نمونه ارتباط مابین کتاب و فورشنده کتاب در یک کتابخانه میتوان فروش، امانت و ... باشد یعنی چندین ارتباط وجود داشته باشد.
بعد از این گام باید درجه و الزام این ارتباط ها را بررسی نمود.
یاد آوری: درجه 1:1 درجه 1:n درجه m:n
در پروژه فوق هر مدیر فورش می تواند یک یا چند پیش فاکتور را ثبت کند که ارتباطی از نوع 1:n است و در ترسیم نمودار ERD معمولا ارتباط سمت N را با علامت > نشاند داده و ارتباط های سمت یک را با |
منظور از الزام هم الزام وجود این موجودیت است که یا O است یا |
در این مرحله توجه به نوع صفات هم خالی از لطف نیست انواع صفات موجودیت ها می توان صفات شناسه، صفات توصیفی و صفات ار جاعی را نام برد.
بعد از بررسی تمام مراحل فوق می توان ER Diagram را ترسیم نمود.
در پروژه فوق فرض هایی عنوان شده است از جمله آنکه تیم ما سیستم را به این صورت در نظر گرفته است که کامند مربوطه بعد از وارد کردن رمزعبور و نام کاربری خود به صفحه مربوطه برود. با توجه به اینکه این کارمند قبلا توسط مقام های بالای کارخانه مورد تایید قرار گرفته این و هر یک صفحه ای مربوط به خود را دارند که اطلاعات ثبت شده آنها که شامل شماره کارمندی، نام و نام خانوادگی ، بخش(منظور بخش انبار،دفتر فروش مرکزی، دفتر فروش کارخانه و یا تولید می باشد)،سِمَت و حقوق می باشد که همانطور که گفته شد این قسمت قبلا توسط عاملین مربوطه پر شده است.
خــُب ؛ با فرض اینکه در ابتدای کار مسلما مشتری محترم به کارشناس فروش مراجعه می نماید کار ترسیم را آغاز می کنیم. کارشناس با ورود به بخش خود با ثبت اطلاعات مشتری که شامل کد مشتری (جهت شناسایی مشتری در خرید های بعدی)، آدرس دقیق محل تحویل جنس، تلفن، نقدینگی و تخفیف فرم مربوطه را پر می نماید. بعد از این مرحله مشتری با عنوان درخواست خود کارشناس فروش اقدام به ثبت فرم پیش فاکتور/حواله رفته و اطلاعاتی مثل نام خریدار، و کد مشتری، شماره فاکتور، لیست اجناس، قیمت اجناس(شامل قیمت کل و قیمت یک کالا)، تاریخ سفارش، تعداد سفارشات(فی) را پر می نماید . بعد این فرم به اطلاع مشتری رسیده و مشتری آنرا تایید می کند طبق درخواست های کلی پروژه عنوان شده بود که پیش فاکتور زمانی که به تایید مشتری گرامی رسید به حواله تبدیل می شود. بنابر این ما تصمیم بر این گرفتیم که دکمه ای را تعبیه کنیم که بعد از تایید مشتری ، کارشناس مربوطه با تیک دار کردن آن مراحل نظارت و تایید مشتری را به اطلاع می رساندو در واقع اگر این گزینه فعال باشد به معنای تایید مشتری خواهد بود که در شکل زیر با عنوان flag1 مشخص شده است.
بعد از این مراحل فرم پیش فاکتور/حواله که در حال حاظر حکم حواله را دارد از طریق شبکه به مدیر فروش فرستاده می شود.
مدیر فروش هم باید حواله مربوطه را تایید کند. طبق صحبت های عنوان شده در این قسمت هم گزینه ای مشابه در نظر گرفته شده است که اگر مدیر فروش آن را تیک دار نماید حواله مربوطه کلیه مراحل را انجام داده و از طرفی باید در مخزن یا همان DataBase ذخیره گردد و به کارخانه ارسال شود.
در اینجا هم flag2 را در نظر گرفته ایم که اگر true شود یعنی این گزینه تیک خورده است و حواله مربوطه تایید شده است.
پس از طی این مراحل و در هنگام تحویل کالا به مشتری باید صورت حسابی هم دریافت نماید که در این پروژه صورت حسابی با موارد فوق باید در فرم مربوطه توسط کارشناس فروش صادر گردد؛ کد مشتری، کد حواله، نام مشتری، لیست اجناس،قیمت اجناس، تاریخ سفارشات، تعداد سفارشات و ...
توجه کنید که در دنیای واقع اطلاعات مربوطه خیلی فراتر از پروژه مذکور خواهد بود و ما از عنوان کردن تمامی آنها خود داری نمود ه ایم .
بعد از ترسیم ERD باید DFD یا Data Flow Diagram را ترسیم نمود. نام دیگر این دیاگرام Bubble Chart هم هست چون در آن کلیه ارتباطات مابین موجودیت ها را در حباب هایی ترسیم می کنیم.
توجه کنید که علامت à مربوط بی علامت اطلاعات و داده ها می باشد. منظور ورودی و خروجی هاست.
در حباب ها هم فراید و توابعی که لازم می باشد را باید نگاشت.
توجه به اینکه که برای ترسیم نمودار جریان داده باید پروژه را به سطح هایی تقسیم نمود حتی پروژه ای به کوچکی!
کلیه سطح های مربوطه در تصاویر زیر مشخص می باشد. که مسلما با کمک گرفته از نمودار ER ترسیم شده است.
نکته: دیاگرام سطح اول به Context Diagram معروف است.
همانطور که مشاهده می کنید در این قسمت از pspec هم استفاده شده که در آن اطلاعاتی مربوط به flag های عنوان شده دقیق تر مورد بررسی قرارد گیرد.
در گام بعدی باید به مدلسازی رفتاری بپردازیم یعنی کلیه رفتار های سیستم را پیش بینی کرده و در نمودار STD عنوان کنیم . نمودار STD که تیم ما برای این پروژه در نظر گرفته است به شرح زیر می باشد.
نکته: خط سبز در نظر گرفته شده چون از طریق شبکه و دیتابیس مربوطه بود با رنگی متفاوت بررسی شده است تا ارتباط بین این دو بخش مشخص گردد.
نکته: از ترسیم و پیش بینی ارتباط بین مدیر فروش و کارخانه به دلیل اینک اطلاعات تایید حواله بر روی دیتا بیس قرار می گیرد و کارخانه از طریق شبکه به آن دسترسی خواهد داشت نادیده گرفته شده است
پی نوشت: تحلیل گران گرامی در این مرحله می توانند خستگی رفع نمایند و ادامه کار را به طراحان محترم بسپارند...(البته اگر از مدل SSADM استفاده کنیم تحلیل گرا باید دیگه برن خونه هاشون و دنبال یه پروژه دیگه بگردن ولی چون SSADM دیگه یه جورایی از دور خارجه ما از روش Incremental استفاده می کنیم )
خــُب حالا دیگه نوبت به طراحان عزیز رسید. در این فاز باید 4 عمل اصلی و اساسی انجام شود:
1-طراحی داده ها
2-طراحی معماری
3-طراحی واسطه ها
4-طراحی رویه ها
من در اینجا فقط می خوام به قسمت طراحی معماری بپردازم که از مدل های DFD استفاده می کنه.
انواع معماری داده ها
1-Data center: که در ان کلاینت ها به طور مستقل به داده ها دسترسی داشته و می توانند رو آن تغییراتی را انجام دهند – تمامی داده ها هم در بیتا بیس مربوطه قرار دارد.
2- جریان داده: منطق آن روی تبدیلات است. تبدیلات زیادی روی داده ها انجام می شود . دراین نوع معماری عملیات پردازش یا همان تبدیل بیشتری روی منطق الگوریتم می پردازد نه حذف و اظافه کردن داده ها روی دیتابیس. و اغلب در نرم افزار های علمی مورد استفاده قرار می گرید.
3-معماری لایه : که نرم افزار را به لایه های واسط،کاربرد،ارتباط با دیتابیس، و هسته تقسیم می نماید. که در هر کدام عملیات خاصی صورت می گیرد.
4-معماری شی گرا: بخش تشکیل دهنده برنامه اشیا هستند که این اشیا از طریق message passing با هم در ارتباط اند.
5-معماری call-return : در این مدل یک main در نظر میگیریم و زیر برنامه های فراخوانی را در آن در نظر میگیریم . کل DFD را در نظر گرفته و به بخش های وروردی، تبدیل(پردازش) و خروجی تقسیم می کنیم وبعد در نموداری ترسیم می نمانییم.
تیم ما در این پروژه از معماری نوع آخر بهره برده است که بعد از ترسیم نمودار اولیه کار فاکتور گیری هم انجام شده است که در قسمتی از باکس های مربوطه حذف شده اند.
پی نوشت: مسلما طراحان گرامی باید تا حد امکان این قسمت را به درستی و با دقت بیشتر ترسیم کنه تا مسئول پیاده سازی بتوونه در حد آب خوردن کد بزنن!! و البته این موضوع شامل تیم تحلیل هم می شه ! چون اون بندگان خدا باید مدت طولانی و با روش های مختلفی اطلاعات مروبطه رو جمع آوری کنن؛ که واقعا کار خسته کننده است.!!
تا اینجای کار اگه همه چیز به خوبی پیش رفته باشه نوبت به استراحت تیم طراحی مرسه (البته کارهای بسیاری رو باید انجام می داد که مااز گفتنش فاکتور گرفتیم...)
حالا کار پیاده ساز یا همون کدنویس میاد وسط که باید با انتخاب یک زبان برنامه نویسی، اطلاعات دقیق، روابط ،حتی فرمول ها و نیمی از کدها شروع به کد نویسی کنه...
امید وارم اطلاعات مربوطه به شما عزیزان کمک بکنه.
اگر سوالی بود بهم میل بزنید تا سوال رو برطرف کنیم...
موفق باشید...
امیدوارم بتونیم باز هم پروژه های بعدی رو براتون تشریح کنیم.
برای مهندسین بن بستی وجود ندارد...