تحلیل و پایه ریزی معماری سیستم یک شرکت تولید کننده قطعات خودرو

[Ishtar_4552]

با سلام به همه دوستان

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

[مهدی هادیان2]

بسم الله الرحمن الرحیم
با سلام
سعی می کنم مطالبی که فکر میکنم به کارتون میاد خدمتتون عرض کنم؛ ان شاالله مفید واقع بشه.
در ابتدا باید روال دستی اون رو کاملا بررسی کنید. فرض کنید می خواهید در اون جا استخدام بشید باید تمام پروسه ها و مراحل کاری اونجا دستتون بیاد. مشاهده دست اول و نزدیک خیلی میتونه کمک کننده باشه. به اون جا برید و مراحل کاری رو از نزدیک مشاهده کنید.
هر چی فرم دستی دارند بگیرید؛ این ها بعدا خیلی به دردتون می خوره. می تونید قسمتی از کلاس ها و فیلدها را از روی این ها استخراج کنید.
برای جمع آوری اطلاعات می تونید از راه های زیر کمک بگیرید:
تمام مستندات کاری، فرم ها و برگه ها ، چارت سازمانی و شرح وظایف را جمع آوری کنید.
همون طور که قبلا هم عرض کردم مثل کسی باید باشیم که می خواهد در قسمت های مربوطه استخدام شود باید بدانیم دقیقا هر قسمت چه کار می کند.
یکی دیگر از راه های شناخت تنظیم پرسش نامه است.
سوال هایی که به نظر مهم می آید باید مطرح کنیم و از طرفی باید بدانیم که این پرسش نامه ها را به چه کسانی بدهیم. از رابط کمک بگیرید تا بدانید پرسش نامه ها را به چه کسانی بدهید.
اگر بتوانید جلساتی داشته باشید تا بتوانید ابهاماتتان را مطرح کنید خیلی خوب می شود تا مسائل شفاف تر شود.
می خواهم نشانه های کلاس رو خدمتتون عرض کنم؛ چراکه مهمترین محصول یک تحلیل خوب همین کلاس ها هستند که از روی این ها پایگاه داده بدست می آید.
1) مهمترین نشانه: چیزها و وقایعی که سیستم موظف است در مورد اونها چیزی رو ثبت کنه. در واقع همون تعریف Entity در دیتا بیس است. در سناریوها به عبارت هایی مثل ثبت می شود، ذخیره می شود، نگهداری می شود باید حساس بود.
2) سیستم هایی که با سیستم ما تبادل اطلاعات دارند می توانند کلاس باشند. مثلا در سیستم کنترل ترافیک هوایی هواپیما با سیستم ما تبادل اطلاعات دارد پس کاندید کلاس است.
3) ابزار می تواند کلاس باشد. مثلا رادار هواپیما و کامپیوتر
4) نقش های ایفاشده. مثلا کارمند کار می کند پس کارمند می تواند کلاس باشد
5) مکان ها می تواند کلاس باشد. مثلا شعبه ها در سیستم بانک ملی می تواند کلاس باشد
این ها مواردی ست که می توانند کلاس باشند. مهمترین ملاک برای اینکه مطمئن بشید که کلاس هست یا نه اینه که ببینید لازم است اطلاعاتی در مورد اون ثبت شود یا نه؟
موفق باشید.

[maktoom]

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

[Ishtar_4552]

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

ممنون می شم اگه دوستان یه راهکار مناسب تر بهم بدن..

[مهدی هادیان2]

بسم الله الرحمن الرحیم
با سلام


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


از توجهتون ممنونم ، ولی یکی از مشکلاتی که با RUP دارم اینه که مشتری فعلآ نظرش اینه که یک بخش از سیستم یعنی تولید ، طراحی بشه و بعد برم سراغ انبار و بقیه قسمت ها ، کلیه اطلاعات قسمت تولید رو هم در اختیارم قرار دادند..
به نظر بنده این خیلی خوبه که مشتری یه زیر سیستم جدا رو ازتون خواسته است. طراحی این قسمت رو انجام میدید و شروع به کد زدن میکنید و ...
ترجیحا برای کد زدن هم اگه از تکنولوژی های جدید مثل EF استفاده کنید؛ ان شاالله بعدا کمتر درگیر دوباره کاری های خسته کننده خواهید شد.


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

موفق باشید.

[m.hamidreza]

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

ممنون می شم اگه دوستان یه راهکار مناسب تر بهم بدن..

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

پ.ن: اون چیزی که در مورد اسکرام هم گفتید لزوماً صادق نیست. قرار نیست اسکرام یا هر رویکرد دیگه ای به شما بگه دیتابیس رو چطور طراحی کنید... تصمیم با شماست.
موفق باشید.

[maktoom]

سلام

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

[مهدی هادیان2]

بسم الله الرحمن الرحیم
با سلام

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

[مهدی هادیان2]

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