تجزیه و تحلیل و مدلسازی سیستم

1. تجزیه و تحلیل و مدلسازی سیستم

2. فصل 1

3. مهندسی نرم افزار : ایجاد روندی سیستماتیک ، منظم و قابل اندازه گیری برای تولید و نگهداری نرم افزار را وظیفه ی علم مهندسی نرم افزار می دانیم. مهندسي نرم افزار، شاخه اي است از مهندسي، كه با بهره گيري از دانشِ علمي، به ارائه ي راه حل هايي مقرون به صرفه، در قالبِ دستاوردهاي نرم افزاري و به منظور حل مسائل و مشكلات عملي و خدمت به جامعه ي بشري، اقدام مي نمايد. سه معیار مهم : 1. زمان 2. هزینه 3. کیفیت نرم افزاری که می خواهیم تولید کنیم. تعریف نرم افزار : مجموعه ای از برنامه های کامپیوتری ، روال ها ، قوانین ، مستندات و داده ها را نرم افزار می گوییم.

4. مسائل و مشکلات نرم افزار در دنیای کنونی: 1. قابلیت اطمینان نرم افزار : بدان معنا که نرم افزار به درستی اجرا شود. 2. هزینه ی نرم افزار : هدف: کاهش هزینه ی خرید نرم افزار با حفظ کیفیت . 3. اعمال تغییرات و دوباره کاری انواع نرم افزار : 1. چکشخوار ( قابل اعمال تغییرات ) 2. غیر چکشخوار ( غیرقابل تغییر ) هدف مهندسی نرم افزار : تولید سیستم به گونه ای که دوباره کاری و تغییر حداقل شود.

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

6. ویژگی های یک نرم افزا ر به صورت یک محصول: Software as a product1. نرم افزار یک محصول مهندسی است و با اصول مهندسی باید تولید شود.2. نرم افزار یک محصول قابل تغییر یا چکشخوار است.3. نرم افزار به دلیل اینکه محصولی فیزیکی نیست ، خراب یا مستهلک نمی شود. اما در عمل به دلیل اعمال تغییرات مداوم شاید دیگر قابل استفاده نبوده و می بایست نرم افزار دیگری جای آن را بگیرد.4. نرم افزار برخلاف بسیاری از محصولات مهندسی دیگر ، قالباً به صورت سفارشی ساخته می شود و از اجزای آماده در آن کمتر استفاده می شود که یکی از اهداف مهندسی نرم افزار ، افزایش استفاده از قطعات نرم افزاری آماده است.دلایل استفاده از مهندسی نرم افزار در پروژه های مهندسی : Why Software Engineering? مهندسی نرم افزار نقش اساسی در بالا بردن کیفیت نرم افزار و کاهش هزینه ها دارد.

7. نقش مهندسی نرم افزار در پروژه های مهندسی : The influencing role of Software Engineering1. کاهش وابستگی به افراد متخصص به صورت خاص2. بالابردن کیفیت ارتباطات تیمی3. تخمین مناسب شامل تخمین زمان و هزینه 4. مدیریت تغییرات 5. کنترل زمان انجام پروژه ها6. برقراری ارتباط و درک متقابل از نرم افزار بین تولید کنندگان، کاربران و مدیران7. انجام و ارائه ی آموزش های مناسب 8. انجام پیش بینی های لازم جهت مواجهه با افزایش توقع کاربراناهداف مهندسی نرم افزار : Software Engineering Goals1. بالا بردن کیفیت : 1- تطبیق نرم افزار با نیازمندیها 2- جوابگویی نیازهای کار بران 3- فارغ از خطا بودن یا کم خطا بودن و کارآیی بالای نرم افزار * نرم افزار با کیفیت مناسب نرم افزاری است که هم نیازهای صریح و هم نیازهای ذهنی ما را رفع نماید. هر چقدر نرم افزار از منابع کمتری استفاده کند ، کارآیی بالاتری دارد.

8. 2. قابل دسترسی باشد.3. اهداف متناقض باید بصورت تعادل درآیند.مهندس نرم افزار فردی است که قواعد و اصول علم مهندسی نرم افزار را در روند ایجاد یک نرم افزار یا در حین تولید یک پروژه ی نرم افزار ی استفاده می کند.ویژگی های یک مهندس نرم افزار ایده آل:1. یک برنامه نویس خوب باشد.2. با روش های مختلف طراحی آشنایی داشته باشد.3. امکان ترجمه و تبدیل نیازهای کاربران 4. قابلیت ارتباط با طیف مختلف کاربران و مدیران 5. دارا بودن قابلیت بالای مدیریتی

9. فصل 2

10. Software Development Processes روال های تولید نرم افزار : ویژگیهای روال های تولید نرم افزار :1. هر روال از یک سری فازهای متنوع ساخته شده است.2. هر فاز با یک خروجی مشخص خاتمه پیدا می کند. ( وقتی فاز تمام شد، نتیجه ی آن یک محصول است . مثل : گزارش ، برنامه ، ... )3. فازهای تولید نرم افزار در روال های مختلف با ترتیب و توالی مختلف انجام می شود.

11. چرا روال تولید به صورت فازبندی یا مرحله بندی شده است؟ 1. هر فاز یا مرحله نگرشی متفاوت به نرم افزار ارائه می دهد.2. شکستن یک مسئله ی بزرگ به مساائل کوچکتر باعث آسان تر شدن حل مسئله می شود.3. ارتقاء کیفیت نرم افزار با فازبندی به دلیل کنترل کیفیت در حین تولید آن انجام می شود.4. فازبندی شدن تولید نرم افزار باعث کاهش هزینه ی تولید می شود. کیفیت بالا می رود ، هزینه ی نگهداری کاهش می یابد. اشکالات هر مرحله یا هر فاز قابل بازبینی هستند و در هر فاز افراد متخصص به آن فاز، روی آن کار می کنند و کار با کیفیت بالاتری انجام می شود.فازها یا مراحل تولید نرم افزار :1. تعیین یا مشخص کردن نیازمندی ها و ارئه ی آن در ی فاز قابل فهم.2. تعیین اینکه کار چطور باید انجام شود تا کیفیت بالا رود. برای اینکه کدام راه ، راه مناسب تری برای انجام نیازمندی ها ست.

12. 3. ارائه ی راهکاری برای پیاده سازی برنامه ای که قبلا نیازهای آن را شناخته ایم. اینکه نیازمند چه اجزایی هستیم و هر جزء باید در کجا قرار بگیرد و چگونه به اجزای دیگر متصل شود.به عنوان مثال در یک طراحی به گونه ی ساخت یافته (مثل زمانی که با زبان C برنامه ای را می نویسیم.) باید مشخص شود چه ماژول ها یا فانکشن هایی دارد و فانکشن ها چگونه در کنار هم قرار می گیرند.4. Implementation ( پیاده سازی یا همان کد نویسی )5. Testing : تست کد نوشته شده :1- unit یا واحد: تست کوچکترین عناصر برنامه ، تست ماژول ها یا function ها2- system : قسمتهای مختلف سیستم را به هم متصل کرده و تست می کنیم . به این نوع تست ، تست آلفا گفته می شود. تستی که در گروه تولید کننده ی نرم افزار به مجتمع برای کل برنامه انجام میشود. 3-acceptance: تست تجاری یا تست بتا. تست قابل قبول بودن پس از تست شرکت یا system به برخی از مشتریان حرفه ای برای تست داده می شود.

13. 6. Conversion یا انتقال : تحویل به مشتری و بردن محصول به محیط کاری واقعی و راه اندازی آن در محیط واقعیروشهای conversion : 1- استراتژی موازی parallel strategy : کار کردن همزمان نرم افزار با نسخه های قبلی برای سیستم هایی که اهمیت بالایی دارند و در صورت ایجاد مشکل، مشکل بزرگ و غیرقابل جبران باشد. 2- قطع ناگهانی Direct Cutover : اینکه تصمیم گرفته شود نرم افزار قبلی از امروز کنار گذاشته شود و نرم افزار جدید مورد استفاده قرار گیرد. ( پس از اطمینان صحت عملکرد )3- راه اندازی نمونه ای Pilot Study : نرم افزار را مثلا برای دو کاربر خاص نوشته و برا ی تست مورد استفاده قرار می دهیم.4- راه اندازی فاز بندی شده Phased : محصول را مرحله به مرحله راه اندازی می کنیم.7. مرحله ی نگهداری یا پشتیبانی maintenance : اگر نرم افزار مشکلاتی داشته باشد ، مجدداً به سازنده مراجعه شده و بررسی می شود.

14. فصل 3

15. روال های اصلی و روال های جانبی تولید نرم افزار :1. مدیریت پروژه : جزء کارهای اصلی نیست ولی پروژه حتما باید مدیریت شود.2. روال مدیریت تغییرات : مدیریت پیکربندی هدف: ایجاد یک روال که تغییرات به صورت منظم و مدون باشد.3. روال مدیریت خود روند تولید: خود روندهای تولید نیز ممکن است در سیر زمان نیازمند تغییر باشند و باید هر جای آن را که ایراد داشت عوض یا اصلاح کنیم.* هر نرم افزار یک خط تولید اصلی و 3 خط تولید فرعی دارد.مدل تجاری Business Models : هر نرم افزار دارای یک سری قواعد و اصول است. به قواعد و قوانینی که سیستم در حالت فعلی دارد، مدل تجاری می گویند.

16. Environment :نیازمندیهای محیطی جهت اجرا یا پیاده سازی نرم افزار تولید شده ، مثل نیازمندی های سخت افزاری و تعیین کاربرانی که قرار است با آنها کار کند.Process Models روال های تولید نرم افزار :1. روال های تولید خطی liner process model : وقتی تغییری انجام دادیم و طراحی کردیم دیگر قادر به بازگشت به مرحله ی قبل و تغییر در آن نیستیم. 1.1- روال آبشاری waterfall model 1.2- prototyping2. روال های تولید آزمایشی یا تکراری : 2.1- روال افزایشی 2.2- روال مارپیچی 2.3- روال معرفی گراروال های تولید یک نرم افزار سبک : روال هایی که در حین تولید مستندات زیادی تولید نمی کنند مثل XP .روال های تولید یک نرم افزار سنگین : روال هایی که در حین تولیدشان حجم زیادی از مستندات تولید می شود .

17. در روال های تولید نرم افزار به صورت خطی دو روال نقش عمده دارند:1. روال خطی (Sequential) : 1.1. مدل آبشاری waterfall 1.2. مدل اجرایی prototype2. آزمایشی یا چرخشی Iterative : فرایند تولید یک سویه یا خطی نیست بلکه یک فرایند چرخشی است. اولین روال تولید (روال آبشاری): 1. شناخت وضع موجود و نیازمندیها 2. طراحی 3. مرحله ی برنامه سازی

18. اشکالات روال آبشاری: 1. در صورت وجود ایراد، قادر به بازگشت و اصلاح نیستیم. 2. اگر نیازمندیها در محیط تغییر بکنند، قادر به تغییر و اصلاح تغییرات نیستیم. تحلیل شده، به فاز طراحی رفته ، ولی نیازمندیها عوض شده یا بیشتر شده اند. 3. کاربر تا انتهای کار، نسخه ای اجرایی نمی بینید. کاربر برای دیدن یک کد باید تا انتهای کار منتظر بماند چون تا برنامه تست نشود، تحویل کاربر نمی شود. Prototype ، اصلاح شده ی waterfall است. در prototype وسط کار، نسخه ای اجرایی برای تست تحویل کاربر می شود و طبق نیازهای کاربر، بقیه ی کار انجام می شود.

19. روال چرخشی یا iterative : 1. افزایشی incremental : روش خوبی است. مناسب پروژه های سبک است. 2. مارپیچی spiral : روال سنگین 3. مؤلفه گرا component base 4. RUP روال سنگین 5. XP روال سبک مزایای روش های تولید چرخشی: 1. امکان اعمال تغییرات در نیازمندیها 2. اتصال قطعات مختلف نرم افزار به صورت

20. 3. کاهش ریسک 4. امکان یادگیری و آموزش نرم افزار به صورت مرحله ای 5. بالا بردن کیفیت محصول (چون در مراحل مختلف خطاها گرفته نمی شوند.) مدل Spiral (مارپیچی): در مدل مارپیچی فرایند تولید نرم افزار به تعدادی ناحیه تقسیم می شود که این تعداد و شرح وظایفی که در هر ناحیه از آنها انجام می شود ، به عهده ی مدیر پروژه می باشد. اما معمولاً نواحی بین 3 تا 6 ناحیه تعریف می شوند. در چرخه های درونی ، معمولاً تمرکز بیشتر بر روی شناخت و تحلیل نیازمندیهاست و در چرخه های بیرونی تمرکز بیشتر بر روی برنامه سازی و تست است.

21. مدل مؤلفه گرا یا Component base : مدل مؤلفه گرا یک تکه نرم افزار تولید شده ی قابل اجراست. ویژگیها: 1. در این تفکر تأیید بر استفاده از component های از قبل آماده است. اگر برای قسمتی از نرم افزار ، component آماده این ، چه نوشته شده توسط خودمان و چه در بازار نرم افزار پیدا نشد، اقدام به تولید component جدید می کنیم. اما با این تفکر که آن component به صورت جامع و کاملی تولید شود که برای پروژه های بعدی نیز قابل استفاده باشد.

22. الگوی انتخاب روال تولید: مواردی که در الگوی انتخاب روال تولید می تواند مؤثر باشد ، عبارتند از: 1. سایز و پیچیدگی پروژه 2. تجربه ی تیم پروژه از لحاظ قابلیت های فنی و آشنایی با حیطه ی مورد نظر 3. زمان و هزینه ی در اختیار سفارشی کردن روند process tailoring: روال های تولید قالب کلی روند انجام کار را برای ما مشخص می کند. اما انتخاب جزئیاتی از قبیل ساختار مستندات ، نحوه ی طراحی ، نحوه ی برنامه سازی و ... به صورت کامل در آنها تعریف نمی شود.

23. منظور از سفارشی کردن روند تولید تعیین کلیدی نکات ، شامل ساختار مستندات ، نحوه ی تحلیل ، نحوه ی طراحی و .. می باشد. این سفارشی کردن در دو سطح اتفاق می افتد. سطح macro و micro. سطح macroمربوط به یک گروه یا شرکت تولید کننده ی نرم افزار بوده و در آن کلیه ی استانداردهای مورد نظر آن گروه یا شرکت تعریف می شود. سطح micro معمولاً برای هر پروژه و با توجه به ماهیت آن پروژه تعیین می شود.

24. فصل 4

25. جمع آوری نیازمندیها و تحلیل سیستم : فاز تولید هر نرم افزار با مرحله ای به نام تعریف مسئله شروع می شود. منظور از تعریف مسئله شناخت محیط و مدل عملکردی سیستم مورد نظر و نیازمندیهای آن به صورت کلی می باشد. در مرحله ی تعریف مسئله نیازمندیهای مشتری نیز مشخص می شود. پس از فاز تعریف مسئله ، فاز تولید سیستم آغاز می گردد. تحلیل سیستم System Analysis : منظور از تحلیل سیستم ، مشخص کردن ویژگیهای سیستم و ساختار آن می باشد و در این مرحله فعالیتهای زیر انجام می شود. 1. شناسایی و تحلیل نیازهای مشتری

26. 2. ارزیابی سیستم به منظور امکان سنجی آن (امکان سنجی : اینکه آیا سیستم با توجه به محدودیتهای زمانی ، اقتصادی و تکنولوژیکی قابل اجرا هست یا نه.) 3.انجام تحلیل های اقتصادی و تکنیکی 4. مشخص کردن نیروی انسانی ، پایگاه داده ها ، سخت افزار و نرم افزار و سایر اجزاء مورد نیاز برای راه اندازی سیستم 5. مشخص کردن محدودیتهای برنامه ریزی و هزینه های سیستم 6. تهیه ی یک گزارش یا مستند که شامل ساختار و تعاریف کلی سیستم و مراحل تولید آن می باشد.

27. امکان سنجی (Feasibility): منظور از امکان سنجی کنترل این نکته است که با توجه به محدودیت های موجود، سیستم از لحاظ پیاده سازی ، امکان پذیر و قابل قبول می باشد و یا پیاده سازی آن میسر نیست؟ بدیهی است پس از این مرحله مشخص می شود که پروژه می تواند ادامه یابد یا می بایست قطع گردد.

28. زمان انجام فعالیت امکان سنجی: زمان انجام فعالیت امکان سنجی پس از مرحله ی شناخت و قبل از سایر مراحل تولید نرم افزار می باشد. مراحل امکان سنجی:Feasibility Study – Phases 1. تحلیل نیاز 2. امکان سنجی اقتصادی 3. امکان سنجی تکنیکی 4. امکان سنجی قانونی 5. ارزیابی گزینه ها

29. تحلیل نیاز: Need Analysis در این مرحله می بایست مشخص کنیم که آیا اصولاً نیازی به تولید یک سیستم جدید وجود دارد یا خیر؟ در این راستا می بایست مطالعات و عملیات زیر انجام شود: 1. شناخت تاریخچه و اطلاعات زیربنایی سازمان مشتری 2. درک نیازمندیها و مشکلات مشتری 3. آشنایی با چارت سازمانی و شرح وظایف امکان سنجی اقتصادی Economic Feasibility در امکان سنجی اقتصادی تحلیل سود و هزینه انجام می شود و اگر مزایا یا سود یک سیستم نسبت به هزینه های آن بیشتر باشد، سیستم از لحاظ امکان سنجی اقتصادی مثبت بوده و قابل پیاده سازی است.

30. در برآورد هزینه ها می بایست هزینه های اولیه برای پروژه، هزینه ی خرید تجهیزات و هزینه های تکراری یا متناوب از قبیل اجاره ی محل نیز لحاظ گردد. امکان سنجی تکنیکی Technical Feasibility در این مرحله می بایست تکنولوژی مورد استفاده در سیستم مشخص گردد و در این راستا تکنولوژی های موجود در سازمان و نیازهای آموزشی نیز هم برای تولید کنندگان نرم افزار و هم برای استفاده کنندگان می بایست مدّ نظر قرار گیرد.

31. امکان سنجی قانونی Legal Feasibility این مرحله شامل بررسی محدودیتها و موانع قانونی برای پیاده سازی سیستم می باشد و در این مرحله مواردی نظیر وجود کپی رایتها ، طراحی یا ساخت مناسب قرار دارد و جلوگیری از به کار بردن جملات یا کلمات متناقض و مبهم در قرارداد می باشد. معمولاً این مرحله با مشاوره ی کارشناسان حقوقی انجام می شود و برای همه ی سیستم ها، خصوصاً سیستم های کوچک و ساده، مورد نیاز نیست.

32. ارزیابی گزینه ها در این مرحله کلیه ی گزینه های موجود برای پیاده سازی سیستم به همراه هزینه و برنامه ریزی انجام آن مشخص شده و تحلیل گر ، یکی از گزینه ها را انتخاب و به مشتری پیشنهاد می دهد. گزارش امکان سنجی پس از انجام مرحله ی امکان سنجی، تحلیل گر گزارشی تحت عنوان گزارش امکان سنجی را آماده می کند که در این گزارش خلاصه ی فعالیتهای انجام شده در مرحله ی امکان سنجی و گزینه های مختلف که برای پیاده سازی سیستم وجود دارد به همراه زمان برنامه ریزی و محدودیتهای هر گزینه ارائه می شود.

33. پیشنهاد پروژه Project Proposal شناسنامه پروژه یا proposal یک مستند یا گزارش می باشد که در آن اطلاعات جامع و کاملی در ارتباط با پروژه از طرف پیمانکار به مشتری یا کارفرما ارائه می شود. اما در بهترین حالت مشتری نیز گزارشی قبل از آن به نام گزارش درخواست برای proposalیاRequest For Proposal(RFP) آماده می کند که در آن مسائل و نیازمندیهای خود را شرح داده است. در proposal اطلاعات زیر معمولاً وجود دارد.

34. 1. تقویم اولیه ی زمان بندی انجام پروژه (زمان بندی در ادامه ی کار ممکن است دچار تغییر شود.) 2. محدوده، ساختار و سرویس های کلی پروژه 3. زمان بندی و توالی انجام مراحل پروژه طبیعتاً این زمان بندی و مراحل می بایست بر مبنای مدل process ارائه شود. 4. مشخص کردن هزینه های سخت افزاری، نرم افزاری و نیروی انسانی. 5. مشخص کردن نیازهای آموزشی (تعداد و محتوای آموزش) 6. مشخص کردن هزینه ی کلی پروژه 7. ذکر مزایا و امکانات پروژه

35. تحلیل نیازمندیها Requirements analysis منظور از تحلیل نیازمندیها را می توان از دو بعد مورد بررسی قرار داد. در بعد اول ما می بایست شناختی از عملکرد سیستم موجود به دست آوریم.(به این مدل، مدل تجاری یا business model ) گفته می شود و در بعد دوم شناخت نیازمندیها انجام می شود. که به این مدل،مدل نیازمندیها یا request model گفته می شود. مدلها در دنیای نرم افزار به دو شکل کلی ساخت یافته(structure) و شیء گرا (object oriented) ساخته می شود.

36. مدلهای ساخت یافته که در حال حاضر کمتر در تولید سیستم ها مورد استفاده قرار می گیرند یا روشی تحت عنوان SSADM(Structured System Analysis and Design)ساخته می شود. اما مدلهای تحلیل و طراحی شیءگرا در حال حاضر غالباً توسط زبانهای مدلسازی UML یا Unified Modeling Languageساخته می شود. فارغ از نوع مدل پس از تکمیل مرحله ی تجزیه تحلیل گزارشی ارائه شده که در آن گزارش کلیه اطلاعات مراحل تحلیل به همراه مدل ها به کارفرما ارائه شده و کارفرما پس از مطالعه ی آن می تواند نظرات و پیشنهادات اصلاحی خود را به تولید کنندگان اعلام کند.

37. SSADM اولین مدل: Context Diagram(نمودار متن) در تحلیل و طراحی SSADM در مرحله ی اول context diagram ساخته می شود. در نمودار DFD از موجودیت های تولید کننده و مصرف کننده ی اطلاعات که با شکل مستطیل نشان داده می شود و پردازش یا process که از شکل دایره استفاده می شود و جریان داده که از فلش یا پیکان استفاده می شود و رسانه ی ذخیره سازی برای داده که از شکل استفاده می شود ساخته شده است.

38. برای سیستم های بزرگ و پیچیده ، مرحله ی تجزیه تحلیل و نمودارهای DFD معمولاً در یک سطح یا یک level کشیده نمی شوند و می توان در هر مرحله جزئیات بیشتری از پروسس ها و داده را نشان داد. در مرحله ی طراحی ، می بایست با استفاده از آخرین سطح DFDها ساختار سیستم را به دست آوریم. منظور از ساختار معماری سیستم در مدل ساخت یافته، ماژول ها و ارتباط بین آنهاست. در این مرحله می بایست دایره ها یا Bubbleها را به ماژول ها اختصاص دهیم.اما این تبدیل می تواند همیشه تبدیل یک به یک نبوده و در بعضی اوقات یک دایره یا bubble به چند ماژول یا برعکس چند bubble به یک ماژول تبدیل شوند.

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

40. تحلیل نیازمندیها: در این مرحله معمولاً فعالیتهای زیر انجام می شود: 1. درک دامنه و حوزه ی اطلاعاتی سیستم 2. مشخص کردن قابلیتها و امکانات مورد نیاز سیستم.3. ساخت یک مدل برای نمایش اطلاعات فوق (همانند مدل DFD در SSADM و یا مدلهای usecase ، activity diagram و ... در مدل UML )4. تفکیک و شکستن مدل طی مراحلی به مدلهای تفصیلی تر . 5. همواره باید در مرحله ی تجزیه تحلیل از اطلاعات کلی ، مرحله به مرحله به اطلاعات تفصیلی یا جزئی رسید.

41. مدلهای اساسی در تجزیه تحلیل سیستم Essential Model 1. مدل محیطی Environmental Model 2. مدل رفتاری Behavioral Model در مدل محیطی ما کل سیستم و محیط در برگیرنده ی آن را که شامل سخت افزار، نرم افزارهای دیگر ، نیروی انسانی می باشد را مدل می کنیم. نمودار متن یا Context Diagram یک نمونه از مدلهای محیطی است. در مدلهای رفتاری ما عملکرد یک سیستم و ارتباط بین عناصر مختلف یک سیستم را به همراه داده های مورد استفاده در سیستم مدل می کنیم. نمودار DFD و نمودار ERD از نمونه مدلهای رفتاری است.

42. فصل 5

43. System Engineering مهندسی سیستم عبارت است از تحلیل ، طراحی و سازمان دهی مجموعه ای از عناصر برای ساخت یک محصول یا سرویس و یا تکنولوژی. در مهندسی سیستم دو محور را می بایست مدّ نظر داشت: 1. مهندسی اطلاعات 2. مهندسی محصول منظور از مهندسی اطلاعات ، شناخت و بررسی ارتباطات بین داده هایی است که در یک حوزه ی تجاری وجود دارد. منظور از مهندسی محصول ، آشنایی با ویژگی ها و نیازمندیهای محصولی است که می بایست تولید شود.

44. در مهندسی سیستم یا system engineering دو راهکار یا الگو وجود دارد. الگوی بالا به پایین (Top Down) و الگوی پایین به بالا (Bottom Up). در بعضی از حالتها می توان از این دو روش به صورت همزمان استفاده کرد. مدلسازی داده ها: Data Modeling منظور از مدلسازی داده ها شناخت داده های اصلی در یک سیستم و اجزای سازنده ی آن و ارتباطت بین آنها می باشد. برای نمایش مدل داده ها غالباً از نموداری به نام نمودار ER (Entity Relationship) استفاده میشود.( ارتباط بین موجودیتها) در این نمودار موجودیتها با box یا مستطیل نمایش داده می شود.

45. هر موجودیت می تواند دارای ویژگیهایی باشد که آن ویژگیها را در داخل یک بیضی نوشته و با یک خط به آن موجودیت متصل می کنیم. ویژگی یکتا و یا به عبارت دیگر کلید اصلی موجودیت را با یک خط مشخص می کنیم. پس از شناخت کلیه ی موجودیتها، ارتباط بین موجودیتها را تشخیص می دهیم و هر دو موجودیتی که با یکدیگر ارتباط دارند را با یک خط به یکدیگر متصل می کنیم. می توان توضیحاتی نیز برای ارتباط در کنار خط یادداشت کرد. ارتباط بین موجودیتها می تواند دارای کمیت cardinality یک به یک ، یک به چند و چند به چند به چند باشد.

46. Modality (اختیاری بودن): منظور از Modality این است که آیا ارتباط به صورت همیشگی وجود دارد و یا در بعضی از شرایط می تواند ارتباط بین دو موجودیت وجود داشته باشد. اگر ارتباط همیشگی باشد Modalityاز هر دو طرف 1 است ولی اگر همیشه نباشد از یک طرف 1 و از طرف دیگر صفر است. (مثل داشتن اشتراک در آژانس.)

47. دیکشنری داده ها (Data Dictionary): دیکشنری داده ها یک مستند یا گزارش است که در مرحله ی تحویل سیستم ساخته شده و در مراحل بعدی یعنی طراحی و یا برنامه سازی ، می تواند کاملتر شود. در این مستند اطلاعات جامع و کاملی در ارتباط با داده های سیستم (چه داده های ماندگار در مقابل پایگاه داده یا فایلهای دیگر و چه داده های مورد استفاده در برنامه ها) وجود دارد. برخی از اطلاعات این مستند می تواند شامل نام داده ها ، نام مستعار آنها ، چگونگی استفاده از داده ها و اطلاعات تکمیلی دیگر باشد. علاوه بر آن نمودارها ER و ساختار و اطلاعات تفصیلی پایگاه داده ها نیز در این مستند قرار می گیرد.

48. فصل 6

49. Designing the System طراحی سیستم: طراحی یک سیستم ، فاز یا مرحله ای است که بین تجزیه تحلیل و برنامه سازی قرار دارد. در این مرحله ، ما با توجه به شناخت نیازمندیها ، مدل ساخته شده را به مدلی تبدیل می کنیم که می توان با کمک آن مدل فاز برنامه سازی را آغاز نماییم. اگر بخواهیم تعریف مناسبی برای طراحی سیستم ارائه دهیم، طراحی عبارت است از استفاده از تکنیکها و اصول مختلف برای ساخت یک محصول.

50. مراحل طراحی سیستم: Steps in the Design Process 1. طراحی معماری سیستم 2. طراحی واسط های سیستم 3. طراحی جزئی یا تفصیلی سیستم در طراحی معماری سیستم ، که اولین مرحله از طراحی می باشد، می بایست عناصر سازنده ی یک سیستم و نحوه ی ارتباط و اتصال آنها مشخص شود. در روش طراحی ساخت یافته این مرحله شامل شناخت ماژول ها و ارتباط بین آنها و در طراحی شیءگرا شامل شناخت کلاسها و ارتباط بین آنهاست.