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

2. فصل 1

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

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

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

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

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

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

9. فصل 2

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

11. چرا روال تولید به صورت فازبندی یا مرحله بندی شده است؟ 1
چرا روال تولید به صورت فازبندی یا مرحله بندی شده است؟ 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 : کار کردن همزمان نرم افزار با نسخه های قبلی برای سیستم هایی که اهمیت بالایی دارند و در صورت ایجاد مشکل، مشکل بزرگ و غیرقابل جبران باشد قطع ناگهانی Direct Cutover : اینکه تصمیم گرفته شود نرم افزار قبلی از امروز کنار گذاشته شود و نرم افزار جدید مورد استفاده قرار گیرد. ( پس از اطمینان صحت عملکرد ) راه اندازی نمونه ای Pilot Study : نرم افزار را مثلا برای دو کاربر خاص نوشته و برا ی تست مورد استفاده قرار می دهیم راه اندازی فاز بندی شده Phased : محصول را مرحله به مرحله راه اندازی می کنیم. 7. مرحله ی نگهداری یا پشتیبانی maintenance : اگر نرم افزار مشکلاتی داشته باشد ، مجدداً به سازنده مراجعه شده و بررسی می شود.

14. فصل 3

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

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

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

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

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

20. 3. کاهش ریسک 4. امکان یادگیری و آموزش نرم افزار به صورت مرحله ای 5
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
تحلیل نیازمندیها: در این مرحله معمولاً فعالیتهای زیر انجام می شود: 1. درک دامنه و حوزه ی اطلاعاتی سیستم 2. مشخص کردن قابلیتها و امکانات مورد نیاز سیستم. 3. ساخت یک مدل برای نمایش اطلاعات فوق (همانند مدل DFD در SSADM و یا مدلهای usecase ، activity diagram و ... در مدل UML ) 4. تفکیک و شکستن مدل طی مراحلی به مدلهای تفصیلی تر . 5. همواره باید در مرحله ی تجزیه تحلیل از اطلاعات کلی ، مرحله به مرحله به اطلاعات تفصیلی یا جزئی رسید.

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

42. فصل 5

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

44. در مهندسی سیستم یا system engineering دو راهکار یا الگو وجود دارد
در مهندسی سیستم یا 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

51. در طراحی واسط ها ، ارتباط سیستم با عوامل بیرونی یعنی با کاربران و یا با سایر سیستم های نرم افزاری و سخت افزاری را مشخص می کنیم. پس طراحی UI یا واسط کاربر نیز جزئی از طراحی واسط هاست و در مرحله ی آخر مرحله ی جزئی و تفصیلی ساختار هر یک از قطعات سازنده ی سیستم (در مورد ساخت یافته، ماژول ها و در مورد شیءگرا کلاسها می باشد.) ساختار هر یک از اجزای سیستم به صورت تفصیلی مشخص می شود. نکات کلیدی و مهم در طراحی سیستم : Key Issues in the Design Process 1. طراحی سیستم ، معمولاً یک روال تکراری است و غالباً در یک مرحله به صورت کامل انجام نمی شود. 2. در طراحی می بایست معیارهایی جهت تشخیص طراحی مناسب و نامناسب داشته باشیم و بتوانیم با کمک این معیارها ، طراحی اصلی محصول را ارزیابی نماییم.

52. برخی از این معیارها عبارتند از : Design Principles 1
برخی از این معیارها عبارتند از : Design Principles 1. اجتناب از دید محدود یا بسته 2. انجام طراحی به صورتی که قابل پیگیری از روی مدل نیازمندیها باشد. 3. عدم اختراع مجدد چرخ . یعنی حتی الامکان از نرم افزارها یا component های آماده استفاده کنیم. 4.استفاده از یک الگوی واحد ( uniform) برای طراحی 5. حدالامکان استفاده از مدلهای قابل فهم در طراحی 6. پیاده سازی طراحی به صورتی که از مشکلات ناگهانی حتی الامکان اجتناب شود.

53. مفاهیم مهم در طراحی : 1. تجرّد یا abstraction Abstraction را می توان در دو بعد داده ها و برنامه ها مدّ نظر داشت. 2. پنهان سازی داده ها information hiding پنهان سازی داده ها یک اصل است و مطابق آن، طراحی مناسب ، طراحی ای است که هر برنامه در آن فقط به داده های مورد نیاز خود دسترسی دارد. 3. Modularity ماژولاریتی (پیماه ای بودن) منظور از ماژولاریتی این است که وظایف یک سیستم و امکانات آن به چه صورت به ماژولها تخصیص یابد. در این ارتباط دو مقوله ی مهم couplying و cohesion وجود دارد که در ادامه به آن می پردازیم. 4. ساختار سلسله مراتب کنترلی control hierarchy

54. Coupling ارتباط بین ماژول های یک سیستم coupling و cohesion دو معیار اصلی در طراحی سیستم می باشد. منظور از coupling ، حجم ارتباط بین ماژولها دریک سیستم است و در طراحی مناسب بهتر است، coupling کمتر باشد. انواع coupling (از بهترین به بدترین): 1. Data coupling اتصال بر مبنای داده (بهترین نوع) در Data coupling ، اتصال بین دو ماژول با انواع داده ای پایه ای انجام می شود. 2. Stamp coupling در این نوع coupling ، یک ساختار داده ای مرکب نظیر آرایه یا link list از ماژول فراخواننده به ماژول ارسال می شود.(یعنی مثلاً a ، b را فراخوانی می کند تا یک کلمه را برایش ارسال کند.)

55. 3. Control coupling : در این حالت پارامتر ردّ و بدل شده بین دو ماژول، یک پارامتر کنترلی است. منظور از داده ی کنترلی، داده ای است که در عباراتی نظیر if ، switch یا حلقه ی while از آن استفاده می شود. 4. Common coupling (کاپلینگ مشترک): در این حالت از داده های public یا عمومی در نرم افزار استفاده می شود. یا به عبارت دیگر داده های مشترکی که ماژول های مختلفی می توانند از آن استفاده کنند. (استفاده از داده های public یک الگوی اشتباه است. چون ناخواسته ممکن است جایی آن متغیر تغییر کند و در کد مشکل اساسی ایجاد نماید. 5. Cohesion چسبندگی: منظور از Cohesion ارتباط محتوایی بین قسمتهای مختلف یک ماژول می باشد و یا به عبارت دیگر ، بیان این مطلب که یک ماژول چه کارهای مختلفی را انجام می دهد. (در حالت ایده آل یک ماژول باید فقط یک کار انجام دهد.)

56. انواع cohesion عبارتند از : Types of Cohesion 1
انواع cohesion عبارتند از : Types of Cohesion 1. Coincidental cohesion چسبندگی تصادفی: در اینجا ماژول کارهای مختلفی را انجام می دهد که هیچ ارتباطی با هم ندارند. 2. Logical cohesion چسبندگی منطقی: در این حالت ماژول کارهای مختلفی را انجام می دهد که از لحاظ منطقی با یکدیگر مرتبطند. (مثلاً ماژول ما انتخاب واحد دانشجو را ثبت می کند و سوابق تحصیلی دانشجو را لیست می کند.) (ثبت ورود و خروج و محاسبه ی اضافه کاری) 3. Temporal cohesion چسبندگی موقت: در این حالت ماژول کارهای مختلفی را انجام می دهد که وجه ارتباطی آنها این است که همه باید در یک مقطع زمانی انجام شود.( انتخاب واحد ، پرداخت پول و تسویه حساب)

57. 4. Communication cohesion چسبندگی ارتباطی: در این حالت ، ماژول کارهای مختلفی را انجام می دهد که در حین آن کارها از داده هایی استفاده می کند که بعضاً مشترک هستند. 5. Sequential چسبندگی ترتیبی ماژول کارهای مختلفی را انجام می دهد که همه ی آنها باید به صورت سریال یا پشت سر هم انجام شود. 6. Informational در این حالت، ماژول کارهای مختلفی را انجام می دهد که وجه ارتباط آنها در این است که همه بر روی ساختارهای داده ای مشترک انجام می شود. 7. Functional چسبندگی تابعی بهترین حالت می باشد و در اینجا ماژول فقط یک کار واحد انجام می دهد. رساندن coupling و cohesion هر دو به حالت ایده آل ممکن نیست.

58. طراحی تفصیلی سیستم: منظور از طراحی تفصیلی سیستم ، طراحی عناصر پایه ای سازنده ی هر سیستم می باشد. در روش structured یا ساخت یافته، این عناصر عبارتند از : functionها ، procedureها و در طراحی شیءگرا این عناصر عبارتند از : classها که در داخل آنها function و procedure داریم. برای طراحی تفصیلی ابزارهای متفاوتی وجود دارد که دو تا از مهمترین آنها عبارتند از فلوچارت و سودوکد seudo code و یا شبه کد. استفاده از فلوچارت در حال حاضر به دلیل حجم بالای آن و فاصله ی آن از زمان برنامه نویسی کمتر رایج می باشد. اما سودوکد به علت حجم کم و نزدیکی به زبان برنامه نویسی مقصد بیشتر استفاده می شود. هنگام طراحی تفصیلی با شبه کد ، طراح ،طراحی فانکشن ها و procedureها را با عباراتی نظیر زبان برنامه نویسی سیستم انجام می دهد و در مرحله ی پیاده سازی برنامه ساز با مشاهده ی شبه کدها، کد نهایی را در محیط مربوطه می نویسد.

59. فصل 7

60. مدیریت پیکربندی نرم افزار Software Configuration : منظور از مدیریت پیکر بندی نرم افزار ، مدیریت کلیه ی اجزای یک نرم افزار شامل برنامه ها ، مستندات و داده ها از زمان ساخت می باشد. تعریف IEEE از مدیریت پیکربندی نرم افزار عبارت است از : روال شناسایی و تعریف کلیه ی itemهای سیستم (شامل متن برنامه، مستندات و داده ها.) کنترل تغییرات این آیتم ها در چرخه ی زندگیشان ثبت و ذخیره ی کلیه ی آیتم ها و کنترل صحت تغییرات انجام شده می باشد. قسمتهای مختلف نرم افزار که می بایست در مدیریت پیکربندی مدّ نظر قرار گیرند عبارتند از: 1. مشخصات گزارشات سیستم 2. برنامه ریطی انجام پروژه 3. گزارش تحلیل نیازمندیها 4. گزارش راهنمای کاربران

61. 5. گزارش طراحی 6. متن برنامه های سیستم 7. گزارش ویژگیهای تست 8
5. گزارش طراحی 6. متن برنامه های سیستم 7. گزارش ویژگیهای تست 8. گزارش نصب و راه اندازی سیستم 9. برنامه های اجرایی 10. شرح پایگاه داده 11. راهنمای کاربران 12. گزارشات نگهداری 13. استانداردها و روال های مهندسی نرم افزار و ...

62. The SCM process : 1. شناسایی اشیاء یا itemها ی موجود در سیستم 2

63. Change Control Accept Change request
Evaluate Change request on the given parameters
Present the Change report
Use the Change report to make a final decision on status and priority of change
Generate ECO for each approved change
Check CI out of project database
Change the CI as required
Check CI into project database
Perform necessary SQA activities
Use appropriate version control mechanisms to create next version of the software

64. کنترل تغییرات پذیرش درخواست تغییر
ارزیابی درخواست تغییر در پارامترهای موجود
ارائه ی گزارش تغییر
استفاده از گزارش تغییر برای اخذ تصمیم نهایی بر روی وضعیت و اولویت تغییر
خارج کردن آیتم مورد نظر از انباره ی پروژه برای انجام تغییرات تأیید شده
بررسی آیتم جهت تغییر خارج از انباره ی پروژه
انجام تغییرات مورد نیاز بر روی آیتم مورد نظر
بازگردان آیتم تغییر یافته به انباره ی پروژه
انجام عملیات کنترل کیفیت لازم
اختصاص نسخه یا ورژن جدید برای آیتم تغییر یافته

65. 1. دریافت و درخواست تغییر 2. بررسی گزارش تغییر از لحاظ پارامترهایی نظیر مسائل فنی و هزینه و زمان آن 3. ساخت گزارش تغییر توسط شخص یا تیم مربوطه 4. تعیین انجام یا عدم انجام تغییر و اولویت آن توسط مدیریت 5. خارج کردن آیتم مورد نظر برای تغییر از انباره ی پروژه (الکترونیکی (hard) یا فیزیکی(گزارش)) 6. اعمال تغییرات روی آیتم مورد نظر 7. انجام عملیات کنترل کیفیت لازم 8. بازگرداندن آیتم به انباره ی پروژه 9. اختصاص نسخه یا ورژن (version) جدید برای آیتم تغییر یافته.

66. انباره ی SCM (انباره ی مدیریت پیکربندی) منظور از انباره ی SCM محل فیزیکی و الکترونیکی است که در آن کلیه ی اطلاعات پروژه نگهداری می شود. بدیهی است این محل می بایست مقیاس پذیر ، قابل اطمینان ، در دسترس و شفاف باشد. ابزارهای SCM : برای مدیریت SCM ابزارهای نرم افزاری متفاوتی وجود دارد که می تواند کار SCM را تسهیل نماید. دو تا از مهمترین این ابزارها عبارتند از : 1. Configuration Management Assistant 2. Adele

67. فصل 8

68. فاز نگهداری : فاز نگهداری آخرین مرحله چرخش زندگی هر نرم افزار می باشد و پس از نصب و راه اندازی نرم افزار ، آغاز و تا انتهای استفاده از نرم افزار ادامه می یابد. Maintenance: فعالیتهایی است شامل ارتقاء (بالا بردن سرویسهای آن)، تطابق یا adapting و اصلاح یا correcting می باشد.(برطرف کردن مشکلات) انواع مشکلاتی که در maintenance یا فاز نگهداری هستند به 3 دسته تقسیم می شوند: 1. Emergency fix (اصلاحات اضطراری) این دسته از مشکلات ، مشکلاتی هستند که در کار سیستم ، اختلالات جدّی به وجود آورده و می بایست در اسرع وقت برطرف شوند.

69. 2. Urgent fix (اصلاحات ضروری) این دسته از مشکلات نیز حتماً می بایست در سیستم برطرف شود اما سرعت برطرف کردن آنها می تواند دیرتر از اصلاحات ضروری باشد. 3. Nice to have fix (اصلاحات ارجح یا مناسب) این گونه اصلاحات یا تغییرات بهتر است در سیستم انجام شود. اما اولویت زمانی برای انجام آنها بالا نمی باشد. مشکلات مرحله ی نگهداری : 1. وجود پرسنل دینامیک Dynamic personnel : که هزینه ی آموزش زیادی را می تواند به سیستم تحمیل کند. 2. Motivation and morale 3. Lack of documentation

70. 4. Pathy code عدم یکپارچگی کد(قطعه قطعه بودن آن) 5
4. Pathy code عدم یکپارچگی کد(قطعه قطعه بودن آن) 5. Outdated or obsolete technology استفاده از تکنولوژی از رده خارج 6. Round-the-clock operation فعالیت های 24 ساعته یا شبانه روزی Maintenance Metrics : 1. System availability 2. Maintenance turnaround 3. Productivity منظور از Productivity حجم نرم افزاری است که در مرحله ی maintenance در یک مقطع زمانی تولید می شود.

71. نکات کلیدی در مرحله ی نگهداری Key Factors affecting Maintenance 1
نکات کلیدی در مرحله ی نگهداری Key Factors affecting Maintenance 1. متوسط زمانی که یک شخص در طی آن می تواند با سیستم آشنا شود. 2. وجود یا عدم وجود مستندات مناسب 3. در نظر گرفتن این نکته که هر فعالیت موجود در maintenance باعث کاهش عمر مفید نرم افزار می شود.

72. فصل 9

73. پیاده سازی نرم افزار : منظور از پیاده سازی ، انتقال نرم افزار پس از تکمیل آن به سایت اصلی و راه اندازی آن است. فعالیتهایی که در حین راه اندازی هستند: 1. آماده کردن برنامه نصب 2. انجام روال های عملیاتی لازم 3. آماده سازی و تبدیل داده ها 4. آموزش کاربران 5. راه اندازی سیستم

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

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

76. 4. آموزش کاربران User Training: آموزش کاربران در دو سطح انجام می شود: 1. آموزش اپراتورهای سیستم 2. آموزش مدیران راهبری سیستم در آموزش مدیران (admins )مواردی از قبیل استفاده ی درست از تجهیزات ، عیب یابی اولیه و فعالیتهای لازمی که در فاز پشتیبانی انجام می شوند را می بایست به آنها آموزش داد. در آموزش به اپراتورها یا end userهای سیستم ، مواردی از قبیل استفاده از تجهیزات ، استفاده از برنامه ی کاربردی، استفاده از داده های سیستم ، امکان اضافه ، حذف و یا ویرایش اطلاعات در سیستم ، گرفتن گزارشات از سیستم،بهینه سازی اطلاعات دریافتی از سیستم و عیب یابی های اولیه می بایست آموزش داده شود.

77. چهار استراتژی برای راه اندازی سیستم وجود دارد که عبارتند از :
5. استراتژیهای راه اندازی سیستم Implementation Strategies :
چهار استراتژی برای راه اندازی سیستم وجود دارد که عبارتند از :
1. استراتژی موازی
2. استراتژی قطع
3. استراتژی فازبندی یا مرحله بندی
4. استراتژی آزمایشی
در استراتژی موازی، سیستم جدید و سیستم قدیم به صورت موازی با هم اجرا می شوند. هدف از این استراتژی بالا بردن قابلیت اطمینان سیستم و مشخص کردن خطاهایی است که تا لحظه نصب در سیستم برطرف نشده اند.

78. Implementation Strategies Contd…

79. اما این استراتژی نیاز به نیروی کار و هزینه ی زیادی دارد
اما این استراتژی نیاز به نیروی کار و هزینه ی زیادی دارد. این استراتژی مناسب سیستم هایی هستند که اهمیت بالایی دارند مثل سیستم های مالی. 2. در استراتژی قطع یا direct cutover approach در هنگام راه اندازی ، اجرای سیستم قدیمی ، قطع و سیستم جدید جایگزین آن می شود. 3. استراتژی فازبندی شده: در این استراتژی، نصب و راه اندازی سیستم جدید به صورت مرحله به مرحله انجام می شود. به عنوان مثال در یک سیستم آموزش دانشجویی در ابتدا، سیستم انتخاب واحد، سپس زیر سیستم محاسبه ی شهریه و در ادامه زیر سیستم های دیگر راه اندازی می شوند. در این مورد مشکلات ، مرحله به مرحله رفع می شوند و فشاری به کل سیستم وارد نمی شود. این مورد مناسب سیستم هایی است که بخشهای مختلف آن جداجدا هستند و مستقل عمل می کنند. 4. استراتژی آزمایشی (Pilot) : برای کاربران خاصی (متخصص) مورد بررسی قرار می گیرد.

80. معیارهای انتخاب استراتژی راه اندازی : 1
معیارهای انتخاب استراتژی راه اندازی : 1. ماهیت و سایز سیستم: (هر چه سیستم بزرگتر و پیچیده تر باشد، به سمت استراتژیهای موازی و آزمایشی پیش می رویم.) 2. نوع سازمان مشتری : (ساختار سازمانی) 3. وجود واحد انفورماتیک یا کامپیوتر در داخل سازمان مشتری 4. تعداد کاربرانی که با سیستم ارتباط برقرار می کنند. 5. حجم داده های سیستم. 6. پراکندگی جغرافیایی سیستم (داخل سازمانی یا بیرون سازمانی) (استراتژی مناسب: آزمایشی و فازبندی شده) 7. استفاده از ابزارها یا tools مناسب (استراتژی مناسب: استراتژی قطع) 8. در دسترس بودن نیروی انسانی : (بدون داشتن نیروی انسانی استراتژی موازی قابل اجرا نیست.) 9. درجه ی اهمیت و بحرانی بودن نرم افزار : (نرم افزارهایی که اهمیت و پیچیدگی انجام کار بالایی دارند، مثل نرم افزارهای مالی ، در آنها سراغ استراتژی قطع نمی رویم.)

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

82. 4. آیا برای راهبری سیستم جدید، به اپراتورهای کمتر یا بیشتری نسبت به سیستم قدیم احتیاج است؟ 5. آیا سیستم جدید روالهای اجرایی و عملیاتی سازمان را بهبود بخشیده است؟ 6. آیا سیستم جدید ، ضریب تولید را افزایش داده است؟ 7. آیا سیستم جدید، سرویس دهی به مشتریان را بهبود بخشیده است؟ برنامه ریزی حالتهای بحرانی منظور از برنامه ریزی حالتهای بحرانی، پیش بینی مشکلاتی است که از لحاظ سخت افزاری یا نرم افزاری می تواند در آینده به وجود بیاید و ارائه ی راهکارهایی برای مواجهه با آنهاست. برخی از این راهکارها، عبارتند از : استفاده از کامپیوترهای پشتیبان ، امکان اتصال با خطوط پرسرعت به نقاط دیگر و امکان استفاده از سیستم دستی.

83. فصل 10

84. تحلیل و طراحی نرم افزار به روش شیءگرایی: همانطور که ذکر شد، دو روش عمده برای تولید نرم افزار وجود دارد که عبارتند از : روش ساخت یافته یا Structured و روش شیءگرا یا Object Oriented در روش ساخت یافته ،پایه و اساس مدلهای تجزیه و تحلیل بر مبنای جریان داده ها و data flow بوده و طراح ساخت یافته، این مدلها را که عموماً بر مبنای DFD می باشند، به یک ساختار که در آن ماژولها و ارتباز ماژولها نشان داده شده است، تبدیل کرده و سپس ساختار درون هر ماژول را با ابزارهایی نظیر فلوچارت و یا سودوکد طراحی می کند و برنامه نویس با توجه به مدل طراحی ، اقدام به ساخت کدها می نماید.

85. در تجزیه تحلیل شیءگرا، تمرکز تحلیل گر بر روی رفتارهایی است که یا در حال حاضر در سیستم انجام می شود (مدل تجاری business mode ) و رفتارهایی که می خواهیم بعداً در سیستم اضافه یا انجام شود.(requirement model) در مدلسازی شیءگرا، این مدلها، غالباً با زبان UML و با زبان use case ساخته می شود. پس از آن تحلیل گر می تواند با استفاده از مدلهای تکمیلی ، نحوه ی ردّ و بدل شده پیغامها بین اشیاء (نمودارهای sequence و collaboration ) و یا چرخه های کاری (work flows) (نمودار فعالیت activity) و نمودار وضعیت برای نشان دادن وضعیت اشیاء و نحوه ی تبدیل این وضعیتها به یکدیگر (state chart diagram ) استفاده می کند و سپس طراح شیءگرا با استفاده از مدلهای فوق ، می بایست قطعات اصلی سیستم که در مورد شیءگرا ، کلاسها و component ها هستند را شناسایی کرده و ارتباط بین آنها را بدست آورد و سپس برای هر کلاس ویژگی ها و رفتارهای (Methods) آن را مشخص کرده و متدها را با استفاده از شبه کد طراحی نماید.

86. ویژگیهای پروژه های شیءگرایی: 1
ویژگیهای پروژه های شیءگرایی: 1. مشخص کردن یک روال تولید چرخشی (iterative) 2. تخمین زدن زمان و هزینه ی انجام پروژه با استفاده از روال تولید انتخاب شده. 3. مشخص کردن نقاط سنجش (milestones) و نحوه ی اندازه گیری پیشرفت انجام پروژه . 4. مشخص کردن نقاط مهم برای کنترل کیفی نرم افزار (در مراحل تولید) 5. مدیریت تغییرات 6. مشاهده ،پیگیری و کنترل پیشرفت انجام پروژه

87. Object Oriented Metrics برخی از استانداردهای مورد استفاده در پروژه های object oriented عبارتند از : 1. تعداد متدها در یک کلاس ( اگر تعداد متدهای کلاسی از حدی بیشتر شد، باید آن را به کلاسهای کوچکتر تفکیک کرد.) 2. عمق درخت و وراثت. 3. تعداد اشیاء نمونه گرفته شده از یک کلاس 4. بررسی coupling بین کلاسها 5. واکنش ها یا پاسخ هایی که به یک کلاس داده می شود. 6. کمبود چسبندگی یا cohesion در محیط های یک کلاس.

88. تخمین زدن یک پروژه ی شیءگرا Estimating an O
تخمین زدن یک پروژه ی شیءگرا Estimating an O.O project: برای تخمین زدن پروژ] های شیءگرا ، می توان از معیارها یا موازین زیر استفاده کرد: 1. تعدا usecase ها و سناریوهای آنها (هر چه تعداد آنها بیشتر باشد ، حجم کد بیشتری مورد نیاز است.) 2. تعداد کلاسهای اصلی 3. مشخص کردن واسط ها یا interface ها و کلاسهای لازم برای پیاده سازی آنها. (هر واسطی که سیستم را به محیط بیرونی مرتبط می کند.) 4. محاسبه و بازبینی تخمین ها بر مبنای کلاسها برنامه ریزی پروژه های شیءگرا: 1. پروژه های شیءگرا با پروسس های چرخشی پیاده سازی می شوند. 2. در برنامه ریزی برای این پروژه ها می بایست : 1-2. تعدا چرخش های مورد نیاز را تخمین زد مشخص کرد که در انتهای هر چرخه ، چه حجم یا درصدی از کارها انجام شده است.