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

‫تجزیه و تحلیل و مدلسازی سیستم‬
‫استاد ‪ :‬مهسا رضایی‬
‫فصل ‪1‬‬
‫مهندس ی نرم افزار ‪:‬‬
‫ایجاد روندی سیستماتیک ‪ ،‬منظم و قابل اندازه گیری برای تولید و نگهداری نرم افزار را وظیفه‬
‫ی علم مهندس ی نرم افزار می دانیم‪.‬‬
‫مهندس ي نرم افزار‪ ،‬شاخه اي است از مهندس ي‪ ،‬كه با بهره گیري از دانش علمي‪ ،‬به ارائه ي راه‬
‫حل هايي مقرون به صرفه‪ ،‬در قالب دستاوردهاي نرم افزاري و به منظور حل مسائل و‬
‫مشكالت عملي و خدمت به جامعه ي بشري‪ ،‬اقدام مي نمايد‪.‬‬
‫سه معیار مهم ‪:‬‬
‫‪ .1‬زمان‬
‫‪ .2‬هزینه‬
‫‪ .3‬کیفیت نرم افزاری که می خواهیم تولید کنیم‪.‬‬
‫تعریف نرم افزار ‪:‬‬
‫مجموعه ای از برنامه های کامپیوتری ‪ ،‬روال ها ‪ ،‬قوانین ‪ ،‬مستندات و داده ها را نرم افزار می‬
‫گوییم‪.‬‬
‫مسائل و مشکالت نرم افزار در دنیای کنونی‪:‬‬
‫‪ .1‬قابلیت اطمینان نرم افزار ‪ :‬بدان معنا که نرم افزار به درستی اجرا شود‪.‬‬
‫‪ .2‬هزینه ی نرم افزار ‪ :‬هدف‪ :‬کاهش هزینه ی خرید نرم افزار با حفظ کیفیت ‪.‬‬
‫‪ .3‬اعمال تغییرات و دوباره کاری‬
‫انواع نرم افزار ‪:‬‬
‫‪ .1‬چکشخوار ( قابل اعمال تغییرات )‬
‫‪ .2‬غیر چکشخوار ( غیرقابل تغییر )‬
‫هدف مهندس ی نرم افزار ‪:‬‬
‫تولید سیستم به گونه ای که دوباره کاری و تغییر حداقل شود‪.‬‬
‫در نظر گرفتن تولید نرم افزار به صورت یک روند‪:‬‬
‫تولید نرم افزار از مجموعه ای از فعالیتها ساخته می شود‪.‬‬
‫در تولید یک نرم افزار دارای محدودیتهایی هستیم ‪ .1 :‬زمان ‪ .2‬هزینه ‪ .3‬محدودیتهای تکنیکی‬
‫در تولید نرم افزار هدف ساخت یک نرم افزار با کیفیت باال و هزینه کم می باشد‪.‬‬
‫تولید نرم افزار یک روال و یا روندی است که از مجموعه ای از کارها تشکیل شده است‪.‬‬
‫ویژگی های روال های تولید نرم افزار ‪:‬‬
‫‪ .1‬قابل پیش بینی بودن ‪ .1 :‬کیفیت ‪ .2‬هزینه ‪ .3‬زمان ‪ .4‬پیش بینی ارتباط بین فعالیتها‬
‫(اولویت در ترتیب انجام مراحل)‬
‫‪ .2‬هر روال یا روند تولید باید قابل تست باشد ‪.‬‬
‫‪ .3‬امکان روال های تولید جهت حذف سریع خطاها و جلوگیری از به وجود آمدن خطاها‬
‫‪ .4‬اصالح روال تولید‬
‫ویژگی های یک نرم افزا ر به صورت یک محصول‪Software as a product :‬‬
‫‪ .1‬نرم افزار یک محصول مهندس ی است و با اصول مهندس ی باید تولید شود‪.‬‬
‫‪ .2‬نرم افزار یک محصول قابل تغییر یا چکشخوار است‪.‬‬
‫‪ .3‬نرم افزار به دلیل اینکه محصولی فیزیکی نیست ‪ ،‬خراب یا مستهلک نمی شود‪ .‬اما در عمل به‬
‫دلیل اعمال تغییرات مداوم شاید دیگر قابل استفاده نبوده و می بایست نرم افزار دیگری جای آن‬
‫را بگیرد‪.‬‬
‫ً‬
‫‪ .4‬نرم افزار برخالف بسیاری از محصوالت مهندس ی دیگر ‪ ،‬قالبا به صورت سفارش ی ساخته می‬
‫شود و از اجزای آماده در آن کمتر استفاده می شود که یکی از اهداف مهندس ی نرم افزار ‪ ،‬افزایش‬
‫استفاده از قطعات نرم افزاری آماده است‪.‬‬
‫دالیل استفاده از مهندس ی نرم افزار در پروژه های مهندس‬
‫ی ‪Why Software Engineering? :‬‬
‫مهندس ی نرم افزار نقش اساس ی در باال بردن کیفیت نرم افزار و کاهش هزینه ها دارد‪.‬‬
‫نقش مهندس ی نرم افزار در پروژه های مهندس ی ‪:‬‬
‫‪The influencing role of Software Engineering‬‬
‫‪ .1‬کاهش وابستگی به افراد متخصص به صورت خاص‬
‫‪ .2‬باالبردن کیفیت ارتباطات تیمی‬
‫‪ .3‬تخمین مناسب شامل تخمین زمان و هزینه‬
‫‪ .4‬مدیریت تغییرات‬
‫‪ .5‬کنترل زمان انجام پروژه ها‬
‫‪ .6‬برقراری ارتباط و درک متقابل از نرم افزار بین تولید کنندگان‪ ،‬کاربران و مدیران‬
‫‪ .7‬انجام و ارائه ی آموزش های مناسب‬
‫‪ .8‬انجام پیش بینی های الزم جهت مواجهه با افزایش توقع کاربران‬
‫اهداف مهندس ی نرم افزار ‪Software Engineering Goals :‬‬
‫‪ .1‬باال بردن کیفیت ‪ -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‬برنامه ای را می‬
‫نویسیم‪ ).‬باید مشخص شود چه ماژول ها یا فانکشن هایی دارد و فانکشن ها چگونه در کنار هم‬
‫قرار می گیرند‪.‬‬
‫‪ ( Implementation .4‬پیاده سازی یا همان کد نویس ی )‬
‫‪ : Testing .5‬تست کد نوشته شده ‪ unit -1 :‬یا واحد‪ :‬تست کوچکترین عناصر برنامه ‪ ،‬تست‬
‫ماژول ها یا ‪ function‬ها‬
‫‪ : system -2‬قسمتهای مختلف سیستم را به هم متصل کرده و تست‬
‫می کنیم ‪ .‬به این نوع تست ‪ ،‬تست آلفا گفته می شود‪ .‬تستی که در گروه تولید کننده ی نرم افزار‬
‫به مجتمع برای کل برنامه انجام میشود‪.‬‬
‫‪ : acceptance -3‬تست تجاری یا تست بتا‪ .‬تست قابل قبول بودن پس‬
‫از تست شرکت یا ‪ system‬به برخی از مشتریان حرفه ای برای تست داده می شود‪.‬‬
‫‪ Conversion .6‬یا انتقال ‪ :‬تحویل به مشتری و بردن محصول به محیط کاری واقعی و راه‬
‫اندازی آن در محیط واقعی‬
‫روشهای ‪ -1 : conversion‬استراتژی موازی ‪ : 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‬‬
‫‪prototyping -1.2‬‬
‫‪ .2‬روال های تولید آزمایش ی یا تکراری ‪:‬‬
‫‪ -2.1‬روال افزایش ی‬
‫‪ -2.2‬روال مارپیچی‬
‫‪ -2.3‬روال معرفی گرا‬
‫روال های تولید یک نرم افزار سبک ‪:‬‬
‫روال هایی که در حین تولید مستندات زیادی تولید نمی کنند مثل ‪. XP‬‬
‫روال های تولید یک نرم افزار سنگین ‪:‬‬
‫روال هایی که در حین تولیدشان حجم زیادی از مستندات تولید می شود ‪.‬‬
‫در روال های تولید نرم افزار به صورت خطی دو روال نقش عمده دارند‪:‬‬
‫‪ .1‬روال خطی (‪ .1.1 : )Sequential‬مدل آبشاری ‪waterfall‬‬
‫‪ .1.2‬مدل اجرایی‬
‫‪prototype‬‬
‫‪ .2‬آزمایش ی یا چرخش ی ‪ : Iterative‬فرایند تولید یک سویه یا خطی‬
‫نیست بلکه یک فرایند چرخش ی است‪.‬‬
‫اولین روال تولید (روال آبشاری)‪:‬‬
‫‪ .1‬شناخت وضع موجود و نیازمندیها‬
‫‪ .2‬طراحی‬
‫‪ .3‬مرحله ی برنامه سازی‬
‫اشکاالت روال آبشاری‪:‬‬
‫‪ .1‬در صورت وجود ایراد‪ ،‬قادر به بازگشت و اصالح نیستیم‪.‬‬
‫‪ .2‬اگر نیازمندیها در محیط تغییر بکنند‪ ،‬قادر به تغییر و اصالح تغییرات نیستیم‪.‬‬
‫تحلیل شده‪ ،‬به فاز طراحی رفته ‪ ،‬ولی نیازمندیها عوض شده یا بیشتر شده‬
‫اند‪.‬‬
‫‪ .3‬کاربر تا انتهای کار‪ ،‬نسخه ای اجرایی نمی بینید‪ .‬کاربر برای دیدن یک کد باید تا‬
‫انتهای کار منتظر بماند چون تا برنامه تست نشود‪ ،‬تحویل کاربر نمی شود‪.‬‬
‫‪ ، Prototype‬اصالح شده ی ‪ waterfall‬است‪.‬‬
‫در ‪ prototype‬وسط کار‪ ،‬نسخه ای اجرایی برای تست تحویل کاربر می‬
‫شود و طبق نیازهای کاربر‪ ،‬بقیه ی کار انجام می شود‪.‬‬
‫روال چرخش ی یا ‪: iterative‬‬
‫‪ .1‬افزایش ی ‪ : incremental‬روش خوبی است‪ .‬مناسب پروژه های سبک‬
‫است‪.‬‬
‫‪ .2‬مارپیچی ‪: spiral‬‬
‫روال سنگین‬
‫‪ .3‬مؤلفه گرا ‪component base‬‬
‫‪RUP .4‬‬
‫روال سنگین‬
‫‪XP .5‬‬
‫روال سبک‬
‫مزایای روش های تولید چرخش ی‪:‬‬
‫‪ .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‬یا ‪)RFP( Request For Proposal‬‬
‫آماده می کند که در آن مسائل و نیازمندیهای خود را شرح داده‬
‫ً‬
‫است‪ .‬در ‪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‬و یا مدلهای ‪ activity diagram ، usecase‬و ‪...‬‬
‫در مدل ‪) 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‬‬
‫منظور از مدلسازی داده ها شناخت داده های اصلی در یک سیستم و اجزای‬
‫ً‬
‫سازنده ی آن و ارتباطت بین آنها می باشد‪ .‬برای نمایش مدل داده ها غالبا از‬
‫نموداری به نام نمودار ‪ )Entity Relationship( ER‬استفاده‬
‫میشود‪ (.‬ارتباط بین موجودیتها)‬
‫در این نمودار موجودیتها با ‪ box‬یا مستطیل نمایش داده می شود‪.‬‬
‫هر موجودیت می تواند دارای ویژگیهایی باشد که آن ویژگیها را در داخل یک‬
‫بیض ی نوشته و با یک خط به آن موجودیت متصل می کنیم‪ .‬ویژگی یکتا و یا به‬
‫عبارت دیگر کلید اصلی موجودیت را با یک خط مشخص می کنیم‪.‬‬
‫پس از شناخت کلیه ی موجودیتها‪ ،‬ارتباط بین موجودیتها را تشخیص می دهیم‬
‫و هر دو موجودیتی که با یکدیگر ارتباط دارند را با یک خط به یکدیگر متصل‬
‫می کنیم‪ .‬می توان توضیحاتی نیز برای ارتباط در کنار خط یادداشت کرد‪.‬‬
‫ارتباط بین موجودیتها می تواند دارای کمیت ‪ cardinality‬یک به یک ‪،‬‬
‫یک به چند و چند به چند به چند باشد‪.‬‬
‫‪( Modality‬اختیاری بودن)‪:‬‬
‫منظور از ‪ Modality‬این است که آیا ارتباط به صورت همیشگی وجود‬
‫دارد و یا در بعض ی از شرایط می تواند ارتباط بین دو موجودیت وجود داشته‬
‫باشد‪.‬‬
‫اگر ارتباط همیشگی باشد ‪ Modality‬از هر دو طرف ‪ 1‬است ولی اگر‬
‫همیشه نباشد از یک طرف ‪ 1‬و از طرف دیگر صفر است‪( .‬مثل داشتن اشتراک‬
‫در آژانس‪).‬‬
‫دیکشنری داده ها (‪:)Data Dictionary‬‬
‫دیکشنری داده ها یک مستند یا گزارش است که در مرحله ی تحویل سیستم‬
‫ساخته شده و در مراحل بعدی یعنی طراحی و یا برنامه سازی ‪ ،‬می تواند کاملتر‬
‫شود‪ .‬در این مستند اطالعات جامع و کاملی در ارتباط با داده های سیستم (چه‬
‫داده های ماندگار در مقابل پایگاه داده یا فایلهای دیگر و چه داده های مورد‬
‫استفاده در برنامه ها) وجود دارد‪ .‬برخی از اطالعات این مستند می تواند شامل‬
‫نام داده ها ‪ ،‬نام مستعار آنها ‪ ،‬چگونگی استفاده از داده ها و اطالعات تکمیلی‬
‫دیگر باشد‪ .‬عالوه بر آن نمودارها ‪ ER‬و ساختار و اطالعات تفصیلی پایگاه داده‬
‫ها نیز در این مستند قرار می گیرد‪.‬‬
‫فصل ‪6‬‬
‫‪Designing the System‬‬
‫طراحی سیستم‪:‬‬
‫طراحی یک سیستم ‪ ،‬فاز یا مرحله ای است که بین تجزیه تحلیل و برنامه سازی‬
‫قرار دارد‪ .‬در این مرحله ‪ ،‬ما با توجه به شناخت نیازمندیها ‪ ،‬مدل ساخته شده‬
‫را به مدلی تبدیل می کنیم که می توان با کمک آن مدل فاز برنامه سازی را آغاز‬
‫نماییم‪.‬‬
‫اگر بخواهیم تعریف مناسبی برای طراحی سیستم ارائه دهیم‪ ،‬طراحی عبارت‬
‫است از استفاده از تکنیکها و اصول مختلف برای ساخت یک محصول‪.‬‬
‫مراحل طراحی سیستم‪:‬‬
‫‪Steps in the Design Process‬‬
‫‪ .1‬طراحی معماری سیستم‬
‫‪ .2‬طراحی واسط های سیستم‬
‫‪ .3‬طراحی جزئی یا تفصیلی سیستم‬
‫در طراحی معماری سیستم ‪ ،‬که اولین مرحله از طراحی می باشد‪ ،‬می بایست‬
‫عناصر سازنده ی یک سیستم و نحوه ی ارتباط و اتصال آنها مشخص شود‪.‬‬
‫در روش طراحی ساخت یافته این مرحله شامل شناخت ماژول ها و ارتباط بین‬
‫آنها و در طراحی ش یءگرا شامل شناخت کالسها و ارتباط بین آنهاست‪.‬‬
‫در طراحی واسط ها ‪ ،‬ارتباط سیستم با عوامل بیرونی یعنی با کاربران و یا با‬
‫سایر سیستم های نرم افزاری و سخت افزاری را مشخص می کنیم‪ .‬پس طراحی‬
‫‪ UI‬یا واسط کاربر نیز جزئی از طراحی واسط هاست و در مرحله ی آخر مرحله‬
‫ی جزئی و تفصیلی ساختار هر یک از قطعات سازنده ی سیستم (در مورد‬
‫ساخت یافته‪ ،‬ماژول ها و در مورد ش یءگرا کالسها می باشد‪ ).‬ساختار هر یک از‬
‫اجزای سیستم به صورت تفصیلی مشخص می شود‪.‬‬
‫نکات کلیدی و مهم در طراحی سیستم ‪:‬‬
‫ً‬
‫ً‬
‫‪ .1‬طراحی سیستم ‪ ،‬معموال یک روال تکراری است و غالبا در یک مرحله به‬
‫صورت کامل انجام نمی شود‪.‬‬
‫‪Key Issues in the Design Process‬‬
‫‪ .2‬در طراحی می بایست معیارهایی جهت تشخیص طراحی مناسب و نامناسب‬
‫داشته باشیم و بتوانیم با کمک این معیارها ‪ ،‬طراحی اصلی محصول را ارزیابی‬
‫نماییم‪.‬‬
‫برخی از این معیارها عبارتند از ‪:‬‬
‫‪Design Principles‬‬
‫‪ .1‬اجتناب از دید محدود یا بسته‬
‫‪ .2‬انجام طراحی به صورتی که قابل پیگیری از روی مدل نیازمندیها باشد‪.‬‬
‫‪ .3‬عدم اختراع مجدد چرخ ‪ .‬یعنی حتی االمکان از نرم افزارها یا‬
‫‪component‬های آماده استفاده کنیم‪.‬‬
‫‪.4‬استفاده از یک الگوی واحد ( ‪ )uniform‬برای طراحی‬
‫‪ .5‬حداالمکان استفاده از مدلهای قابل فهم در طراحی‬
‫‪ .6‬پیاده سازی طراحی به صورتی که از مشکالت ناگهانی حتی االمکان اجتناب‬
‫شود‪.‬‬
‫مفاهیم مهم در طراحی ‪:‬‬
‫‪ .1‬تجرد یا ‪abstraction‬‬
‫‪ Abstraction‬را می توان در دو بعد داده ها و برنامه ها مد نظر داشت‪.‬‬
‫‪ .2‬پنهان سازی داده ها ‪information hiding‬‬
‫پنهان سازی داده ها یک اصل است و مطابق آن‪ ،‬طراحی مناسب ‪ ،‬طراحی ای است که هر‬
‫برنامه در آن فقط به داده های مورد نیاز خود دسترس ی دارد‪.‬‬
‫‪ Modularity .3‬ماژوالریتی (پیماه ای بودن)‬
‫منظور از ماژوالریتی این است که وظایف یک سیستم و امکانات آن به چه صورت به‬
‫ماژولها تخصیص یابد‪ .‬در این ارتباط دو مقوله ی مهم ‪ couplying‬و ‪cohesion‬‬
‫وجود دارد که در ادامه به آن می پردازیم‪.‬‬
‫‪ .4‬ساختار سلسله مراتب کنترلی ‪control hierarchy‬‬
‫‪ Coupling‬ارتباط بین ماژول های یک سیستم‬
‫‪ coupling‬و ‪ cohesion‬دو معیار اصلی در طراحی سیستم می باشد‪.‬‬
‫منظور از ‪ ، coupling‬حجم ارتباط بین ماژولها دریک سیستم است و در طراحی‬
‫مناسب بهتر است‪ coupling ،‬کمتر باشد‪.‬‬
‫انواع ‪( coupling‬از بهترین به بدترین)‪:‬‬
‫‪ Data coupling .1‬اتصال بر مبنای داده (بهترین نوع)‬
‫در ‪ ، Data coupling‬اتصال بین دو ماژول با انواع داده ای پایه ای انجام‬
‫می شود‪.‬‬
‫‪ Stamp coupling .2‬در این نوع ‪ ، coupling‬یک ساختار داده ای‬
‫مرکب نظیر آرایه یا ‪ link list‬از ماژول فراخواننده به ماژول ارسال می شود‪(.‬یعنی‬
‫ً‬
‫مثال ‪ b ، a‬را فراخوانی می کند تا یک کلمه را برایش ارسال کند‪).‬‬
‫‪: Control coupling .3‬‬
‫در این حالت پارامتر رد و بدل شده بین دو ماژول‪ ،‬یک پارامتر کنترلی است‪.‬‬
‫منظور از داده ی کنترلی‪ ،‬داده ای است که در عباراتی نظیر ‪ switch ، if‬یا حلقه ی‬
‫‪ while‬از آن استفاده می شود‪.‬‬
‫‪( Common coupling .4‬کاپلینگ مشترک)‪:‬‬
‫در این حالت از داده های ‪ public‬یا عمومی در نرم افزار استفاده می شود‪ .‬یا به عبارت‬
‫دیگر داده های مشترکی که ماژول های مختلفی می توانند از آن استفاده کنند‪.‬‬
‫(استفاده از داده های ‪ public‬یک الگوی اشتباه است‪ .‬چون ناخواسته ممکن است‬
‫جایی آن متغیر تغییر کند و در کد مشکل اساس ی ایجاد نماید‪.‬‬
‫‪ Cohesion .5‬چسبندگی‪:‬‬
‫منظور از ‪ Cohesion‬ارتباط محتوایی بین قسمتهای مختلف یک ماژول می باشد و یا به‬
‫عبارت دیگر ‪ ،‬بیان این مطلب که یک ماژول چه کارهای مختلفی را انجام می دهد‪( .‬در حالت‬
‫ایده آل یک ماژول باید فقط یک کار انجام دهد‪).‬‬
‫انواع ‪ cohesion‬عبارتند از ‪:‬‬
‫‪Types of Cohesion‬‬
‫‪ Coincidental cohesion .1‬چسبندگی تصادفی‪:‬‬
‫در اینجا ماژول کارهای مختلفی را انجام می دهد که هیچ ارتباطی با هم ندارند‪.‬‬
‫‪ Logical cohesion .2‬چسبندگی منطقی‪:‬‬
‫در این حالت ماژول کارهای مختلفی را انجام می دهد که از لحاظ منطقی با یکدیگر‬
‫ً‬
‫مرتبطند‪( .‬مثال ماژول ما انتخاب واحد دانشجو را ثبت می کند و سوابق تحصیلی‬
‫دانشجو را لیست می کند‪( ).‬ثبت ورود و خروج و محاسبه ی اضافه کاری)‬
‫‪ Temporal cohesion .3‬چسبندگی موقت‪:‬‬
‫در این حالت ماژول کارهای مختلفی را انجام می دهد که وجه ارتباطی آنها این است‬
‫که همه باید در یک مقطع زمانی انجام شود‪ (.‬انتخاب واحد ‪ ،‬پرداخت پول و تسویه‬
‫حساب)‬
‫‪ Communication cohesion .4‬چسبندگی ارتباطی‪:‬‬
‫در این حالت ‪ ،‬ماژول کارهای ًمختلفی را انجام می دهد که در حین آن کارها از داده‬
‫هایی استفاده می کند که بعضا مشترک هستند‪.‬‬
‫‪ Sequential .5‬چسبندگی ترتیبی‬
‫ماژول کارهای مختلفی را انجام می دهد که همه ی آنها باید به صورت سریال یا پشت‬
‫سر هم انجام شود‪.‬‬
‫‪Informational .6‬‬
‫در این حالت‪ ،‬ماژول کارهای مختلفی را انجام می دهد که وجه ارتباط آنها در این‬
‫است که همه بر روی ساختارهای داده ای مشترک انجام می شود‪.‬‬
‫‪ Functional .7‬چسبندگی تابعی‬
‫بهترین حالت می باشد و در اینجا ماژول فقط یک کار واحد انجام می دهد‪.‬‬
‫رساندن ‪ 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
Accept Change
request
Check CI out of
project database
Change the CI
as required
Evaluate Change request
on the given parameters
Generate ECO for each
approved change
Perform necessary
SQA activities
Check CI into
project database
Present the
Change report
Use the Change report
to make a final decision
on status and priority of
change
Use appropriate version
control mechanisms to
create next version of
the software
‫کنترل تغییرات‬
‫ارائه ی گزارش تغییر‬
‫ارزیابی درخواست تغییر در پارامترهای‬
‫موجود‬
‫پذیرش درخواست‬
‫تغییر‬
‫استفاده از گزارش تغییر برای اخذ‬
‫تصمیم نهایی بر روی وضعیت و‬
‫اولویت تغییر‬
‫خارج کردن آیتم مورد نظر از انباره‬
‫ی پروژه برای انجام تغییرات تأیید‬
‫شده‬
‫بررس ی آیتم جهت تغییر‬
‫خارج از انباره ی پروژه‬
‫اختصاص نسخه یا ورژن جدید‬
‫برای آیتم تغییر یافته‬
‫بازگردان آیتم تغییر‬
‫یافته به انباره ی پروژه‬
‫انجام عملیات کنترل‬
‫کیفیت الزم‬
‫انجام تغییرات مورد‬
‫نیاز بر روی آیتم مورد‬
‫نظر‬
‫‪ .1‬دریافت و درخواست تغییر‬
‫‪ .2‬بررس ی گزارش تغییر از لحاظ پارامترهایی نظیر مسائل فنی و هزینه و زمان آن‬
‫‪ .3‬ساخت گزارش تغییر توسط شخص یا تیم مربوطه‬
‫‪ .4‬تعیین انجام یا عدم انجام تغییر و اولویت آن توسط مدیریت‬
‫‪ .5‬خارج کردن آیتم مورد نظر برای تغییر از انباره ی پروژه (الکترونیکی (‪ )hard‬یا‬
‫فیزیکی(گزارش))‬
‫‪ .6‬اعمال تغییرات روی آیتم مورد نظر‬
‫‪ .7‬انجام عملیات کنترل کیفیت الزم‬
‫‪ .8‬بازگرداندن آیتم به انباره ی پروژه‬
‫‪ .9‬اختصاص نسخه یا ورژن (‪ )version‬جدید برای آیتم تغییر یافته‪.‬‬
‫انباره ی ‪( SCM‬انباره ی مدیریت پیکربندی)‬
‫منظور از انباره ی ‪ SCM‬محل فیزیکی و الکترونیکی است که در آن کلیه ی اطالعات‬
‫پروژه نگهداری می شود‪ .‬بدیهی است این محل می بایست مقیاس پذیر ‪ ،‬قابل اطمینان‬
‫‪ ،‬در دسترس و شفاف باشد‪.‬‬
‫ابزارهای ‪: SCM‬‬
‫برای مدیریت ‪ SCM‬ابزارهای نرم افزاری متفاوتی وجود دارد که می تواند کار ‪SCM‬‬
‫را تسهیل نماید‪ .‬دو تا از مهمترین این ابزارها عبارتند از ‪:‬‬
‫‪Configuration Management Assistant .1‬‬
‫‪Adele .2‬‬
‫فصل ‪8‬‬
‫فاز نگهداری ‪:‬‬
‫فاز نگهداری آخرین مرحله چرخش زندگی هر نرم افزار می باشد و پس از نصب و راه‬
‫اندازی نرم افزار ‪ ،‬آغاز و تا انتهای استفاده از نرم افزار ادامه می یابد‪.‬‬
‫‪:Maintenance‬‬
‫فعالیتهایی است شامل ارتقاء (باال بردن سرویسهای آن)‪ ،‬تطابق یا ‪ adapting‬و‬
‫اصالح یا ‪ correcting‬می باشد‪(.‬برطرف کردن مشکالت)‬
‫انواع مشکالتی که در ‪ maintenance‬یا فاز نگهداری هستند به ‪ 3‬دسته‬
‫تقسیم می شوند‪:‬‬
‫‪( Emergency fix .1‬اصالحات اضطراری)‬
‫این دسته از مشکالت ‪ ،‬مشکالتی هستند که در کار سیستم ‪ ،‬اختالالت جدی به وجود‬
‫آورده و می بایست در اسرع وقت برطرف شوند‪.‬‬
‫‪( Urgent fix .2‬اصالحات ضروری)‬
‫ً‬
‫این دسته از مشکالت نیز حتما می بایست در سیستم برطرف شود اما سرعت برطرف کردن‬
‫آنها می تواند دیرتر از اصالحات ضروری باشد‪.‬‬
‫‪( Nice to have fix .3‬اصالحات ارجح یا مناسب)‬
‫این گونه اصالحات یا تغییرات بهتر است در سیستم انجام شود‪ .‬اما اولویت زمانی برای انجام‬
‫آنها باال نمی باشد‪.‬‬
‫مشکالت مرحله ی نگهداری ‪:‬‬
‫‪ .1‬وجود پرسنل دینامیک ‪: Dynamic personnel‬‬
‫که هزینه ی آموزش زیادی را می تواند به سیستم تحمیل کند‪.‬‬
‫‪Motivation and morale .2‬‬
‫‪Lack of documentation .3‬‬
)‫ عدم یکپارچگی کد(قطعه قطعه بودن آن‬Pathy code .4
‫ استفاده از تکنولوژی از رده‬Outdated or obsolete technology .5
‫خارج‬
‫ ساعته یا شبانه روزی‬24 ‫ فعالیت های‬Round-the-clock operation .6
:Maintenance Metrics
System availability .1
Maintenance turnaround .2
Productivity .3
‫ حجم نرم افزاری است که در مرحله ی‬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…
‫اما این استراتژی نیاز به نیروی کار و هزینه ی زیادی دارد‪ .‬این استراتژی مناسب سیستم هایی‬
‫هستند که اهمیت باالیی دارند مثل سیستم های مالی‪.‬‬
‫‪ .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‬در برنامه ریزی برای این پروژه ها می بایست ‪:‬‬
‫‪ .2-1‬تعدا چرخش های مورد نیاز را تخمین زد‪.‬‬
‫‪ .2-2‬مشخص کرد که در انتهای هر چرخه ‪ ،‬چه حجم یا درصدی از کارها انجام شده است‪.‬‬