مشخص بودن معماری سیستم قبل از تحلیل؟
سلام،
بعضی ها معتقد هستند قبل از تحلیل سیستم باید معماری رو بدونیم و اینکه در rup در فاز دوم باید معلوم بشه معماری چیست این گروه میگن در بسیاری از پروژه ها به بن بست رسیده چون اگر از اول ندونیم قراره چه جوری کار کنیم به مشکلات زیادی میخوریم.
اگر کسی در این رابطه تجربه ای داره که میتونه این حرف رو در یک پروژه تایید یا نقض کنه خوشحال میشم که بگه.
البته در ظاهر به نظر میاد تحلیل شناخت مسئله است و ربطی به معماری نداره و بعد از تحلیل با توجه به مسئله باید معماری رو تعیین کرد ولی اگر اینطوری بگیم که تحلیل را با توجه به داشته هایمان (معماری) انجام دهیم چی؟
نقل قول: مشخص بودن معماری سیستم قبل از تحلیل؟
شما تا قبل از Business Modeling نمي تونيد بفهميد چه معماري رو خواهيد داشت.اما براي requirement بايد ديدي از معماريتون داشته باشيد
نقل قول: مشخص بودن معماری سیستم قبل از تحلیل؟
نقل قول:
بعضی ها معتقد هستند قبل از تحلیل سیستم باید معماری رو بدونیم و اینکه در rup در فاز دوم باید معلوم بشه معماری چیست
جمله اول مفهومي نداره ،مگر مي شود بدون تحليل معين كرد كه چه معماري نرم افزاري براي پروژه اي كه تحليل نشده مناسب است؟ معمولا تصميم گيري براي معماري سيستم در ديد كلان در زمان اوليه فاز Inception (معمولا دو هفته) انجام مي شود. اين كار توسط سه نقش مدير پروژه ، معمار سيستم و تحليل گر ارشد انجام مي شود و معمولا در پروژه هاي بزرگ در قرار داد ذكر مي شود.
جمله دوم درسته، شما بايد معماري نرم افزار را در فاز دوم مشخص كنيد. سوالات خود را بپرسيد تا بحث را ادامه دهيم.
نقل قول:
شما تا قبل از Business Modeling نمي تونيد بفهميد چه معماري رو خواهيد داشت.اما براي requirement بايد ديدي از معماريتون داشته باشي
ما در اين فرآيند توليد نرم افزار نظم ها را چندين بار تكرار خواهيم كرد، پس از لحاظ ديد RUP جمله فوق صحيح نيست. يا به عبارتي بهتر شما بايد به اين سوال پاسخ دهيد ، موارد فوق در كدام فاز ؟ و كدام تكرار
نقل قول: مشخص بودن معماری سیستم قبل از تحلیل؟
نقل قول:
يا به عبارتي بهتر شما بايد به اين سوال پاسخ دهيد ، موارد فوق در كدام فاز ؟ و كدام تكرار
فاز inception تكرار اول!
نقل قول: مشخص بودن معماری سیستم قبل از تحلیل؟
سلام علیکم
نقل قول:
فاز inception تكرار اول!
در این فاز و تکرار اصلا بحثی در مورد معماری نمیشه !
معماری(4+1) 5 قسمت اصلی داره که اصلی ترین قسمت های آن تا پایان فاز 2 تموم میشه . اگه فرایند رو طبق اصول خودش پیش بری این معماری 4+1 بصورت اتوماتیک آماده میشه یعنی در اصل 4+1 جمع کردن یکسری از محصولات مهمی است که در هر تکرار بدست می آوریم.
موفق باشید
یا علی
نقل قول: مشخص بودن معماری سیستم قبل از تحلیل؟
حرف زیر خیلی خوبه !
نقل قول:
ما در اين فرآيند توليد نرم افزار نظم ها را چندين بار تكرار خواهيم كرد، پس از لحاظ ديد RUP جمله فوق صحيح نيست. يا به عبارتي بهتر شما بايد به اين سوال پاسخ دهيد ، موارد فوق در كدام فاز ؟ و كدام تكرار
واقعا با داشتن دید مناسب خیلی از گیج بازی هایی که امثال من داریم بوجود نمیاد.
هر موقع سوالی مطرح میکنیم باید بدانیم مربوط به کدام فاز - کدام تکرار - کدام دسیپلین - کدام محصول است ؟
پس بهتره اصولی پیش بریم
اصولی مطالعه کنیم
حرف هر کسی رو قبول نکنیم و بهتر از ها این است که به دنبال سرچشمه اطلاعات بگردیم.
نقل قول: مشخص بودن معماری سیستم قبل از تحلیل؟
نقل قول:
در این فاز و تکرار اصلا بحثی در مورد معماری نمیشه !
فكر كنم منم همينو گفتم!!
در ضمن نحوه پاسخ دادنتون اصلا جالب نيست.
نقل قول: مشخص بودن معماری سیستم قبل از تحلیل؟
نقل قول:
نقل قول:
در این فاز و تکرار اصلا بحثی در مورد معماری نمیشه !
فكر كنم منم همينو گفتم!!
در ضمن نحوه پاسخ دادنتون اصلا جالب نيست.
لطفا از ارسال مطالب نا مرتبط با موضوع خودداري كنيد و موارد لازم را در پيام خصوصي مطرح كنيد.
اتفاقا در اين فاز و در تكرار اول در مورد معماري كلان سيستم بايد بحث شود، در بسياري از پروژه ها بعد از تكرار اول بايد قرارداد بسته شود. بسياري از كارفرماها اين صبر را ندارند كه شما بعد از يك ماه اعلام كنيد معماري مورد نظرشان قابل انجام نيست (مثلا نرم افزار بر روي وب كار كند يا ويندوز). البته منظور من از معماري بحث كلان سيستم است. شما در فرجه اي كه در فاز و تكرار اول داريد بايد در مورد معماري (بيشتر نياز هاي غير وظيفه مندي سيستم و چيزهايي كه در نظم آخر يعني Environment بحث ميشود) بايد بحث كنيد، اين آيتم ها معمولا شامل چيزهايي مي شود كه در قرارداد آورده مي شوند.
نقل قول: مشخص بودن معماری سیستم قبل از تحلیل؟
خوشحالم که بعد از مدت ها مجددا بحث فنی و جالبی در فروم در گرفته است و از کلیه دوستانی که در این بحث شرکت کرده اند تشکر میکنم. امیدوارم این تعامل مثبت بتواند به ارتقاء دانش فنی همه ما کمک کند.
ضمن تأیید صحبت های دوست گرامی جناب Whitehat، چند نکته را هم بنده اضافه میکنم :
نقل قول:
نوشته شده توسط
whitehat
اتفاقا در اين فاز و در تكرار اول در مورد معماري كلان سيستم بايد بحث شود، در بسياري از پروژه ها بعد از تكرار اول بايد قرارداد بسته شود. بسياري از كارفرماها اين صبر را ندارند كه شما بعد از يك ماه اعلام كنيد معماري مورد نظرشان قابل انجام نيست (مثلا نرم افزار بر روي وب كار كند يا ويندوز).
همانگونه که ایشان اشاره کرده اند در بعضی پروژه ها لازم است در همان تکرارهای ابتدایی فاز Inception در مورد معماری صحبت شود؛ در مورد پروژه هایی که معماری آن با ریسک های قابل توجهی همراه است، مثلا از تکنولوژی های جدید و ناشناخته ای باید استفاده کنید یا نوع سیستم برای شما جدید است، لازم است امکان پذیری انجام پروژه از لحاظ معماری آن مورد بررسی قرار گیرد، RUP این فعالیت را Architectural Synthesis (سنتز معماری) می نامد و در طی آن شما لازم است نیازمندی های کلیدی معماری سیستم را (عملکردی و غیر عملکردی که غالبا در این گونه موارد نیازمنیدهای غیر عملکردی هستند که ریسک ایجاد می کنند) شناسایی کنید و برای برآورده شدن آن نیازمندی ها راه حلی که به سادگی قابل تصور باشد را ارائه کنید.
این راه حل می تواند به صورت های مختلفی ارائه شود : فهرستی از تکنولوژیهای مورد استفاده، یک مدل UML سطح بالا و یا حتی یک شبیه سازی از معماری مورد نظر. RUP این راه حل ارائه شده را Architectural proof of concept می نامد که هدف آن اثبات امکان پذیری فنی سیستم است. و در نهایت راه حل ارائه شده را در برابر ان نیازمندی ها ارزیابی کنید.
همانگونه که اشاره شد انجام این فعالیت و تهیه فراورده متناظر آن در مواردی که معماری سیستم برای شما شناخته شده است و ریسک مهمی در ارتباط با ان وجود ندارد ضرورتی ندارد.
واضح است که پیش نیاز انجام این فعالیت کسب شناخت از نیازمندی های - در حد تهیه vision، بخصوص بخش های
Product overview, Features, Quality Range & Other requirements(system Requirementsاست که در همان تکرارهای ابتدایی Inception محقق می شود.
