مشخص بودن معماری سیستم قبل از تحلیل؟

[p.1000]

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

[Elham_gh]

شما تا قبل از Business Modeling نمي تونيد بفهميد چه معماري رو خواهيد داشت.اما براي requirement بايد ديدي از معماريتون داشته باشيد

[whitehat]

بعضی ها معتقد هستند قبل از تحلیل سیستم باید معماری رو بدونیم و اینکه در rup در فاز دوم باید معلوم بشه معماری چیست

جمله اول مفهومي نداره ،مگر مي شود بدون تحليل معين كرد كه چه معماري نرم افزاري براي پروژه اي كه تحليل نشده مناسب است؟ معمولا تصميم گيري براي معماري سيستم در ديد كلان در زمان اوليه فاز Inception (معمولا دو هفته) انجام مي شود. اين كار توسط سه نقش مدير پروژه ، معمار سيستم و تحليل گر ارشد انجام مي شود و معمولا در پروژه هاي بزرگ در قرار داد ذكر مي شود.
جمله دوم درسته،‌ شما بايد معماري نرم افزار را در فاز دوم مشخص كنيد. سوالات خود را بپرسيد تا بحث را ادامه دهيم.

شما تا قبل از Business Modeling نمي تونيد بفهميد چه معماري رو خواهيد داشت.اما براي requirement بايد ديدي از معماريتون داشته باشي

ما در اين فرآيند توليد نرم افزار نظم ها را چندين بار تكرار خواهيم كرد، پس از لحاظ ديد RUP جمله فوق صحيح نيست. يا به عبارتي بهتر شما بايد به اين سوال پاسخ دهيد ، موارد فوق در كدام فاز ؟ و كدام تكرار

[Elham_gh]

يا به عبارتي بهتر شما بايد به اين سوال پاسخ دهيد ، موارد فوق در كدام فاز ؟ و كدام تكرار

فاز inception تكرار اول!

[Modifier]

سلام علیکم

فاز inception تكرار اول!

در این فاز و تکرار اصلا بحثی در مورد معماری نمیشه !

معماری(4+1) 5 قسمت اصلی داره که اصلی ترین قسمت های آن تا پایان فاز 2 تموم میشه . اگه فرایند رو طبق اصول خودش پیش بری این معماری 4+1 بصورت اتوماتیک آماده میشه یعنی در اصل 4+1 جمع کردن یکسری از محصولات مهمی است که در هر تکرار بدست می آوریم.

موفق باشید
یا علی

[Modifier]

حرف زیر خیلی خوبه !

ما در اين فرآيند توليد نرم افزار نظم ها را چندين بار تكرار خواهيم كرد، پس از لحاظ ديد RUP جمله فوق صحيح نيست. يا به عبارتي بهتر شما بايد به اين سوال پاسخ دهيد ، موارد فوق در كدام فاز ؟ و كدام تكرار

واقعا با داشتن دید مناسب خیلی از گیج بازی هایی که امثال من داریم بوجود نمیاد.

هر موقع سوالی مطرح میکنیم باید بدانیم مربوط به کدام فاز - کدام تکرار - کدام دسیپلین - کدام محصول است ؟

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

[Elham_gh]

در این فاز و تکرار اصلا بحثی در مورد معماری نمیشه !

فكر كنم منم همينو گفتم!!

در ضمن نحوه پاسخ دادنتون اصلا جالب نيست.

[whitehat]

در این فاز و تکرار اصلا بحثی در مورد معماری نمیشه !

فكر كنم منم همينو گفتم!!

در ضمن نحوه پاسخ دادنتون اصلا جالب نيست.

لطفا از ارسال مطالب نا مرتبط با موضوع خودداري كنيد و موارد لازم را در پيام خصوصي مطرح كنيد.

اتفاقا در اين فاز و در تكرار اول در مورد معماري كلان سيستم بايد بحث شود، در بسياري از پروژه ها بعد از تكرار اول بايد قرارداد بسته شود. بسياري از كارفرماها اين صبر را ندارند كه شما بعد از يك ماه اعلام كنيد معماري مورد نظرشان قابل انجام نيست (مثلا نرم افزار بر روي وب كار كند يا ويندوز). البته منظور من از معماري بحث كلان سيستم است. شما در فرجه اي كه در فاز و تكرار اول داريد بايد در مورد معماري (بيشتر نياز هاي غير وظيفه مندي سيستم و چيزهايي كه در نظم آخر يعني Environment بحث ميشود) بايد بحث كنيد، اين آيتم ها معمولا شامل چيزهايي مي شود كه در قرارداد آورده مي شوند.

[smhoseyni]

خوشحالم که بعد از مدت ها مجددا بحث فنی و جالبی در فروم در گرفته است و از کلیه دوستانی که در این بحث شرکت کرده اند تشکر میکنم. امیدوارم این تعامل مثبت بتواند به ارتقاء دانش فنی همه ما کمک کند.
ضمن تأیید صحبت های دوست گرامی جناب Whitehat، چند نکته را هم بنده اضافه میکنم :

اتفاقا در اين فاز و در تكرار اول در مورد معماري كلان سيستم بايد بحث شود، در بسياري از پروژه ها بعد از تكرار اول بايد قرارداد بسته شود. بسياري از كارفرماها اين صبر را ندارند كه شما بعد از يك ماه اعلام كنيد معماري مورد نظرشان قابل انجام نيست (مثلا نرم افزار بر روي وب كار كند يا ويندوز).

همانگونه که ایشان اشاره کرده اند در بعضی پروژه ها لازم است در همان تکرارهای ابتدایی فاز Inception در مورد معماری صحبت شود؛ در مورد پروژه هایی که معماری آن با ریسک های قابل توجهی همراه است، مثلا از تکنولوژی های جدید و ناشناخته ای باید استفاده کنید یا نوع سیستم برای شما جدید است، لازم است امکان پذیری انجام پروژه از لحاظ معماری آن مورد بررسی قرار گیرد، RUP این فعالیت را Architectural Synthesis (سنتز معماری) می نامد و در طی آن شما لازم است نیازمندی های کلیدی معماری سیستم را (عملکردی و غیر عملکردی که غالبا در این گونه موارد نیازمنیدهای غیر عملکردی هستند که ریسک ایجاد می کنند) شناسایی کنید و برای برآورده شدن آن نیازمندی ها راه حلی که به سادگی قابل تصور باشد را ارائه کنید.
این راه حل می تواند به صورت های مختلفی ارائه شود : فهرستی از تکنولوژیهای مورد استفاده، یک مدل UML سطح بالا و یا حتی یک شبیه سازی از معماری مورد نظر. RUP این راه حل ارائه شده را Architectural proof of concept می نامد که هدف آن اثبات امکان پذیری فنی سیستم است. و در نهایت راه حل ارائه شده را در برابر ان نیازمندی ها ارزیابی کنید.
همانگونه که اشاره شد انجام این فعالیت و تهیه فراورده متناظر آن در مواردی که معماری سیستم برای شما شناخته شده است و ریسک مهمی در ارتباط با ان وجود ندارد ضرورتی ندارد.
واضح است که پیش نیاز انجام این فعالیت کسب شناخت از نیازمندی های - در حد تهیه vision، بخصوص بخش های
Product overview, Features, Quality Range & Other requirements(system Requirementsاست که در همان تکرارهای ابتدایی Inception محقق می شود.