تجزیه و تحلیل و مدلسازی سیستم
Download
1 / 88

تجزیه و تحلیل و مدلسازی سیستم - PowerPoint PPT Presentation


  • 162 Views
  • Uploaded on

تجزیه و تحلیل و مدلسازی سیستم. استاد : مهسا رضایی. فصل 1. مهندسی نرم افزار : ایجاد روندی سیستماتیک ، منظم و قابل اندازه گیری برای تولید و نگهداری نرم افزار را وظیفه ی علم مهندسی نرم افزار می دانیم.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' تجزیه و تحلیل و مدلسازی سیستم' - cullen-tanner


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript


مهندسی نرم افزار :

ایجاد روندی سیستماتیک ، منظم و قابل اندازه گیری برای تولید و نگهداری نرم افزار را وظیفه ی علم مهندسی نرم افزار می دانیم.

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

سه معیار مهم :

1. زمان 2. هزینه 3. کیفیت نرم افزاری که می خواهیم تولید کنیم.

تعریف نرم افزار :

مجموعه ای از برنامه های کامپیوتری ، روال ها ، قوانین ، مستندات و داده ها را نرم افزار می گوییم.


مسائل و مشکلات نرم افزار در دنیای کنونی:

1. قابلیت اطمینان نرم افزار : بدان معنا که نرم افزار به درستی اجرا شود.

2. هزینه ی نرم افزار : هدف: کاهش هزینه ی خرید نرم افزار با حفظ کیفیت .

3. اعمال تغییرات و دوباره کاری

انواع نرم افزار :

1. چکشخوار ( قابل اعمال تغییرات ) 2. غیر چکشخوار ( غیرقابل تغییر )

هدف مهندسی نرم افزار :

تولید سیستم به گونه ای که دوباره کاری و تغییر حداقل شود.


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


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

مهندسی نرم افزار نقش اساسی در بالا بردن کیفیت نرم افزار و کاهش هزینه ها دارد.


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


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


فصل 2 مهندسی :


Software مهندسی : Development Processes

روال های تولید نرم افزار :

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


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


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

3-acceptance: تست تجاری یا تست بتا. تست قابل قبول بودن پس از تست شرکت یا system به برخی از مشتریان حرفه ای برای تست داده می شود.


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


فصل 3 برنامه ای که قبلا نیازهای آن را شناخته ایم. اینکه نیازمند چه اجزایی هستیم و هر جزء باید در کجا قرار بگیرد و چگونه به اجزای دیگر متصل شود.


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


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


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

1. شناخت وضع موجود و نیازمندیها

2. طراحی

3. مرحله ی برنامه سازی


اشکالات روال آبشاری: صورت خطی دو روال نقش عمده دارند:

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

2. اگر نیازمندیها در محیط تغییر بکنند، قادر به تغییر و اصلاح تغییرات نیستیم. تحلیل شده، به فاز طراحی رفته ، ولی نیازمندیها عوض شده یا بیشتر شده اند.

3. کاربر تا انتهای کار، نسخه ای اجرایی نمی بینید. کاربر برای دیدن یک کد باید تا انتهای کار منتظر بماند چون تا برنامه تست نشود، تحویل کاربر نمی شود.

Prototype ، اصلاح شده ی waterfall است.

در prototype وسط کار، نسخه ای اجرایی برای تست تحویل کاربر می شود و طبق نیازهای کاربر، بقیه ی کار انجام می شود.


روال چرخشی یا صورت خطی دو روال نقش عمده دارند:iterative :

1. افزایشی incremental : روش خوبی است. مناسب پروژه های سبک است.

2. مارپیچی spiral : روال سنگین

3. مؤلفه گرا component base

4. RUP روال سنگین

5. XP روال سبک

مزایای روش های تولید چرخشی:

1. امکان اعمال تغییرات در نیازمندیها

2. اتصال قطعات مختلف نرم افزار به صورت


3. کاهش ریسک صورت خطی دو روال نقش عمده دارند:

4. امکان یادگیری و آموزش نرم افزار به صورت مرحله ای

5. بالا بردن کیفیت محصول (چون در مراحل مختلف خطاها گرفته نمی شوند.)

مدل Spiral (مارپیچی):

در مدل مارپیچی فرایند تولید نرم افزار به تعدادی ناحیه تقسیم می شود که این تعداد و شرح وظایفی که در هر ناحیه از آنها انجام می شود ، به عهده ی مدیر پروژه می باشد. اما معمولاً نواحی بین 3 تا 6 ناحیه تعریف می شوند. در چرخه های درونی ، معمولاً تمرکز بیشتر بر روی شناخت و تحلیل نیازمندیهاست و در چرخه های بیرونی تمرکز بیشتر بر روی برنامه سازی و تست است.


مدل مؤلفه گرا یا صورت خطی دو روال نقش عمده دارند:Component base :

مدل مؤلفه گرا یک تکه نرم افزار تولید شده ی قابل اجراست.

ویژگیها:

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


الگوی انتخاب روال تولید: صورت خطی دو روال نقش عمده دارند:

مواردی که در الگوی انتخاب روال تولید می تواند مؤثر باشد ، عبارتند از:

1. سایز و پیچیدگی پروژه

2. تجربه ی تیم پروژه از لحاظ قابلیت های فنی و آشنایی با حیطه ی مورد نظر

3. زمان و هزینه ی در اختیار

سفارشی کردن روند process tailoring:

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


منظور از سفارشی کردن روند تولید تعیین کلیدی نکات ، شامل ساختار مستندات ، نحوه ی تحلیل ، نحوه ی طراحی و .. می باشد.

این سفارشی کردن در دو سطح اتفاق می افتد. سطح macro و micro.

سطح macroمربوط به یک گروه یا شرکت تولید کننده ی نرم افزار بوده و در آن کلیه ی استانداردهای مورد نظر آن گروه یا شرکت تعریف می شود.

سطح micro معمولاً برای هر پروژه و با توجه به ماهیت آن پروژه تعیین می شود.


فصل 4 تولید تعیین کلیدی نکات ، شامل ساختار مستندات ، نحوه ی تحلیل ، نحوه ی طراحی و .. می باشد.


جمع آوری نیازمندیها و تحلیل سیستم :

فاز تولید هر نرم افزار با مرحله ای به نام تعریف مسئله شروع می شود.

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

تحلیل سیستم System Analysis :

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

1. شناسایی و تحلیل نیازهای مشتری


2. ارزیابی سیستم به منظور امکان سنجی آن

(امکان سنجی : اینکه آیا سیستم با توجه به محدودیتهای زمانی ، اقتصادی و تکنولوژیکی قابل اجرا هست یا نه.)

3.انجام تحلیل های اقتصادی و تکنیکی

4. مشخص کردن نیروی انسانی ، پایگاه داده ها ، سخت افزار و نرم افزار و سایر اجزاء مورد نیاز برای راه اندازی سیستم

5. مشخص کردن محدودیتهای برنامه ریزی و هزینه های سیستم

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


امکان سنجی سنجی آن (Feasibility):

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


زمان انجام فعالیت امکان سنجی: سنجی آن

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

مراحل امکان سنجی:Feasibility Study – Phases

1. تحلیل نیاز

2. امکان سنجی اقتصادی

3. امکان سنجی تکنیکی

4. امکان سنجی قانونی

5. ارزیابی گزینه ها


تحلیل نیاز سنجی آن : Need Analysis

در این مرحله می بایست مشخص کنیم که آیا اصولاً نیازی به تولید یک سیستم جدید وجود دارد یا خیر؟ در این راستا می بایست مطالعات و عملیات زیر انجام شود:

1. شناخت تاریخچه و اطلاعات زیربنایی سازمان مشتری

2. درک نیازمندیها و مشکلات مشتری

3. آشنایی با چارت سازمانی و شرح وظایف

امکان سنجی اقتصادی Economic Feasibility

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


در برآورد هزینه ها می بایست هزینه های اولیه برای پروژه، هزینه ی خرید تجهیزات و هزینه های تکراری یا متناوب از قبیل اجاره ی محل نیز لحاظ گردد.

امکان سنجی تکنیکی Technical Feasibility

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


امکان سنجی های اولیه برای پروژه، هزینه ی خرید تجهیزات و هزینه های تکراری یا متناوب از قبیل اجاره ی محل نیز لحاظ گردد.قانونی Legal Feasibility

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


ارزیابی گزینه ها های اولیه برای پروژه، هزینه ی خرید تجهیزات و هزینه های تکراری یا متناوب از قبیل اجاره ی محل نیز لحاظ گردد.

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

گزارش امکان سنجی

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


پیشنهاد پروژه های اولیه برای پروژه، هزینه ی خرید تجهیزات و هزینه های تکراری یا متناوب از قبیل اجاره ی محل نیز لحاظ گردد.Project Proposal

شناسنامه پروژه یا proposal یک مستند یا گزارش می باشد که در آن اطلاعات جامع و کاملی در ارتباط با پروژه از طرف پیمانکار به مشتری یا کارفرما ارائه می شود.

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


1. تقویم اولیه ی زمان بندی انجام پروژه (زمان بندی در ادامه ی کار ممکن است دچار تغییر شود.)

2. محدوده، ساختار و سرویس های کلی پروژه

3. زمان بندی و توالی انجام مراحل پروژه

طبیعتاً این زمان بندی و مراحل می بایست بر مبنای مدل process ارائه شود.

4. مشخص کردن هزینه های سخت افزاری، نرم افزاری و نیروی انسانی.

5. مشخص کردن نیازهای آموزشی (تعداد و محتوای آموزش)

6. مشخص کردن هزینه ی کلی پروژه

7. ذکر مزایا و امکانات پروژه


تحلیل پروژه (زمان بندی در ادامه ی کار ممکن است دچار تغییر شود.)نیازمندیها Requirements analysis

منظور از تحلیل نیازمندیها را می توان از دو بعد مورد بررسی قرار داد.

در بعد اول ما می بایست شناختی از عملکرد سیستم موجود به دست آوریم.(به این مدل، مدل تجاری یا business model ) گفته می شود و در بعد دوم شناخت نیازمندیها انجام می شود. که به این مدل،مدل نیازمندیها یا request model گفته می شود.

مدلها در دنیای نرم افزار به دو شکل کلی ساخت یافته(structure) و شیء گرا (object oriented) ساخته می شود.


مدلهای پروژه (زمان بندی در ادامه ی کار ممکن است دچار تغییر شود.)ساخت یافته که در حال حاضر کمتر در تولید سیستم ها مورد استفاده قرار می گیرند یا روشی تحت عنوان SSADM(Structured System Analysis and Design)ساخته می شود.

اما مدلهای تحلیل و طراحی شیءگرا در حال حاضر غالباً توسط زبانهای مدلسازی UML یا Unified Modeling Languageساخته می شود.

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


SSADM پروژه (زمان بندی در ادامه ی کار ممکن است دچار تغییر شود.)

اولین مدل: Context Diagram(نمودار متن)

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

استفاده می شود ساخته شده است.


برای سیستم های بزرگ و پیچیده ، مرحله ی تجزیه تحلیل و نمودارهای DFD معمولاً در یک سطح یا یک level کشیده نمی شوند و می توان در هر مرحله جزئیات بیشتری از پروسس ها و داده را نشان داد.

در مرحله ی طراحی ، می بایست با استفاده از آخرین سطح DFDها ساختار سیستم را به دست آوریم. منظور از ساختار معماری سیستم در مدل ساخت یافته، ماژول ها و ارتباط بین آنهاست.

در این مرحله می بایست دایره ها یا Bubbleها را به ماژول ها اختصاص دهیم.اما این تبدیل می تواند همیشه تبدیل یک به یک نبوده و در بعضی اوقات یک دایره یا bubble به چند ماژول یا برعکس چند bubble به یک ماژول تبدیل شوند.


تکنیکهای جمع آوری اطلاعات در مرحله تجزیه تحلیل:

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


تحلیل نیازمندیها: مرحله تجزیه تحلیل:

در این مرحله معمولاً فعالیتهای زیر انجام می شود:

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

5. همواره باید در مرحله ی تجزیه تحلیل از اطلاعات کلی ، مرحله به مرحله به اطلاعات تفصیلی یا جزئی رسید.


مدلهای اساسی در تجزیه تحلیل مرحله تجزیه تحلیل:سیستم Essential Model

1. مدل محیطی Environmental Model

2. مدل رفتاری Behavioral Model

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

نمودار متن یا Context Diagram یک نمونه از مدلهای محیطی است. در مدلهای رفتاری ما عملکرد یک سیستم و ارتباط بین عناصر مختلف یک سیستم را به همراه داده های مورد استفاده در سیستم مدل می کنیم.

نمودار DFD و نمودار ERD از نمونه مدلهای رفتاری است.


فصل 5 مرحله تجزیه تحلیل:


System Engineering مرحله تجزیه تحلیل:

مهندسی سیستم عبارت است از تحلیل ، طراحی و سازمان دهی مجموعه ای از عناصر برای ساخت یک محصول یا سرویس و یا تکنولوژی.

در مهندسی سیستم دو محور را می بایست مدّ نظر داشت:

1. مهندسی اطلاعات

2. مهندسی محصول

منظور از مهندسی اطلاعات ، شناخت و بررسی ارتباطات بین داده هایی است که در یک حوزه ی تجاری وجود دارد.

منظور از مهندسی محصول ، آشنایی با ویژگی ها و نیازمندیهای محصولی است که می بایست تولید شود.


در مهندسی سیستم یا مرحله تجزیه تحلیل:system engineering دو راهکار یا الگو وجود دارد. الگوی بالا به پایین (Top Down) و الگوی پایین به بالا (Bottom Up). در بعضی از حالتها می توان از این دو روش به صورت همزمان استفاده کرد.

مدلسازی داده ها: Data Modeling

منظور از مدلسازی داده ها شناخت داده های اصلی در یک سیستم و اجزای سازنده ی آن و ارتباطت بین آنها می باشد. برای نمایش مدل داده ها غالباً از نموداری به نام نمودار ER (Entity Relationship) استفاده میشود.( ارتباط بین موجودیتها)

در این نمودار موجودیتها با box یا مستطیل نمایش داده می شود.


هر موجودیت می تواند دارای ویژگیهایی باشد که آن ویژگیها را در داخل یک بیضی نوشته و با یک خط به آن موجودیت متصل می کنیم. ویژگی یکتا و یا به عبارت دیگر کلید اصلی موجودیت را با یک خط مشخص می کنیم.

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

ارتباط بین موجودیتها می تواند دارای کمیت cardinality یک به یک ، یک به چند و چند به چند به چند باشد.


Modality ویژگیهایی باشد که آن ویژگیها را در داخل یک بیضی نوشته و با یک خط به آن موجودیت متصل می کنیم. ویژگی یکتا و یا به عبارت دیگر کلید اصلی موجودیت را با یک خط مشخص می کنیم. (اختیاری بودن):

منظور از Modality این است که آیا ارتباط به صورت همیشگی وجود دارد و یا در بعضی از شرایط می تواند ارتباط بین دو موجودیت وجود داشته باشد.

اگر ارتباط همیشگی باشد Modalityاز هر دو طرف 1 است ولی اگر همیشه نباشد از یک طرف 1 و از طرف دیگر صفر است. (مثل داشتن اشتراک در آژانس.)


دیکشنری داده ها ( ویژگیهایی باشد که آن ویژگیها را در داخل یک بیضی نوشته و با یک خط به آن موجودیت متصل می کنیم. ویژگی یکتا و یا به عبارت دیگر کلید اصلی موجودیت را با یک خط مشخص می کنیم.Data Dictionary):

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


فصل 6 ویژگیهایی باشد که آن ویژگیها را در داخل یک بیضی نوشته و با یک خط به آن موجودیت متصل می کنیم. ویژگی یکتا و یا به عبارت دیگر کلید اصلی موجودیت را با یک خط مشخص می کنیم.


Designing the System ویژگیهایی باشد که آن ویژگیها را در داخل یک بیضی نوشته و با یک خط به آن موجودیت متصل می کنیم. ویژگی یکتا و یا به عبارت دیگر کلید اصلی موجودیت را با یک خط مشخص می کنیم.

طراحی سیستم:

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

اگر بخواهیم تعریف مناسبی برای طراحی سیستم ارائه دهیم، طراحی عبارت است از استفاده از تکنیکها و اصول مختلف برای ساخت یک محصول.


مراحل طراحی سیستم: ویژگیهایی باشد که آن ویژگیها را در داخل یک بیضی نوشته و با یک خط به آن موجودیت متصل می کنیم. ویژگی یکتا و یا به عبارت دیگر کلید اصلی موجودیت را با یک خط مشخص می کنیم.Steps in the Design Process

1. طراحی معماری سیستم

2. طراحی واسط های سیستم

3. طراحی جزئی یا تفصیلی سیستم

در طراحی معماری سیستم ، که اولین مرحله از طراحی می باشد، می بایست عناصر سازنده ی یک سیستم و نحوه ی ارتباط و اتصال آنها مشخص شود.

در روش طراحی ساخت یافته این مرحله شامل شناخت ماژول ها و ارتباط بین آنها و در طراحی شیءگرا شامل شناخت کلاسها و ارتباط بین آنهاست.


در طراحی واسط ها ، ارتباط سیستم با عوامل بیرونی یعنی با کاربران و یا با سایر سیستم های نرم افزاری و سخت افزاری را مشخص می کنیم. پس طراحی UI یا واسط کاربر نیز جزئی از طراحی واسط هاست و در مرحله ی آخر مرحله ی جزئی و تفصیلی ساختار هر یک از قطعات سازنده ی سیستم (در مورد ساخت یافته، ماژول ها و در مورد شیءگرا کلاسها می باشد.) ساختار هر یک از اجزای سیستم به صورت تفصیلی مشخص می شود.

نکات کلیدی و مهم در طراحی سیستم : Key Issues in the Design Process

1. طراحی سیستم ، معمولاً یک روال تکراری است و غالباً در یک مرحله به صورت کامل انجام نمی شود.

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


برخی از این معیارها عبارتند از : با عوامل بیرونی یعنی با کاربران و یا با سایر سیستم های نرم افزاری و سخت افزاری را مشخص می کنیم. پس طراحی Design Principles

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

2. انجام طراحی به صورتی که قابل پیگیری از روی مدل نیازمندیها باشد.

3. عدم اختراع مجدد چرخ . یعنی حتی الامکان از نرم افزارها یا component های آماده استفاده کنیم.

4.استفاده از یک الگویواحد ( uniform) برای طراحی

5. حدالامکان استفاده از مدلهای قابل فهم در طراحی

6. پیاده سازی طراحی به صورتی که از مشکلات ناگهانی حتی الامکان اجتناب شود.


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

1. تجرّد یا abstraction

Abstraction را می توان در دو بعد داده ها و برنامه ها مدّ نظر داشت.

2. پنهان سازی داده ها information hiding

پنهان سازی داده ها یک اصل است و مطابق آن، طراحی مناسب ، طراحی ای است که هر برنامه در آن فقط به داده های مورد نیاز خود دسترسی دارد.

3. Modularity ماژولاریتی (پیماه ای بودن)

منظور از ماژولاریتی این است که وظایف یک سیستم و امکانات آن به چه صورت به ماژولها تخصیص یابد. در این ارتباط دو مقوله ی مهم couplying و cohesion وجود دارد که در ادامه به آن می پردازیم.

4. ساختار سلسله مراتب کنترلی control hierarchy


Coupling با عوامل بیرونی یعنی با کاربران و یا با سایر سیستم های نرم افزاری و سخت افزاری را مشخص می کنیم. پس طراحی ارتباط بین ماژول های یک سیستم

coupling و cohesion دو معیار اصلی در طراحی سیستم می باشد.

منظور از coupling، حجم ارتباط بین ماژولها دریک سیستم است و در طراحی مناسب بهتر است، coupling کمتر باشد.

انواع coupling(از بهترین به بدترین):

1. Data couplingاتصال بر مبنای داده (بهترین نوع)

در Data coupling، اتصال بین دو ماژول با انواع داده ای پایه ای انجام می شود.

2. Stamp couplingدر این نوع coupling، یک ساختار داده ای مرکب نظیر آرایه یا link list از ماژول فراخواننده به ماژول ارسال می شود.(یعنی مثلاً a ، b را فراخوانی می کند تا یک کلمه را برایش ارسال کند.)


3. با عوامل بیرونی یعنی با کاربران و یا با سایر سیستم های نرم افزاری و سخت افزاری را مشخص می کنیم. پس طراحی Control coupling :

در این حالت پارامتر ردّ و بدل شده بین دو ماژول، یک پارامتر کنترلی است.

منظور از داده ی کنترلی، داده ای است که در عباراتی نظیر if، switch یا حلقه ی while از آن استفاده می شود.

4. Common coupling (کاپلینگ مشترک):

در این حالت از داده های public یا عمومی در نرم افزار استفاده می شود. یا به عبارت دیگر داده های مشترکی که ماژول های مختلفی می توانند از آن استفاده کنند.

(استفاده از داده های public یک الگوی اشتباه است. چون ناخواسته ممکن است جایی آن متغیر تغییر کند و در کد مشکل اساسی ایجاد نماید.

5. Cohesion چسبندگی:

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


انواع با عوامل بیرونی یعنی با کاربران و یا با سایر سیستم های نرم افزاری و سخت افزاری را مشخص می کنیم. پس طراحی cohesion عبارتند از : Types of Cohesion

1. Coincidental cohesion چسبندگی تصادفی:

در اینجا ماژول کارهای مختلفی را انجام می دهد که هیچ ارتباطی با هم ندارند.

2. Logical cohesion چسبندگی منطقی:

در این حالت ماژول کارهای مختلفی را انجام می دهد که از لحاظ منطقی با یکدیگر مرتبطند. (مثلاً ماژول ما انتخاب واحد دانشجو را ثبت می کند و سوابق تحصیلی دانشجو را لیست می کند.) (ثبت ورود و خروج و محاسبه ی اضافه کاری)

3. Temporal cohesion چسبندگی موقت:

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


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

در این حالت ، ماژول کارهای مختلفی را انجام می دهد که در حین آن کارها از داده هایی استفاده می کند که بعضاً مشترک هستند.

5. Sequential چسبندگی ترتیبی

ماژول کارهای مختلفی را انجام می دهد که همه ی آنها باید به صورت سریال یا پشت سر هم انجام شود.

6. Informational

در این حالت، ماژول کارهای مختلفی را انجام می دهد که وجه ارتباط آنها در این است که همه بر روی ساختارهای داده ای مشترک انجام می شود.

7. Functional چسبندگی تابعی

بهترین حالت می باشد و در اینجا ماژول فقط یک کار واحد انجام می دهد.

رساندن coupling و cohesion هر دو به حالت ایده آل ممکن نیست.


طراحی تفصیلی سیستم: با عوامل بیرونی یعنی با کاربران و یا با سایر سیستم های نرم افزاری و سخت افزاری را مشخص می کنیم. پس طراحی

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

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


فصل 7 با عوامل بیرونی یعنی با کاربران و یا با سایر سیستم های نرم افزاری و سخت افزاری را مشخص می کنیم. پس طراحی


مدیریت پیکربندی نرم افزار با عوامل بیرونی یعنی با کاربران و یا با سایر سیستم های نرم افزاری و سخت افزاری را مشخص می کنیم. پس طراحی Software Configuration :

منظور از مدیریت پیکر بندی نرم افزار ، مدیریت کلیه ی اجزای یک نرم افزار شامل برنامه ها ، مستندات و داده ها از زمان ساخت می باشد.

تعریف IEEE از مدیریت پیکربندی نرم افزار عبارت است از : روال شناسایی و تعریف کلیه ی itemهای سیستم (شامل متن برنامه، مستندات و داده ها.)

کنترل تغییرات این آیتم ها در چرخه ی زندگیشان ثبت و ذخیره ی کلیه ی آیتم ها و کنترل صحت تغییرات انجام شده می باشد.

قسمتهای مختلف نرم افزار که می بایست در مدیریت پیکربندی مدّ نظر قرار گیرند عبارتند از:

1. مشخصات گزارشات سیستم

2. برنامه ریطی انجام پروژه

3. گزارش تحلیل نیازمندیها

4. گزارش راهنمای کاربران


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

6. متن برنامه های سیستم

7. گزارش ویژگیهای تست

8. گزارش نصب و راه اندازی سیستم

9. برنامه های اجرایی

10. شرح پایگاه داده

11. راهنمای کاربران

12. گزارشات نگهداری

13. استانداردها و روال های مهندسی نرم افزار

و ...


The SCM process با عوامل بیرونی یعنی با کاربران و یا با سایر سیستم های نرم افزاری و سخت افزاری را مشخص می کنیم. پس طراحی :

1. شناسایی اشیاء یا itemها ی موجود در سیستم

2. مشخص کردن قوانین نسخه بندی

3. کنترل اعمال تغییرات

4. کنترل اعمال تغییرات انجام شده از لحاظ کیفیت

5. گزارش گیری


Change control
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

Check CI out of project database

Generate ECO for each approved change

Use appropriate version control mechanisms to create next version of the software

Change the CI as required

Perform necessary SQA activities

Check CI into project database


کنترل تغییرات با عوامل بیرونی یعنی با کاربران و یا با سایر سیستم های نرم افزاری و سخت افزاری را مشخص می کنیم. پس طراحی

پذیرش درخواست تغییر

ارزیابی درخواست تغییر در پارامترهای موجود

ارائه ی گزارش تغییر

بررسی آیتم جهت تغییر خارج از انباره ی پروژه

استفاده از گزارش تغییر برای اخذ تصمیم نهایی بر روی وضعیت و اولویت تغییر

خارج کردن آیتم مورد نظر از انباره ی پروژه برای انجام تغییرات تأیید شده

انجام تغییرات مورد نیاز بر روی آیتم مورد نظر

انجام عملیات کنترل کیفیت لازم

بازگردان آیتم تغییر یافته به انباره ی پروژه

اختصاص نسخه یا ورژن جدید برای آیتم تغییر یافته


1. دریافت و درخواست تغییر با عوامل بیرونی یعنی با کاربران و یا با سایر سیستم های نرم افزاری و سخت افزاری را مشخص می کنیم. پس طراحی

2. بررسی گزارش تغییر از لحاظ پارامترهایی نظیر مسائل فنی و هزینه و زمان آن

3. ساخت گزارش تغییر توسط شخص یا تیم مربوطه

4. تعیین انجام یا عدم انجام تغییر و اولویت آن توسط مدیریت

5. خارج کردن آیتم مورد نظر برای تغییر از انباره ی پروژه (الکترونیکی (hard) یا فیزیکی(گزارش))

6. اعمال تغییرات روی آیتم مورد نظر

7. انجام عملیات کنترل کیفیت لازم

8. بازگرداندن آیتم به انباره ی پروژه

9. اختصاص نسخه یا ورژن (version) جدید برای آیتم تغییر یافته.


انباره ی با عوامل بیرونی یعنی با کاربران و یا با سایر سیستم های نرم افزاری و سخت افزاری را مشخص می کنیم. پس طراحی SCM (انباره ی مدیریت پیکربندی)

منظور از انباره ی SCM محل فیزیکی و الکترونیکی است که در آن کلیه ی اطلاعات پروژه نگهداری می شود. بدیهی است این محل می بایست مقیاس پذیر ، قابل اطمینان ، در دسترس و شفاف باشد.

ابزارهای SCM :

برای مدیریت SCMابزارهای نرم افزاری متفاوتی وجود دارد که می تواند کار SCMرا تسهیل نماید. دو تا از مهمترین این ابزارها عبارتند از :

1. Configuration Management Assistant

2. Adele


فصل 8 با عوامل بیرونی یعنی با کاربران و یا با سایر سیستم های نرم افزاری و سخت افزاری را مشخص می کنیم. پس طراحی


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

فاز نگهداری آخرین مرحله چرخش زندگی هر نرم افزار می باشد و پس از نصب و راه اندازی نرم افزار ، آغاز و تا انتهای استفاده از نرم افزار ادامه می یابد.

Maintenance:

فعالیتهایی است شامل ارتقاء (بالا بردن سرویسهای آن)، تطابق یا adapting و اصلاح یا correcting می باشد.(برطرف کردن مشکلات)

انواع مشکلاتی که در maintenance یا فاز نگهداری هستند به 3 دسته تقسیم می شوند:

1. Emergency fix (اصلاحات اضطراری)

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


2. با عوامل بیرونی یعنی با کاربران و یا با سایر سیستم های نرم افزاری و سخت افزاری را مشخص می کنیم. پس طراحی Urgent fix (اصلاحات ضروری)

این دسته از مشکلات نیز حتماً می بایست در سیستم برطرف شود اما سرعت برطرف کردن آنها می تواند دیرتر از اصلاحات ضروری باشد.

3. Nice to have fix (اصلاحات ارجح یا مناسب)

این گونه اصلاحات یا تغییرات بهتر است در سیستم انجام شود. اما اولویت زمانی برای انجام آنها بالا نمی باشد.

مشکلات مرحله ی نگهداری :

1. وجود پرسنل دینامیک Dynamic personnel :

که هزینه ی آموزش زیادی را می تواند به سیستم تحمیل کند.

2. Motivation and morale

3. Lack of documentation


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 در یک مقطع زمانی تولید می شود.


نکات کلیدی در مرحله ی نگهداری با عوامل بیرونی یعنی با کاربران و یا با سایر سیستم های نرم افزاری و سخت افزاری را مشخص می کنیم. پس طراحی Key Factors affecting Maintenance

1. متوسط زمانی که یک شخص در طی آن می تواند با سیستم آشنا شود.

2. وجود یا عدم وجود مستندات مناسب

3. در نظر گرفتن این نکته که هر فعالیت موجود در maintenance باعث کاهش عمر مفید نرم افزار می شود.


فصل 9 با عوامل بیرونی یعنی با کاربران و یا با سایر سیستم های نرم افزاری و سخت افزاری را مشخص می کنیم. پس طراحی


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

منظور از پیاده سازی ، انتقال نرم افزار پس از تکمیل آن به سایت اصلی و راه اندازی آن است.

فعالیتهایی که در حین راه اندازی هستند:

1. آماده کردن برنامه نصب

2. انجام روال های عملیاتی لازم

3. آماده سازی و تبدیل داده ها

4. آموزش کاربران

5. راه اندازی سیستم


1. آماده کردن برنامه نصب : با عوامل بیرونی یعنی با کاربران و یا با سایر سیستم های نرم افزاری و سخت افزاری را مشخص می کنیم. پس طراحی

در این مرحله عملیات عبارتند از :

1. خرید سخت افزار

2. آماده سازی سایت

3. خرید نرم افزارهای جانبی (نرم افزارهایی که در زمان اجرا لازم هستند.)

4. نصب نرم افزار تولید شده

5. آموزش کاربران

2. انجام روالهای عملیاتی لازم:

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

2. آموزش و آشنایی کاربران با سیستم جدید باید به صورت مرحله بندی شده انجام شود.


3. مراحل تبدیل داده ها: با عوامل بیرونی یعنی با کاربران و یا با سایر سیستم های نرم افزاری و سخت افزاری را مشخص می کنیم. پس طراحی

1. لیست کردن کلیه ی فایلهایی که می بایست تبدیل شوند.

2. لیست کردن فایل های جدیدی که می بایست آماده شوند و تهیه ی داده های مورد نیاز آنها.

3. لیست کردن کلیه ی مستندات برنامه هایی که در حین تبدیل داده مورد نیاز است.

4. مشخص کردن کنترلهایی که در روند انتقال داده ها می بایست اعمال شوند.(کنترل جامعیت)

5. آماده کردن برنامه ی انتقال داده.

6. مشخص کردن کارهایی که باید در حین انتقال داده انجام شود.


4. آموزش کاربران با عوامل بیرونی یعنی با کاربران و یا با سایر سیستم های نرم افزاری و سخت افزاری را مشخص می کنیم. پس طراحی User Training:

آموزش کاربران در دو سطح انجام می شود:

1. آموزش اپراتورهای سیستم

2. آموزش مدیران راهبری سیستم

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


5. استراتژیهای راه اندازی سیستم با عوامل بیرونی یعنی با کاربران و یا با سایر سیستم های نرم افزاری و سخت افزاری را مشخص می کنیم. پس طراحی Implementation Strategies :

چهار استراتژی برای راه اندازی سیستم وجود دارد که عبارتند از :

1. استراتژی موازی

2. استراتژی قطع

3. استراتژی فازبندی یا مرحله بندی

4. استراتژی آزمایشی

در استراتژی موازی، سیستم جدید و سیستم قدیم به صورت موازی با هم اجرا می شوند. هدف از این استراتژی بالا بردن قابلیت اطمینان سیستم و مشخص کردن خطاهایی است که تا لحظه نصب در سیستم برطرف نشده اند.


Implementation strategies contd
Implementation Strategies با عوامل بیرونی یعنی با کاربران و یا با سایر سیستم های نرم افزاری و سخت افزاری را مشخص می کنیم. پس طراحی Contd…


اما این استراتژی نیاز به نیروی کار و هزینه ی زیادی دارد. این استراتژی مناسب سیستم هایی هستند که اهمیت بالایی دارند مثل سیستم های مالی.

2. در استراتژی قطع یا direct cutover approach در هنگام راه اندازی ، اجرای سیستم قدیمی ، قطع و سیستم جدید جایگزین آن می شود.

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

4. استراتژی آزمایشی (Pilot) : برای کاربران خاصی (متخصص) مورد بررسی قرار می گیرد.


معیارهای انتخاب استراتژی راه اندازی :

1. ماهیت و سایز سیستم: (هر چه سیستم بزرگتر و پیچیده تر باشد، به سمت استراتژیهای موازی و آزمایشی پیش می رویم.)

2. نوع سازمان مشتری : (ساختار سازمانی)

3. وجود واحد انفورماتیک یا کامپیوتر در داخل سازمان مشتری

4. تعداد کاربرانی که با سیستم ارتباط برقرار می کنند.

5. حجم داده های سیستم.

6. پراکندگی جغرافیایی سیستم (داخل سازمانی یا بیرون سازمانی)

(استراتژی مناسب: آزمایشی و فازبندی شده)

7. استفاده از ابزارها یا tools مناسب (استراتژی مناسب: استراتژی قطع)

8. در دسترس بودن نیروی انسانی : (بدون داشتن نیروی انسانی استراتژی موازی قابل اجرا نیست.)

9. درجه ی اهمیت و بحرانی بودن نرم افزار : (نرم افزارهایی که اهمیت و پیچیدگی انجام کار بالایی دارند، مثل نرم افزارهای مالی ، در آنها سراغ استراتژی قطع نمی رویم.)


مرور نرم افزار پس از نصب: اندازی :

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

برخی از سوالاتی که در این ارتباط مطرح می شوند، عبارتند از:

1. آیا سیستم جدید، هزینه ی اجرایی و عملیاتی ما را کاهش و یا افزایش داده است؟

2. آیا سیستم جدید ، اطلاعات دقیق و به روزی را به ارائه می دهد؟

3. آیا کار کردن با سیستم جدید برای کاربران از سیستم قدیمی راحتتر است؟


4. آیا برای راهبری سیستم جدید، به اپراتورهای کمتر یا بیشتری نسبت به سیستم قدیم احتیاج است؟

5. آیا سیستم جدید روالهای اجرایی و عملیاتی سازمان را بهبود بخشیده است؟

6. آیا سیستم جدید ، ضریب تولید را افزایش داده است؟

7. آیا سیستم جدید، سرویس دهی به مشتریان را بهبود بخشیده است؟

برنامه ریزی حالتهای بحرانی

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


فصل 10 اپراتورهای کمتر یا بیشتری نسبت به سیستم قدیم احتیاج است؟


تحلیل و طراحی نرم افزار به روش شیءگرایی:

همانطور که ذکر شد، دو روش عمده برای تولید نرم افزار وجود دارد که عبارتند از :

روش ساخت یافته یا Structuredو روش شیءگرا یا Object Oriented

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


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


ویژگیهای پروژه های شیءگرایی: تحلیل گر بر روی رفتارهایی است که یا در حال حاضر در سیستم انجام می شود (مدل تجاری

1. مشخص کردن یک روال تولید چرخشی (iterative)

2. تخمین زدن زمان و هزینه ی انجام پروژه با استفاده از روال تولید انتخاب شده.

3. مشخص کردن نقاط سنجش (milestones) و نحوه ی اندازه گیری پیشرفت انجام پروژه .

4. مشخص کردن نقاط مهم برای کنترل کیفی نرم افزار (در مراحل تولید)

5. مدیریت تغییرات

6. مشاهده ،پیگیری و کنترل پیشرفت انجام پروژه


Object Oriented Metrics تحلیل گر بر روی رفتارهایی است که یا در حال حاضر در سیستم انجام می شود (مدل تجاری

برخی از استانداردهای مورد استفاده در پروژه های object oriented عبارتند از :

1. تعداد متدها در یک کلاس ( اگر تعداد متدهای کلاسی از حدی بیشتر شد، باید آن را به کلاسهای کوچکتر تفکیک کرد.)

2. عمق درخت و وراثت.

3. تعداد اشیاء نمونه گرفته شده از یک کلاس

4. بررسی coupling بین کلاسها

5. واکنش ها یا پاسخ هایی که به یک کلاس داده می شود.

6. کمبود چسبندگی یا cohesion در محیط های یک کلاس.


تخمین زدن یک پروژه ی شیءگرا تحلیل گر بر روی رفتارهایی است که یا در حال حاضر در سیستم انجام می شود (مدل تجاری Estimating an O.O project:

برای تخمین زدن پروژ] های شیءگرا ، می توان از معیارها یا موازین زیر استفاده کرد:

1. تعدا usecaseها و سناریوهای آنها (هر چه تعداد آنها بیشتر باشد ، حجم کد بیشتری مورد نیاز است.)

2. تعداد کلاسهای اصلی

3. مشخص کردن واسط ها یا interface ها و کلاسهای لازم برای پیاده سازی آنها. (هر واسطی که سیستم را به محیط بیرونی مرتبط می کند.)

4. محاسبه و بازبینی تخمین ها بر مبنای کلاسها

برنامه ریزی پروژه های شیءگرا:

1. پروژه های شیءگرا با پروسس های چرخشی پیاده سازی می شوند.

2. در برنامه ریزی برای این پروژه ها می بایست :

1-2. تعدا چرخش های مورد نیاز را تخمین زد.

2-2. مشخص کرد که در انتهای هر چرخه ، چه حجم یا درصدی از کارها انجام شده است.


ad