موضوع مهم : چگونگی شروع تحلیل یک سیستم

با سلام

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

وقتی هم که شروع میکنند یا بی خیال اعمال و فرایندهای مهندسی میشوند و به سراغ روش "علی اصغری" میروند یا اینکه از جایی و با عملی شروع میکنند که استاندارد و اصولی نیست.

از همین فروم هم بعضی وقتها مشخصه هنوز هیچ کاری نکرده بدنبال usecase میگرده !!

من خواستم در این تاپیک چند نکته ایی که با تجربه و تحقیق بدست آوردم رو خدمت شما دوستان عرض کنم در مورد

اینکه چگونه قدم اول رو برداریم. به صورت کاربردی و مفید انشاالله

البته اگر دوستان در تکمیل یا تصحیح صحبت های من نکته ایی دارند حتما بگن که همه ما خوشحال میشیم :

____________

به نظر من در قدم اول ما نیاز به یک problem statement داریم .
problem statement که روند کاری سیستم یا چگونگی استفاده سیستم توسط افراد ، ماشین یا برنامه های دیگر را شرح میدهد.
امکاناتی که سیستم نیاز دارد (معمولی (Normal requirements)- مورد انتظار(Expected requirements) - جالب توجه(Exciting requirements)) در problem statement بحث میشود و شرح داده میشود

problem statement با تحقیق ، پرسش و مطالعه بدست میآید :

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

تا اینجا یک قدم خیلی مهم برداشته شده است. خیلی مهم

بعد به سراغ usecase ها میروید که سیستم را از دیدگاه کاربر نهایی مدل سازی میکند(که شرح آن در problem statement آمده است)

البته قبل از بدست آوردن usecase ها 2 کار مهم را باید انجام دهید که خیلی مهم است :


1) استخراج Actor ها با توجه به problem statement .

2) هر Actor چه کاری در روند سیستم انجام میدهد.


بعد با توجه به 2 قسمت بالا بخصوص قسمت 2 usecase ها رو استخراج میکنیم.

نکته :
سعی کنید لیستی که برای کارهای هر actor مینویسید ریز کارها باشد تا هم دید بهتری نسبت به روند کاری سیستم داشته باشیم و هم بتوان با دسته بندی آنها به usecase های مورد نظر رسید.

توضیح مهم :

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

بعد از بدست آوردن usecase ها به سراغ شرح usecase ها میرویم(usecase Description) که این مورد نیز بسیار مهم میباشد. انشاالله در فرصتی مناسب (نچندان نزدیک) در مورد آن توضیح مفید و کاربردی خواهم داد.

مطالبی که عرض شد قسمتی از آن از کتاب پرسمن ، سایتهای مختلف و تجربه عملی بوده است.

موفق باشید.

یا علی

سلام خسته نباشيد !
من قبلا يك سيستم را تجزيه تحليل و طراحي كردم ولي الان استادمون گفته كه سيستمي را تجزيه و تحليل كنيد كه در همه ي سيستم ها قابل تعميم باشه ! راستش خودم يه تعاريفي را براش ارائه دادم ولي نمي دونم چطور مي تونم اين تعارف را گسترش بدم ! ميشه كمكم كنيد ؟

نقل قول:

---

نوشته شده توسط merelin

سلام خسته نباشيد !
من قبلا يك سيستم را تجزيه تحليل و طراحي كردم ولي الان استادمون گفته كه سيستمي را تجزيه و تحليل كنيد كه در همه ي سيستم ها قابل تعميم باشه ! راستش خودم يه تعاريفي را براش ارائه دادم ولي نمي دونم چطور مي تونم اين تعارف را گسترش بدم ! ميشه كمكم كنيد ؟

---

سئوالتون واضح نیست . یعنی چی که سيستمي را تجزيه و تحليل كنيد كه در همه ي سيستم ها قابل تعميم باشه ! میشه بیشتر توضیح بدید؟

نقل قول:

---

نوشته شده توسط merelin

سلام خسته نباشيد !
من قبلا يك سيستم را تجزيه تحليل و طراحي كردم ولي الان استادمون گفته كه سيستمي را تجزيه و تحليل كنيد كه در همه ي سيستم ها قابل تعميم باشه ! راستش خودم يه تعاريفي را براش ارائه دادم ولي نمي دونم چطور مي تونم اين تعارف را گسترش بدم ! ميشه كمكم كنيد ؟

---

سلام علیکم

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

ولی در مورد طراحی که قضیه فرق میکنه ...

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

یا بهتره بگم اگه طراحیه پیاده شده بخواد همه جا کار بده باید دنبالش امکانات اون زبان یا framework رو نیز روی سیستم مورد نظر قرار گیرد.

در آخر اینکه این مباحث خیلی تبصره ها و ریزه کاری هم داره که خودتون باید یاد بگیرید و اگه یاد گرفتید به ما هم بگید فعلا همین ها کافیه.

موفق باشید.

یا علی.

نقل قول:

---

نوشته شده توسط Modifier

سلام علیکم

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

ولی در مورد طراحی که قضیه فرق میکنه ...

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

یا بهتره بگم اگه طراحیه پیاده شده بخواد همه جا کار بده باید دنبالش امکانات اون زبان یا framework رو نیز روی سیستم مورد نظر قرار گیرد.

در آخر اینکه این مباحث خیلی تبصره ها و ریزه کاری هم داره که خودتون باید یاد بگیرید و اگه یاد گرفتید به ما هم بگید فعلا همین ها کافیه.

موفق باشید.

یا علی.

---

اینکه گفتید " اسناد تحلیل مختص به سیستم خاصی نباشه"، منظورتون در یک Problem Domain ثابت اینطوری (یعنی بین System Responsibility های داخل این PD فرق نکنه) یا نه توی PD های مختلف فرق نکنه.
منظورم از Problem Domain چیزی مثل سیستمی برای آژانس های تاکسی تلفنی ولی System Responsibility توی این Problem Domain از یه آژانس بالاشهری با یه آژانس پایین شهری فرق می کنه.