سلام دوست عزیز
۱- این کتاب تالیف و ترجمه است که نویسندگان کتاب در طول چندین سال تجربه کاری خودشون به این نتیجه رسیدن که اگه حوزه تحلیل نیازمندی ها با این سبک و سیاقی که توی کتاب اومده انجام بشه ارزش افزوده زیادی خواهد داشت. خاطر نشان کنم که این کتاب سعی کرده براساس متدولوژی RUP سازماندهی بشه. به نظرم این کتاب ارزش یک بار خوندن رو داره.
بله درسته و به قول استاد اعظم طود تحقیق و تفکر دکتر رانکوهی : باید رفت و از سر چشمه آب خورد.
اگر کسی می خواد به طور حرفه ای تو این زمینه کار کنه صد البته باید رفرنسهای معتبر رو مطالعه کنه.
۲- اگر بخوایم روی زبان های برنامه نویسی شی گرا مثال بزنیم . برنامه نویسی شی گرا که از سه مفهوم وراثت - کپسوله سازی و چند ریختی تشکیل شده که این سه مفهوم مهمه نه زبانهای برنامه نویسی شی گرا مثل جاوا و سی شارپ. چون اگه در هر یک از زبانهای جاوا و سی شارپ این مفاهیم رعایت نشه مثل اینکه که ما داریم در یک زبان ساخت یافته مثل وی بی کد می زنیم. زمانی ما می تونیم بگیم که برنامه کاربردی ما شی گراست که ما سه مفهوم را رعایت کرده باشیم و متناسب با برنامه خودمان ازش استفاده کرده باشیم. و استفاده از یک زبان شی گرا برای توسعه نرم افزار بدین معنی نیست که ما داریم برنامه کاربردی شی گرا تولید می کنیم.
سلام به دوستان عزیز
در این مجال یکسری نکات مهم و ارزشمند رو براتون میزارم که امیدوارم مفید واقع بشه.
هر کدوم از موارد که برای دوستان عزیزم مبهم و گنگ هست مطرح کنن تا توضیحاتی بدم تا موضوع براتون روشن و قابل درک تر بشه.
۱-بدلیل وجود عدم قطعیت در توسعه نرم افزار در ابتدای کار نمی توانیم راه حل کاملی را برای مسائل ذینفعان پیشنهاد بدیم و به همین خاطر باید رفته رفته و با گرفتن فیدبک از ذینفعان و کاربران راه حل پیشنهادی خودمون را کامل کنیم و بهبود ببخشیم.
۲-برای حل هر مساله ای قبل از ارائه هر راه حلی باید ریشه اصلی بروز مساله را کشف کنیم.
۳-نرم افزار Knowledge work می باشد. یعنی باید رفته رفته دانش کسب کنیم و اون چیزی را که می خواهیم تولید کنیم.
۴-برای پاسخ به این سوال : آیا برای نیازهای کاربران و ذینفعان ویژگی متناظر آنها ارائه شده است یا نه ؟ می توانیم از ماتریس رهگیری استفاد نماییم.
۵-اگر نیازی که مشتری مطرح کرده است در دامنه راه حل قرار داشته باشد، تحلیلگر بایستی با مطرح کردن سوالاتی مناسب ریشه مساله را پیدا کند. و به عبارتی دیگر مشتری را وارد دامنه مساله کند.
۶-تحلیلگر سیستم بایستی روی ویژگی های که همیشه و اغلب توسط کاربران مورد استفاده قرار میگیرند وقت زیادی صرف نماید.
۷-کاری اثر بخش می باشد که در راستای Goal باشد.
۸-تحلیلگر برای درک بهتر و دقیق تر نیازهای کاربران و ذینفعان بایستی با محیط آنها حس بگیرد.
۹-تعیین مرز سیستم (Boundary) تاثیر بسزایی بر روی محدوده سیستم (Scope) دارد.
۱۰-تحلیلگر برای بدست آوردن ریشه اصلی مساله مطرح شده توسط ذینفعان می تواند از دو روش زیر استفاده کند:
الف- بکار بردن کلمه چرا؟
ب- نفی کردن مساله ذینفع.
۱۱-تحلیلگر میتواند از ساختار سازمانی، فرایندهای سازمانی و قواعد حاکم بر سازمان برای شناخت کسب و کار مورد نظر استفاده نماید.
۱۲-گزارشاتی را که برای کاربر با معنی می باشند را به عنوان ویژگی در نظر می گیریم.
۱۳-عدم قطعیت یعنی نمی دانیم دقیقا چه اتفاقی خواهد افتاد و بار منفی بر روی محیط ندارد.
۱۴-ریسک رفتاری احتمالی دارد و بار منفی بر روی محیط می گذارد.
۱۵- اصطلاح (Minimum Marketable Feature)MMF یعنی کم ترین چیزی که به مشتری بدهیم و کارش را راه بیندازد.
۱۶-با اولویت بندی کردن ویژگی ها می توانیم به MMF برسیم.
۱۷-اولویت = اهمیت * فوریت
۱۸-ویژن مشخصات سیستمی را که در آینده ساخته خواهد شد را نشان می دهد.
۱۹-شناسایی محدوده سیستم (Scope) مهمترین ریسک پروژه می باشد.
۲۰-در شناسای ویژگی های مهم از قاعده ۲۰ – ۸۰ استفاده می کنیم.
۲۱-چه نرم افزار وجود داشته باشد و چه وجود نداشته باشد BR ها بر کسب و کار حاکم می باشند.
۲۲-نمونه اولیه(Prototype) هر چقدر هم که هزینه داشته باشد باید تولیدش کنیم و سعی کنیم که هزینه آن را کاهش دهیم و نه اینکه چون هزینه دارد انجامش ندهیم.
۲۳-کسی می تواند بگوید که یک کسب وکار را خوب شناخته ام که تمام BRهای آن را بداند.
۲۴-مدل ساده شده واقعیت می باشد و هر چقدر جزئیات آن را افزایش دهیم به واقعیت شبیه تر می شود.
۲۵- اصطلاح Abstraction یعنی های لایت کردن اون قسمت های که برای ما مهم هستند و حذف کردن اون قسمت های که برای ما مهم نیستند.
۲۶-یکی از اشتباهات رایج در مدل سازی این است که مدل ساز بجای اینکه در هنگام مدل سازی به نیازها نگاه کند، از ذهن خود بخواند و مدل سازی کند.
۲۷-تا وقتی که یوزکیس ها را تشریح نکرده ایم نباید روابط بین آن ها را شناسایی کنیم چون باعث تحلیل لغوی می شود و موجب پیچیده شدن دیاگرام موردکاربرد می گردد.
۲۸-در کار تحلیل رجحان محتوا بر شکل داریم یعنی راه حل مقدم بر مدل سازی می باشد.
۲۹-قاعده ۳۰ ثانیه: جایی که هزینه و منفعت یک موضوع خیلی قابل شناسایی نیست شما فقط ۳۰ ثانیه فرصت دارید تصمیم گیری کنید.
۳۰-راهکار بر شیوه مدل سازی ارجحیت دارد. آنچه که مهم است Solution دادن است.
۳۱-یوزکیس بیانگر یک راهکار است که به سیستم می دهیم.
۳۲-صاحب راهکاری که به سیستم داده شده کل تیم است و نه فقط تحلیلگر.
۳۳-سعی شود که مدل موردکاربرد به همراه پروتوتایپ و مدل تحلیل باشد.
۳۴-یکی از شاخص ها برای تسلط به یک سیستم نرم افزاری مسلط بودن بر روی مدل تحلیل آن می باشد.
۳۵-از مدل تحلیل استفاده می کنیم چون نمی توانیم مستقیما از نیازمندی ها وارد طراحی شویم.
در آخر هم از دوستان خواهش میکنم از نظرات سازنده شون دریغ نکنن.
و اگه به نظرتون موردی مشکل داره بگید تا اصلاح کنم.
سلام به همه
حس کردم گروه خیلی سوت و کوره هست گفتم یه بحث کوچیکی تو حوزه تحلیل شروع کنیم. اونم اینکه:
برای تحقق مورد کاربرد در سطح تحلیل چه کارهای باید انجام بدیم؟
من این کارها رو انجام میدم:
۱- یک مورد کاربرد انتخاب میکنم.
۲- سه نوع کلاس سطح تحلیل با کلیشه entity, boundary و control رو پیدا میکنم.
۳- رفتارها و صفات مربوط به هر کلاس سطح تحلیل رو شناسایی میکنم.
۴- روابط بین کلاس های سطح تحلیل رو مشخص میکنم.
نتیجه ۴ گام بالا میشه یک نمودار کلاس با سه نوع کلاس سطح تحلیل که صفات و رفتار هر یک شناسایی شده و روابط بین کلاس های سطح تحلیل نیز مشخص شده است.
نمودار کلاس روابط ساختاری و ایستای کلاس های مربوط به مورد کاربرد را مشخص میکنه.
۵- در این گام در صورت نیاز به مشخص کردن روابط پویایی بین نمونه های کلاس های سطح تحلیل اقدام به آماده کردن نمودار توالی میکنم.
۶- گام های بالا رو برای هر یک از موارد کاربرد تکرار میکنم.
۷- در گام آخر هم نمودار کلاس حاصل از تحقق هر مورد کاربرد را با هم ترکیب میکنم.
نتیجه کارم میشه یک نمودار کلاس سطح تحلیل مربوط به کل نرم افزارم که قرار است توسعه داده بشه.
اگر بخواهیم با دقت بیشتری به موضوع مطرح شده نگاه کنیم میبینیم که در RUP یک فعالیتی با نام use case analysis وجود داره و نقشی که مسول انجام این فعالیت هست Designer می باشد. در این فعالیت تقریبا تمام گام هایی که در بالا ذکر شد انجام میشه اما توسط طراح و نه تحلیلگر سیستم.
اما نکته قابل توجه این هست که تحلیل گر سیستم اگر بتونه دو گام اول رو انجام بده حتی بدون توجه به سه نوع کلاسی که در بالا مطرح شد خیلی موثر خواهد بود و طراح میتونه از خروجی کار تحلیلگر سیستم بهره کافی رو ببره. چون تحلیلگر سیستم درک کامل و خوبی از موارد کاربرد داره. درک و فهمی که طراح نسبت به موارد کاربرد نداره.
اساسا تحقق مورد کاربرد در سطح تحلیل که در فعالیت use case analysis انجام میشه وظیفه طراح هست و نه تحلیلگر سیستم. اما تحلیلگر سیستم میتونه نقش مثبت و موثری در این فعالیت داشته باشه.
در مقابل فعالیت use case analysis فعالیتی دیگر با عنوان use case design وجود داره که که مسولیت انجام اون با طراح هست و این جایی هست که به طور واقعی حرف از تکنولوژی به میان میاد یعنی به عنوان مثال زبان برنامه نویسی مطرح میشه.
سلام به دوستان
یه موضوع کوچیکی که میشه در موردش صحبت کرد بحث انتخاب موارد کاربرد با اهمیت و مهم هست که از اهمیت به سزایی در چرخه توسعه نرم افزار برخوردار هست. مخصوصا موارد کاربرد با اهمیت از نظر معماری نرم افزار. سوال خودم رو این طور مطرح میکنم که:
چه عواملی باعث میشه که یک مورد کاربرد با اهمیت تلقی بشه و چرا؟
سلام
چند وقت پیش داشتم مقاله آقای فیلیپ کراچن رو که در سال ۱۹۹۵ در IEEE منتشر کرده بود رو مرور میکردم. این مقاله ویو مدل ۱+۴ رو معرفی میکنه.
تو صفحه ۱۳ این مقاله با این چند خط مواجه شدم که میتونه پاسخ مناسبی واسه سوالی که پرسیدم باشه:
The most critical functionality of the system is captured in the form of scenarios (or use cases). By critical we mean: functions that are the most important, the raison d’être of the system, or that have the highestfrequency of use, or that present some significant technical risk that must be mitigated.
کلمه raison d’être به معنی "دلیل بودن" یا "دلیل وجود" چیزی هست.
جناب استاد مهرداد متن ذیل رو در وب سایت خودشون منتشر کردن و بنده مفید دونستم در اینجا هم بیارم تا دوستان مانشتی استفاده کنند:
پیشگفتار
در گروه تلگرامی نیازمندی، گفتگوی جالبی انجام شد که بد ندیدم در اینجا نیز بخشهایی از آن را بازگو کنم.
دوستان عزیزی که علاقهمند به حضور در این گروه هستند، میتوانند به آدرس زیر مراجعه فرمایند.
مهمان عزیز شما قادر به مشاهده پیوندهای انجمن مانشت نمیباشید. جهت مشاهده پیوندها ثبت نام کنید.
گفتگوی تلگرامی
آقای قاقالو:
حس کردم گروه خیلی سوت و کوره هست گفتم یه بحث کوچیکی تو حوزه تحلیل شروع کنیم. اونم اینکه:
برای تحقق مورد کاربرد در سطح تحلیل چه کارهای باید انجام بدیم؟
من این کارها رو انجام میدم:
۱- یک مورد کاربرد انتخاب میکنم.
۲- سه نوع کلاس سطح تحلیل با کلیشه entity, boundary و control رو پیدا میکنم.
۳- رفتارها و صفات مربوط به هر کلاس سطح تحلیل رو شناسایی میکنم.
۴- روابط بین کلاس های سطح تحلیل رو مشخص میکنم.
نتیجه ۴ گام بالا میشه یک نمودار کلاس با سه نوع کلاس سطح تحلیل که صفات و رفتار هر یک شناسایی شده و روابط بین کلاس های سطح تحلیل نیز مشخص شده است.
نمودار کلاس روابط ساختاری و ایستای کلاس های مربوط به مورد کاربرد را مشخص میکنه.
۵- در این گام در صورت نیاز به مشخص کردن روابط پویایی بین نمونه های کلاس های سطح تحلیل اقدام به آماده کردن نمودار توالی میکنم.
۶- گام های بالا رو برای هر یک از موارد کاربرد تکرار میکنم.
۷- در گام آخر هم نمودار کلاس حاصل از تحقق هر مورد کاربرد را با هم ترکیب میکنم.
نتیجه کارم میشه یک نمودار کلاس سطح تحلیل مربوط به کل نرم افزارم که قرار است توسعه داده بشه
شما چطور عمل میکنید؟
استاد مهرداد:
ضمن تشکر از آقای قاقالوی عزیز، اگر اجازه بفرمایید من هم نظرم را عرض کنم.
با گامهای دو یه بعد برای تحلیل گر سیستم موافق نیستم.
اگر اشتباه نکنم در خود آر یو پی، این کار به تحلیلگر سیستم سپرده نشده است.
گام دو به بعد "فضای طراحی و تکنولوژی شی گرایی" دارد که لااقل در ایران تحلیل گران فاقد این مهارت هستند
آقای نوذری:
سلام وقت بخیر. من نظر آقای قاقالو رو قبول دارم. فقط باید به یک مساله مهم توجه کرد. همونطور که ایشون نوشتن، باید دقت شود که فعالیت های ۲ به بعد "در سطح تحلیل" انجام شود. با توجه به اینکه تحلیل از نظر انتزاع سطحی بالاتر از طراحی دارد، اگر این دقت نظر انجام شود در فضای "طراحی" نخواهیم افتاد. موضوع یا نگرانی که استاد عزیزم مهندس مهرداد، با عنوان "فضای طراحی و تکنولوژی شی گرایی" اشاره فرمودن نگرانی به جایی هست. ولی مانع از انجام گام های ۲ به بعد که جناب قاقالو ذکر کردن نخواهد شد. به نظر من باید نگرانی مهندس مهرداد رو صرفا با عبارت "جلوگیری از افتادن در فضای تکنولوژی" بیان کرد. چون (۱) طراح کسی هست که Artifact تحلیلگر رو می گیره و روی اون تکنولوژی سوار می کنه و (۲) تحلیل رو با رویکرد شیئ گرایی و در سطح بالایی از انتزاع هم میشه انجام داد.
این مساله مثل طراحی منطقی و فیزیکی دیتابیس می مونه. چیزی که استاد عزیزم مهندس مهرداد فرمودن، مثل این می مونه که بگیم برای طراحی منطقی دیتابیس نیازی به مشخص کردن موجودیت ها یا به بیان من جداول منطقی وجود ندارد، چرا که احتمال ورود به مدلسازی فیزیکی و درگیر شدن مدلساز با مسائل اون بعد خواهد شد.
موضوع یا توضیحی که باید به نوشته آقای قاقالو اضافه بشه این هست که با این مراحل ما داریم System Analysis رو انجام میدیم. ولی اگه بخوایم Business Analysis انجام بدیم اون وقت موضوع متفاوت خواهد بود.
آقای قاقالو:
اگر بخواهیم با دقت بیشتری به موضوع مطرح شده نگاه کنیم میبینیم که در RUP یک فعالیتی با نام use case analysis وجود داره و نقشی که مسول انجام این فعالیت هست Designer می باشد. در این فعالیت تقریبا تمام گام هایی که در بالا ذکر شد انجام میشه اما توسط طراح و نه تحلیلگر سیستم.
اما نکته قابل توجه این هست که تحلیل گر سیستم اگر بتونه دو گام اول رو انجام بده حتی بدون توجه به سه نوع کلاسی که در بالا مطرح شد خیلی موثر خواهد بود و طراح میتونه از خروجی کار تحلیلگر سیستم بهره کافی رو ببره. چون تحلیلگر سیستم درک کامل و خوبی از موارد کاربرد داره. درک و فهمی که طراح نسبت به موارد کاربرد نداره.
اساسا تحقق مورد کاربرد در سطح تحلیل که در فعالیت use case analysis انجام میشه وظیفه طراح هست و نه تحلیلگر سیستم. اما تحلیلگر سیستم میتونه نقش مثبت و موثری در این فعالیت داشته باشه.
در مقابل فعالیت use case analysis فعالیتی دیگر با عنوان use case design وجود داره که که مسولیت انجام اون با طراح هست و این جایی هست که به طور واقعی حرف از تکنولوژی به میان میاد یعنی به عنوان مثال زبان برنامه نویسی مطرح میشه.
استاد مهرداد:
خوشحال هستم که این گفتگو شکل گرفته است.
اگر اجازه دهید چند نکته را عرض کنم.
۱) به نظرم قیاس مدل «تحلیل نرمافزار» بر مبنای «تکنولوژی شیءگرایی» با «مدل منطقی پایگاه داده» ما را به اشتباه خواهد انداخت.
در مدل منطقی پایگاه داده اثری از «رفتار» (behaviour) و «کارکرد» (function) نیست. ما فقط «ساختار» را در مدل مفهومی پایگاه داده داریم.
در مدل تحلیل نرمافزار ما علاوه بر ساختار، کارکرد و رفتار را نیز خواهیم داشت. به عبارت سادهتر، شما علاوه بر شناسایی، کلاسها، صفات کلاسها، روابط ساختاری باید متدهای کلاسها و نحوهی تعامل آنها را برای تحقق سناریوی مد نظر «شناسایی» یا «اختراع» کنید.
اجازه دهید یک مثال ساده عرض کنم. سناریوی ثبت فاکتور که کاربر اطلاعات مشتری و اقلام خریداری شده را وارد میکند و سپس سیستم باید در هر مرحله قیمت هر ردیف از فاکتور و همزمان با آن قیمت کل فاکتور را محاسبه کند و نمایش دهد را در نظر بگیرید.
تحلیل نرمافزار یعنی این که:
- کلاسها، صفات و روابط ساختاری بین کلاسها را پیدا کنید
- تعیین کنید که هر کلاس باید چه متدها و مسئولیتهایی داشته باشد
- تعیین کنید که کلاسها چگونه با یکدیگر تعامل کنند تا سیستم بتواند قیمت ردیف و قیمت کل فاکتور را نشان دهد.
برای نمونه به سوالهای زیر پاسخ دهید
- کلاس فاکتور و قلم فاکتور چه متدهایی دارند؟ (لطفا از ذخیره، ویرایش، حذف، ... نام نبرید) چگونه این متدها را پیدا میکنید؟
- قیمت ردیف و قیمت کل فاکتور را کدام کلاس محاسبه کند؟ فاکتور + فاکتور، قلم فاکتور + یک کلاس جدید + ...
-این کلاس برای آن که بتواند قیمت کل و قیمت ردیف را حساب کند باید با کدام کلاسها پیغام پسغام کند؟
بیشک برای پاسخ به این پرسشها، داشتن «دانش» و «مهارت» در «تکنولوژی شیءگرا» ضروری است.
از نقش تحلیلگر سیستم چنین انتظاری نمیرود. اگر بخواهیم کمی صادقانه صحبت کنیم، تعداد کمی از برنامهنویسان دارای این مهارت هستند، چه رسد به تحلیلگران.- کلاس فاکتور و قلم فاکتور چه متدهایی دارند؟ (لطفا از ذخیره، ویرایش، حذف، ... نام نبرید) چگونه این متدها را پیدا میکنید؟
- قیمت ردیف و قیمت کل فاکتور را کدام کلاس محاسبه کند؟ فاکتور + فاکتور، قلم فاکتور + یک کلاس جدید + ...
-این کلاس برای آن که بتواند قیمت کل و قیمت ردیف را حساب کند باید با کدام کلاسها پیغام پسغام کند؟
بیشک برای پاسخ به این پرسشها، داشتن «دانش» و «مهارت» در «تکنولوژی شیءگرا» ضروری است.
از نقش تحلیلگر سیستم چنین انتظاری نمیرود. اگر بخواهیم کمی صادقانه صحبت کنیم، تعداد کمی از برنامهنویسان دارای این مهارت هستند، چه رسد به تحلیلگران.
آقای نوذری:
سلام استاد وقت بخیر. مرسی از وقتی که میگذارید. اینجا واسه من حکم کلاس درس رو داره.
منظور از چیزی که نوشتم مقایسه تحلیل نرم افزار با مدلسازی دیتابیس نبوده. من فقط می خواستم به نوعی این موضوع رو بگم که فعالیت هایی از جنس تحلیل رو میشه پیدا کرد که توی سطحی پایین تر، طراح هم با اونها سر و کله میزنه. به نظر من واسه این که بحث قوام بگیره بیایید از انتها حرکت کنیم تا ابتدای صحبت برسیم. به این معنا که یه سری از Term ها را روش بحث کنیم. تا بتونیم نهایتا تعریفی روشن از تحلیل و فعالیت هایی که تحلیلگر باهاشون درگیر هست برسیم. استاد من با فرمایش شما: "بیشک برای پاسخ به این پرسشها، داشتن «دانش» و «مهارت» در «تکنولوژی شیءگرا» ضروری است.
از نقش تحلیلگر سیستم چنین انتظاری نمیرود. اگر بخواهیم کمی صادقانه صحبت کنیم، تعداد کمی از برنامهنویسان دارای این مهارت هستند، چه رسد به تحلیلگران." کاملا موافقم. ولی به نظر من حتی اگه بخش از چند فعالیتی که شما اسم بردید مثل شناسایی و تعامل کلاس ها(البته در سطح تحلیل) و ... به طراح سیستم سپرده شود، در اصل و اساسا بخشی از فعالیت تحلیلگر به او سپرده شده است.
شاید به نوعی بتوان گفت تحلیل سیستم در واقع به نوعی "طراحی اولیه" یا به عبارتی "طراحی در سطح بالایی از انتزاع" می باشد. این مطلب در کتاب زیر به تفصیل آمده است:
Use Case Driven Object Modeling with UML, Theory and Practice. By: Doug Rosenberg and Matt Stephens
این کتاب فصلی با عنوان ROBUSTNESS ANALYSIS دارد. در این بخش از کتاب هدف از ROBUSTNESS ANALYSIS این طور بیان شده است:
To get from use cases to detailed design (and then to code), you need to link your use casesto objects. The technique we describe in this chapter, robustness analysis, helps you to bridgethe gap from analysis to design by doing exactly that. In a nutshell, it’s a way of analyzing youruse case text and identifying a first-guess set of objects for each use case. These are classifiedinto boundary objects, entity objects, and controllers (which are often more like functionsthan objects).
همچنین در ادامه بیان شده است که تحلیل یا تکنیکی که نویسنده از آن با عنوان Roubstness Analysis نام برده است برای پر کردن فاصله یا گپی است که بین تحلیل و طراحی وجود دارد:
نویسنده کتاب در ادامه در خصوص شکل فوق و تشریح Robstness Analysis این توضیح را بیان نموده است:
Looking at Figure 5-1, robustness analysis sort of takes place in the murky middle groundbetween analysis and design. If you think of analysis (i.e., the use cases) as the “what” anddesign as the “how,” then robustness analysis is really preliminary design. During this phase,you start making some preliminary assumptions about your design, and you start to thinkabout the technical architecture (also see Chapter 7) and to think through the various possibledesign strategies. So it’s part analysis and part design.
همچنین وی برای مدلسازی و ترسیم نمودارها نیز چنین اصطلاحی را با توضیح زیر بیان می نماید:
... a robustness diagram is an object picture of a use caseAnatomy of a Robustness DiagramA robustness diagram is somewhat of a hybrid between a class diagram and an activity diagram.It's a pictorial representation of the behavior described by a use case, showing bothparticipating classes and software behavior, although it intentionally avoids showing whichclass is responsible for which bits of behavior. Each class is represented by a graphical stereotypeicon (see Figure 5-2). However, a robustness diagram reads more like an activity diagram(or a flowchart), in the sense that one object “talks to” the next object. This flow of action isrepresented by a line between the two objects that are talking to each other.
There’s a direct 1:1 correlation between the flow of action in the robustness diagram andthe steps described in the use case text.
استاد مهرداد:
پیشنهاد میکنم ابتدا چند عبارت زیر را از هم تفکیک کنیم
تحلیل سیستم
تحلیل نیازمندیها
تحلیل (در ادبیات ما در ایران)
تحلیل نرمافزار
طراحی نرمافزار
آن چه در ایران به نام تحلیل شناخته میشود به «تحلیل نیازمندیها» و به عبارت درستتر «نیازمندیها» نزدیکتر است (requirements)
تحلیل نیازمندیها کاری است که ما از «تحلیلگر سیستم» انتظار داریم.
دقت بفرمایید که «تحلیل نرمافزار» به کلی با «نیازمندیها» متفاوت است. (به پسوند نرمافزار دقت بفرمایید)
تحلیل نرمافزار همان طور که فرموده بودید «پیش طراحی» است. به عبارت سادهتر تکنیکی است برای گذار از نیازمندیها و ورود به طراحی نرمافزار.
روباستنس آنالسس، تکنیکی است در «تحلیل نرمافزار» که به طراح نرمافزار کمک میکند کلاسها، آبجکتها و مکانیزمها و ... را شناسایی کند بدون آن که درگیر موضوعات کیفی و تکنولوژی ساخت محصول گردد. همان طور که در شکل به روشنی مشخص است، «تحلیل نرمافزار» قرار است شکاف بین نیازمندیها (در شکل یوزکیسها) به طراحی نرمافزار را پرکند.
همان طور که عرض کردم فکر میکنم که «تحلیل نرمافزار» به مهارتها و دانش طراحی نرمافزار نزدیکتر است تا دانش و مهارت «تحلیلگر سیستم».
البته این فقط یک دستهبندی مفهومی است. ما میتوانیم افرادی را پیدا کنیم که به خوبی از عهدهی همهی این کارها بر آیند. ولی باید بدانیم که «جنس» این کارها با هم متفاوت است.
جمعبندی بنده از فرمایشات حضرتعالی این است که ما برداشتهای یکسانی از واژهها نداریم، وگرنه در باقی قضایا همنظر هستیم.
سپاسگزارم از این که چراغ این خانه را روشن نگه میدارید و امیدوارم که بقیهی دوستان نیز مشارکت بیشتری داشته باشند.
شاد باشید
آقای نوذری:
مرسی استاد از صحبت هاتون. خیلی استفاده کردیم.
با شما و فرمایشتون: "جمعبندی بنده از فرمایشات حضرتعالی این است که ما برداشتهای یکسانی از واژهها نداریم، وگرنه در باقی قضایا همنظر هستیم." کاملا موافقم. توی پست قبلی هم اشاره کرده بودم. چه قدر قشنگ از لحاظ مفهومی چندتا Term بالا رو از هم تفکیک کردین. اجازه بدین من هم یه موضوع دیگه رو به نقل از پرسمن اشاره کنم. و اون "مهندسی کردن سیستم" قبل از شروع "مهندسی کردن نرم افزار" هست:
Software engineering occurs as a consequence of a process called systemengineering. Instead of concentrating solely on software, system engineeringfocuses on a variety of elements, analyzing, designing, and organizing thoseelements into a system that can be a product, a service, or a technology for thetransformation of information or control.
The system engineering process is called business process engineering whenthe context of the engineering work focuses on a business enterprise. When aproduct (in this context, a product includes everything from a wireless telephoneto an air traffic control system) is to be built, the process is called productengineering...
... Before software can be engineered, the ”system” in which it resides must be understood. To accomplish this, the overall objective of the system must be determined; the role of hardware, software, people, database, procedures, and other system elements must be identified; and operational requirements must be elicited, analyzed, specified, modeled, validated, and managed. These activities are the foundation of system engineering.
به نظر من تحلیل سیستم خودش جزئی از فرآیندی بزرگتر به نام مهندسی سیستم هست.همونطور که جنابعالی اشاره کردین جنس این فعالیت ها با هم متفاوت هست. دوستان اگه پست هایی که قبل از عید در خصوص "تحلیل کسب و کار بر پایه BABOK" توی گروه نوشته بودیم رو ملاحظه کنند، شاید بد نباشه. اونجا من به صورت ضمنی و بعضا صراحتا خیلی سعی کردم خط کشی انجام بدم. و مراتب تحلیل رو نشون بدم. من به شدت به بحث انتزاع در فعالیت های سیستم اعتقاد دارم. و طبعا توی این طیف انتزاعی فعالیت ها با هم متفاوت خواهد بود. دلیل اینکه تعریف مهندسی سیستم رو از کتاب پرسمن آوردم هم نشون دادن این مساله بود.
حتی اگر مشتری ها و کاربران نهایی نیازهای خود را به طور صحیح بدانند، این نیازها در طول پروژه تغییر خواهند کرد. در کتاب [Ralph Young] در مورد تجربه مفید نیازها می خوانید:
بدترین کابوس این است. مشتری به دفتر شما می آید، می نشیند، به چشمان شما خیره می شود، و می گوید "می دانم فکر می کنید هر چه من گفتم فهمیده اید، اما آنچه شما نمی فهمید، این است که گفتم منظور من این نیست". معمولا این وضعیت در آخر پروژه بعد از پایان مهلت اتفاق می افتد، که کارها در حال انجام هستند و هزینه زیادی صرف شده است.
فرایندهای تطبیقی(چابک)
از اوآخر دهه ۱۹۹۰ و در طول دهه جاری، فرایند نرم افزار هیاهوی بسیاری را از مدل های سبک وزن تر و بسیار تطبیقی تر شنیده است. با توجه به تغییرات اساسی که در الگوهای پیاده سازی نرم افزار همانند شیء گرایی، زبان های نسل سوم و توسعه آزمون محور ایجاد شد، این مدل ها مبتنی بر پایه اقتصادی گوناگونی بودند. این مدل ها اینگونه فرض می کنند که اگر با به کارگیری روشی که در آن با کمک ابزارهای توسعه و تجربه های درست کدنویسی سریعا انجام گردد و سپس در کاربرد واقعی توسط مشتری ارزیابی و در صورت وجود مشکل بازآرایی لازم به سرعت انجام شود، مقرون به صرفه تر از روشی است که در آن همه نیازمندی ها زودهنگام پیش بینی و مستندسازی گردند.
در حقیقت تعدادی از این روش ها، شامل روش توسعه سیستم های پویا(DSDM)، توسعه ویژگی محور(FDD)، توسعه نرم افزار تطبیقی، اسکرام، ایکس پی ، فرایند یکپارچه باز(Open Up)، فرایند یکپارچه رشنال چابک(Agile RUP)، کانبان، ناب، روش های کریستال و ... هستند.
از اوآخر دهه ۱۹۹۰ و در طول دهه جاری، فرایند نرم افزار هیاهوی بسیاری را از مدل های سبک وزن تر و بسیار تطبیقی تر شنیده است. با توجه به تغییرات اساسی که در الگوهای پیاده سازی نرم افزار همانند شیء گرایی، زبان های نسل سوم و توسعه آزمون محور ایجاد شد، این مدل ها مبتنی بر پایه اقتصادی گوناگونی بودند. این مدل ها اینگونه فرض می کنند که اگر با به کارگیری روشی که در آن با کمک ابزارهای توسعه و تجربه های درست کدنویسی سریعا انجام گردد و سپس در کاربرد واقعی توسط مشتری ارزیابی و در صورت وجود مشکل بازآرایی لازم به سرعت انجام شود، مقرون به صرفه تر از روشی است که در آن همه نیازمندی ها زودهنگام پیش بینی و مستندسازی گردند.
در حقیقت تعدادی از این روش ها، شامل روش توسعه سیستم های پویا(DSDM)، توسعه ویژگی محور(FDD)، توسعه نرم افزار تطبیقی، اسکرام، ایکس پی ، فرایند یکپارچه باز(Open Up)، فرایند یکپارچه رشنال چابک(Agile RUP)، کانبان، ناب، روش های کریستال و ... هستند.
بیانیه چابک
در سال ۲۰۰۱ ایجاد کنندگان بسیاری از متدلوژی های توسعه نرم افزار چابک به همراه جمع دیگری از افراد که روش های چابک گوناگونی را پیاده سازی کرده بودند دور هم گرد آمدند و بیانیه چابک را که خلاصه ای از اعتقادشان در مورد وجود روش بهتر برای تولید نرم افزار است خلق کردند. امروزه بیانیه چابک اعتقادات مهمی که زیربنای این جنبش است را به شرح ذیل ترکیب و تعریف می کند:
ما روش بهتری برای توسعه نرم افزار به وسیله انجام دادن آن کشف کرده ایم و به دیگران کمک می کنیم تا آن را انجام دهند. با انجام این کار به ارزش دست پیدا می کنیم.
اشخاص و تعاملات برتر از فرایندها و ابزارها
همکاری مشتری برتر از مذاکره قرارداد
نرم افزار قابل اجرا برتر از مستندسازی جامع
پاسخ به تغییرات برتر از دنبال کردن یک طرح
با وجود این که اقلام سمت چپ نیز دارای ارزش هستند، اما ما ارزش بیشتری را به اقلام سمت راست می دهیم.
فرایند یکپارچه رشنال(RUP)
فرایند یکپارچه رشنال، اولین فرایند نرم افزاری است که به طور گسترده مورد استفاده قرار گرفت و ضرورت هم پوشانی فعالیت ها در چرخه عمر فازهای آغازین، تشریح، ساخت و انتقال را تشخیص داد. به عنوان نمونه، فعالیت هایی همانند «نیازمندی ها» فقط به یک فاز منفرد واگذار نمی گردند. اگرچه، فعالیت های نیازمندی ها بیشتر در فازهای آغازین و تشریح مورد توجه قرار می گیرند، اما با این وجود تشریح و تغییر نیازمندی ها به صورت فرایندی مداوم در طول چرخه عمر پروژه نیز اتفاق می افتد. این فرایند به طور گسترده در صنعت مورد استفاده قرار می گیرد(دارای میلیون ها شاغل است) و با موفقیت بر روی هزاران پروژه از انواع مختلف اعمال شده است. به طوری که این موفقیت ها شامل پروژه هایی با مقیاس های بسیار بزرگ نیز هستند.
بیانیه چابک
پشت بیانیه چابکی که در پست قبل ارسال کردیم مجموعه ای از اصول مهم وجود دارد که به عنوان چارچوبی مشترک برای همه روش های چابک به خدمت گرفته میشوند:
• بالاترین اولویت ما راضی نگهداشتن مشتری از طریق تحویل زود هنگام و مداوم نرم افزار با ارزش است.
• به تغییرات حتی در پایان توسعه خوش آمد می گوییم. متدهای چابک تغییرات را برای مزیت های رقابتی مشتری مهار می نمایند.
• نرم افزار قابل اجرا ، معیار اصلی برای پیشرفت پروژه است.
• نرم افزار قابل اجرا را در مدت زمان چند هفته تا چند ماه با ترجیح زمان های کوتاه تر به طور مکرر تحویل می دهیم.
• افراد کسب و کار و توسعه دهنده ها باید با یکدیگر به طور روزانه در سرتا سر پروژه کار کنند.
• پروژه ها را حول اشخاص با انگیزه بسازید. برای آن ها محیط و پشتیبانی لازم را محیا کنید و به آن ها اعتماد کنید تا کار را انجام دهند.
• کاراترین و موثرترین روش انتقال اطلاعات به/در درون تیم توسعه، گفتگوی رو در رو است.
• فرایندهای چابک، توسعه پایدار را گسترش می دهند. حامیان مالی، توسعه دهنده ها و کاربران باید بتوانند به طور نامحدودی گام ثابت را حفظ نمایند.
• توجه مداوم به سرآمد فنی و طراحی خوب، چابکی را تقویت می کند.
• سادگی(هنر به حداکثر رساندن مقدار کار انجام نشده) اساسی است.
• بهترین معماری ها، نیازمندی ها و طراحی ها از تیم های خودسازمانده ظهور می کنند.
• در بازه های زمانی منظمی تیم می تواند چگونگی موثرتر شدن خود را انعکاس دهد، در نتیجه تیم رفتارش را بر این اساس تنظیم کرده و تطبیق می دهد.
با سلام
وقت بخیر
بنده به یک راهنمایی مهم خیلی نیاز دارم
برنامه نویسی یا کنکور ارشد؟
من یک دبیر رسمی اموزش و پرورشم
و سطح علمی دانشگاهیم متوسط و ی کم رو به پایین هست و بخوام برای کنکور ارشد۹۷ بخونم باید خیلی وقت بگذارم
و از طرفی میگم چون شغل ثابت دارم پس ارشد خوندن رو جدی نگیرم و برم سراغ برنامه نویسی
و در صورتی که سطح برنامه نویسیم هم خوب نیست و باید خیلی تلاش کنم ولی خییلی علاقه دارم
به نظرتون کدوم کار رو کنم؟
خیلی سر در گمم
چون سطح علمی دانشگاهم و برنامه نویسیم در یک حد هس و هر کدوم رو انتخاب کنم باید براش خیلی زحمت بکشم
خواهشااااا راهنماییم کنید
(۱۲ آذر ۱۳۹۶ ۱۱:۵۳ ق.ظ)مهندس آیدا۹۱ نوشته شده توسط: با سلام
وقت بخیر
بنده به یک راهنمایی مهم خیلی نیاز دارم
برنامه نویسی یا کنکور ارشد؟
من یک دبیر رسمی اموزش و پرورشم
و سطح علمی دانشگاهیم متوسط و ی کم رو به پایین هست و بخوام برای کنکور ارشد۹۷ بخونم باید خیلی وقت بگذارم
و از طرفی میگم چون شغل ثابت دارم پس ارشد خوندن رو جدی نگیرم و برم سراغ برنامه نویسی
و در صورتی که سطح برنامه نویسیم هم خوب نیست و باید خیلی تلاش کنم ولی خییلی علاقه دارم
به نظرتون کدوم کار رو کنم؟
خیلی سر در گمم
چون سطح علمی دانشگاهم و برنامه نویسیم در یک حد هس و هر کدوم رو انتخاب کنم باید براش خیلی زحمت بکشم
خواهشااااا راهنماییم کنید
سلام
به نظر من اگر دنبال برنامه نویسی برید بهتره.