کوشا فایل
کوشا فایل بانک فایل ایران ، دانلود فایل و پروژهکوشا فایل
کوشا فایل بانک فایل ایران ، دانلود فایل و پروژهپایان نامه تجزیه و تحلیل امکان‌پذیر و طرح پیشنهادی سیستم(رشته کامپیوتر)
اختصاصی از کوشا فایل پایان نامه تجزیه و تحلیل امکان‌پذیر و طرح پیشنهادی سیستم(رشته کامپیوتر) دانلود با لینک مستقیم و پرسرعت .
فرمت فایل : word(قابل ویرایش)
تعداد صفحات:67
فهرست مطالب:
فصل بازنگری و اهداف: 3
شناسایی: 4
تجزیه و تحلیل امکان‌پذیر و پیشنهاد سیستم: 5
تجزیه و تحلیل سیستمها- نقاط آغازین تعریف حدود: 8
تجزیه و تحلیل سیستمها – نقاط آغازین تجزیه و تحلیل مشکلات: 9
طراحی سیستم – نقطة آغازین تجزیه و تحلیل تصمیمات: 9
آزمایش برای امکان‌پذیری: 10
امکان‌پذیری عملی: 11
امکان‌پذیری تکنیکی: 12
آیا تکنولوژی پیشنهادی یا راه حلها عملی هستند؟ 12
آیا ما فعلا تکنولوژی ضروری را دارا هستیم؟ 12
آیا ما دارای متخصصان تکنیکی ضروری هستیم؟ 13
امکان‌پذیری زمانبندی: 13
امکان‌پذیری اقتصادی: 14
تکنیکهای تجزیه و تحلیل سود- زیان: 14
سیستم چقدر می‌ارزد؟ 15
هزینه‌های هر تجهیزات کامپیوتری و نرم‌افزاری. 16
چه منافعی و سودهایی را سیستم فراهم می‌آورد؟ 17
جدول 2-10 هزینه‌های راه حل سیستمهای پیشنهاد شده 18
آنالیز بازپرداخت: 22
شکل 3-10 – تجزیه و تحلیل بازپرداخت برای یک پروژه 24
شکل 4-10- جدول جزئی برای ارزش کنونی یک دلار 25
در تحلیل بازگشت سرمایه‌گذاری و بازگشت به سرمایه‌گذاری: 28
ارزش موجود: 29
شکل 5-10: تجزیه و تحلیل ارزش جاری برای یک پروژه 30
تجزیه و تحلیل امکان‌پذیر سیستمهای منتخب: 31
زمینه سیستمهای منتخب: 32
شکل 6-10 – الگوی قالب سیستمهای منتخب 34
شکل 7-10 قالب سیستمهای منتخب ساده: 35
روشهای آنالیز سیستمها: 37
زمینة آنالیز ممکن: 39
جدول 8-10 40
جدول 9-10 نمونة تجزیه و تحلیل امکان‌پذیری زمینه: 41
نوشتن گزارش: 42
طول و بلندی گزارش نوشته شده: 43
سازماندهی گزارش نوشته شده: 43
جدول 10-10 قالبهایی برای گزارشات نوشته شده: 44
شکل 11-10: عناصر ثانویه برای یک گزارش نوشته شده: 44
شکل 12-10 47
ارائة اولیه: 48
شکل 13-10 49
آمادگی و محیا نمودن برای ارائة اولیه: 50
شکل 14-10 51
هدایت موارد پیشنهادی اولیه: 52
اقدامات بعدی ارائة اولیه: 55
پرسشهای مرورکننده: 58
مشکلات و تمارین (عملکردها): 59
موارد کوچک: 65
تیم و تمارین فردی: 66
چکیده:
فصل بازنگری و اهداف:
سیستمهای خوب از طریق راه حلهای جایگزین ارزیابی شده قبل از پیشنهاد تغییرات مورد تجزیه و تحلیل قرار می‌گیرند. در این فصل شما می‌توانید یاد بگیرید که چگونه این جایگزینها را مورد تجزیه و تحلیل قرار داده و بر اساس 4 شرط ممکن آنها را مستندسازی نمایید. عملی، تکنیکی، برنامه‌ریزی و زمانبندی و اقتصادی شما همچنین یاد می‌گیرید که چگونه یک سیستم پیشنهادی به شکل گزارش نوشته شده و یا یک مورد ارائه شده شکل گرفته بسازید شما خواهید دانست که شما امکان تجزیه و تحلیل را و مهارتهای پیشنهادی را فهمیده و درک می‌کنید که برای تجزیه و تحلیلکنندگان سیستمها موردنیاز می‌باشد هنگامیکه شما می‌توانید:
- خطوط آغازین امکان‌پذیر در چرخه سیستم را شناسایی کنید .
- راه‌حلهای جایگزین سیستم را شناسایی کنید.
3ـ 4 نوع از موارد امکان‌پذیر و شروط مرتبط با آنها را شناسایی کرده و توضیح دهید.
4ـ آنالیزهای مختلف به صرفه از لحاظ هزینه را با استفاده از هزینه‌های با تنظیم زمانی و سود ممکن اجرا نمایید.
5- گزارشات پیشنهادی سیستم مناسب را برای ملاقاتهای رسمی مختلف بنویسید.
6- برای یک مورد ارائه شونده به صاحبان سیستمها و کاربران آن نقشه‌ریزی می‌کنید.
شناسایی:
هنگامیکه تمام تجزیه و تحلیلها در مورد پروژه سیستم خدمات اعضای مراحل صوتی انجام شد، باب مارتین در مورد آن برانگیخته‌تر و تحریک شده‌تر بود. برنامه‌ریزی در باب شبیه به پریدن در داخل و شروع نموده به رمزگذاری سیستم اطلاعاتی می‌باشد. اما سند را رئیس او به او راه‌حلهای بسته‌بندی شده تحقیقاتی در بازار را اعطا نمود که گران بود. اما سپس تعدادی سند را برای هزینه‌های کار برنامه‌ریزی در خانه به کار انداخت.
باب فهمید که راه‌حلهای بسته‌بندی شده به طور مرتبط گران نبودند و می‌توانند با سرعت هر چه تمامتر در یک مکان قرار گیرند. باید برنامه‌ریزی برای انجام آن وجود داشته باشد بخاطر اینکه راه حلهای بسته‌بندی شده نیازمند به سنتی شدن برای یافتن تمام نیازمندیها می‌باشد.
تصمیم نهایی در مورد اینکه کدام راه حل برای انتخاب باید توسط کمیته راهنمایی انجام شود باید اتخاذ شود که سرپرستی پروژه بود. سند و موارد اجرائی را دو کمیته سرپرستی مطرح کرد که در حال حاضر بسیار آگاه به بودجه‌بندی هستند.انها باید تعداد را به دقت بررسی و موشکافی می‌کردند و پروژه را فقط برای ادامه یافتن بهبود می‌بخشیدند. اگر یک بازگشت ثابت به سرمایه را نشان می‌داد باب دارای نقش و سهم کوچکی در ارائه پیشنهادات برای سیستم بوده. او تحقیق و مطالعه بر روی حقایق انجام داد برای اینکه اطمینان حاصل کند که او برای هر گونه درخواست و سئوالی آمادگی دارد. او نمی‌خواست که آن را از دست بدهد. او متعجب شد از اینکه در حال حاضر او خوشحال بود از اینکه دانشگاه او از او خواست که در یک مکان تجاری حضور داشته باشد و موارد قانونی را ارائه کند.
تجزیه و تحلیل امکان‌پذیر و پیشنهاد سیستم:
در جهان مشاغل امروز به طور فزاینده‌ای مشاهده می‌شود که تجزیه و تحلیلکنندگان باید یاد بگیرند که مانند مدیران تجاری فکر کنند. کاربردهای کامپیوتر در یک حرکت ثبت شده در حال افزایش وسعت است. در حال حاضر مدیران از سیستمهای اطلاعاتی انتظار دارند که مبالغی را برای آنها بپردازند. اطلاعات یک سرمایه‌گذاری مهم است که باید تنظیم شود. درست مانند بازار که باید یک محصول جدید را تنظیم نماید و کارخانه باید یک طرح یا تجهیزات جدید را تنظیم نماید. تجزیه و تحلیلکنندگان سیستمها برای کمک به پاسخ سئوالات مطرح شده فراخوانده شدند. آیا سرمایه‌ای برای خود آن پرداخت شد؟ آیا سرمایه‌گذاریهای دیگری وجود دارند که حتی بیشتر به هزینه‌های آن باز می‌گردند؟
این بخش در ارتباط با موارد منتشر شده تجزیه و تحلیلهای امکان‌پذیر برای آنالیزکنندگان سیستمها و کاربران سیستمهای اطلاعاتی می‌باشد که همچنین اهمیت ارائه پیشنهادات به مدیریت را به شکل پیشنهاد یک سیستم تأیید می‌کند که یک یک گزارش نوشته شده قانونی یا ارائه شده به صورت زبانی و شفاهی است تجزیه و تحلیل امکان‌پذیر برای فازهای تجزیه و تحلیل سیستمها مناسب است اما خصوصا برای فاز تجزیه و تحلیل تصمیم‌گیری مهم است. پیشنهاد سیستم ارائه دهنده موارد قابل تحویل و ارائه دهنده دانش تکنیکی، فرآوری و راه‌حلهای انبوه می‌باشد.
تجزیه و تحلیل امکان‌پذیر- دستیابی به کاربرد یک جنبش:
بگذارید با یک تعریف قانونی از تجزیه و تحلیل امکان‌پذیر آغاز کنیم. امکان‌پذیری یک اندازه از چگونگی سود و یا عملکرد توسعه یک سیستم اطلاعاتی است که باید تبدیل به یک سازمان شود. تجزیه و تحلیل امکان‌پذیر فرآیندی است که با آن امکان‌پذیری اندازه‌گیری می‌گردد.
امکان‌پذیری باید از طریق چرخه زندگی اندازه‌گیری شود. در بخشهای قبلی به آن دستیابی به حکم جنبش برای امکان‌پذیری می‌گوییم. حدود و پیچیدگی یک پروژه امکان‌پذیر ظاهرا میتواند بعد از مشکلات ابتدایی و فرصتها تغییر کند که کاملا میتواند آنالیز شود یا پس از اینکه سیستم طراحی گردید. بنابراین پروژه‌ای که در یک مکان (زمان خاصی) امکان‌پذیر می‌باشد میتواند برای زمان بعد از آن غیر امکان‌پذیر باشد.
شکل 1-10 نشان دهنده نقاط آغازین در طول فازهای تجزیه و تحلیل سیستمهای چرخه زندگی ما می‌باشد. نقاط آغازین توسط لوزیهای قرمز رنگ ارائه می‌شوند. لوزیهای معرف ارزشهایی امکان‌پذیر مجدد است و بررسی مدیریت باید متوقف شود یا از نقطه آغازین دیگری رشد کند علاوه بر همه منابعی که صرف شده است.
اغلب برخورد با نظریه متوقف نمودن یک پروژه مشکل است. یک انحراف طبیعی میتواند برای تنظیم ادامه یک پروژه بر اساس زمان پولی به کار رود که در حال حاضر، صرف آن می‌شود. بنابراین یک اصل زیربنایی مدیریت هیچ گاه هدر دادن پولهای مفید بعد از جدا کردن موارد زیان نمی‌باشد و بر روی یک پروژه امکان‌پذیرتر حرکت می‌نماید. تصمیم به توقف به معنای این نیست که قیمتهای صرف شده مهم نمی‌باشد هزینه‌ها باید سرانجام پوشش داده شوند اگر سرمایه‌گذاری یک موفقیت در نظر گرفته شود. بگذارید به طور کامل نقاط آغازین را در شکل 1-10 مورد آزمایش قرار دهیم.
تجزیه و تحلیل سیستمها- نقاط آغازین تعریف حدود:
اولین تجزیه و تحلیل ممکن در طول مرحله تعریف حدود هدایت می‌شود در این مرحله اولیه از پروژه امکان‌پذیری به ندرت بیشتر از اندازه‌گیری فوری و ضروری شکل و برآورد مقطوع اولیه توسعه هزینه‌ها می‌باشد. این به سئوالها پاسخ می‌دهد مسائل را به انجام می‌رساند تضمین‌کننده هزینه‌های مطالعات دارای جزئیات می‌باشد و تجزیه و تحلیل سیستمهای جاری را انجام می‌دهد. از لحاظ واقعی، امکان‌پذیری نمی‌تواند به دقت اندازه‌گیری شود تا زمانی که مشکلات (و فرصتها) و نیازمندیها بهتر درک شوند.
بعد از برآورد منافع حل مشکلات و فرصتها، تجزیه و تحلیل کننده هزینه‌های توسعه سیستم مورد پیش‌بینی را برآورد می‌نماید. آنالیز مورد تجزیه به طور معمول افزایش دهنده این هزینه‌ها تا 50 تا 100 درصد (یا بیشتر) می‌باشد بخاطر اینکه تجربه به آنها می‌گوید که مشکلات بندرت به خوبی تعریف و شناسایی می‌شوند و نیازمندیهای استفاده کننده به طور نوعی درک و تفهیم می‌شود.
تجزیه و تحلیل سیستمها – نقاط آغازین تجزیه و تحلیل مشکلات:
نقاط آغازین بعدی بعد از مطالعات با جزئیات بیشتر و تحلیل مشکلات سیستم جاری اتفاق می‌افتد. بخاط اینکه مشکلات بهتر درک می‌شوند، تجزیه و تحلیل میتواند برآوردهای توسعه هزینه‌ها را بهتر سازد و منافعی میتواند از یک سیستم جدید بدست آید. ارزش حداقل حل یک مشکل برابر با هزینه مشکل می‌باشد. برای مثال اگر هزینه‌های حمل موجودی کالا 35000 دلار بالاتر از محدوده‌های مورد پذیرش باشد سپس ارزش حداقل سیستم اطلاعاتی قابل قبول باید 35000 دلار باشد. اینطور انتظار می‌رود که یک سیستم بهبود یافته دارای قابلیت بهتر نسبت به آن می‌باشند بنابراین این مورد باید به این ارزش حداقل برگردد.
قیمتهای توسعه یافته در این نقطه هنوز هم فقط در حد حدث و گمان هستند. آنالیزکنندگان هنوز هم به طور کامل نیازمندیهای کاربران را برای اختصاص یک راه حل طراحی شده بخصوص برای آن نیازمندیها می‌شناسند.
اگر براوردهای هزینه به طور قابل توجهی از مرحله مورد تحقیق آستانه به سمت مرحله آنالیز مشکلات افزایش یابد، مقصر میدان دید و محدوده است. محدوده دارای یک شدت برای افزایش در بسیاری از پروژه‌ها می‌باشد .اگر امکان تهدید محدوده‌ها افزایش یابد، پس محدوده ممکن است کاهش یابد.
طراحی سیستم – نقطه آغازین تجزیه و تحلیل تصمیمات:
فاز آنالیز تصمیم‌گیری ارایه دهنده یک فعالیت تجزیه و تحلیل مهم در هنگامی است که آن یکی از موارد اجرائی ممکن را طرح‌ریزی می‌کند که به عنوان یک هدف برای طراحی سیستم می‌باشد.
مشکلات و نیازمندیها باید تاکنون شناسایی شده باشند. در طول فاز آنالیز تصمیم‌گیری، راه‌حلهای جایگزین در عبارات روشهای ورودی خروجی و روشهای نگهداری داده‌ها تعریف می‌شوند و نیازمندیهای سخت‌افزاری و نرم‌افزاری، روشهای فرآوری و موارد اجرائی عموم می‌باشد. لیست موجود ارائه دهنده یک محدوده نوعی از اختیارات است که میتواند توسط یک تحلیلگر ارزیابی گردد.
هیچ کاری انجام ندهید. سیستم موجود را تنها بگذارید. بدون ارتباط با اختیارات مدیریت یا نظرات شما این انتخاب باید مورد بررسی قرار گیرد و به عنوان انتخاب یک خط مبنا بر خلاف آنچه که دیگران می‌توانند و باید برآورد کنند تحلیل شود.
راه‌اندازی و اداره دوباره فرآیندهای شغلی نه فرآوریهای بر اساس کامپیوتر که این میتواند در ارتباط با فعالیتهای ساده کاهش دادن تکثیر و کار غیرضروری و سازماندهی دوباره چیدمان اداره و حذف کردن تکراری‌ها و فرمهای غیرضروری و دوبله و فرآیندها در بین موارد دیگر می‌باشد.
فرآیندهای کامپیوتری موجود را افزایش می‌دهد.
خریداری یک برنامه کاربردی بسته بندی شده.
طراحی و ساخت یک سیستم جدید بر اساس کامپیوتر.
بعد از تعریف این موارد انتخابی، هر کدام برای عملکرد و امکانهای اقتصادی، برنامه‌ریزی و تکنیکی مورد تحلیل قرار می‌گیرند یکی از جایگزینها پیشنهاد به صاحبان سیستم برای بهبود بخشیدن و یک زیربنا بر این طراحی کلی و دارای جزئیات می‌باشد.
آزمایش برای امکان‌پذیری:
بنابراین ما دارای امکان‌پذیری تعریف شده و تجزیه و تحلیل امکان‌پذیری سیستم و ما نقاط آغازین انعطاف‌پذیری را در طول تجزیه و تحلیل سیستمها تعریف نموده‌ایم. امکان‌پذیری میتواند از نقطه نظرات متعددی مورد نگرش قرار گیرد. در زیر ما 4 لیست از آزمایشات امکان‌پذیری را آماده نموده‌ایم.
امکان‌پذیری عملی یک اندازه‌گیری از چگونگی این مورد است که چگونه یک راه حل دارای برخورد با نیازمندیهای سیستم تعریف شده برای حل مشکلات و توسعه فرصتهای رؤیایی برای سیستم می‌باشد؟
امکان‌پذیری تکنیکی یک اندازه‌گیری از خصوصیات راه حلهای بخصوص تکنیکی و آمادگی منابع تکنیکی می‌باشد و اندازه‌گیری آمادگی متخصصان برای اجرا و ادامه آن می‌باشد.
امکان‌پذیری زمانبندی شده اندازه‌گیری چگونگی زمانبندی پروژه می‌باشد.
امکان‌پذیری اقتصادی یک اندازه‌گیری از تأثیرات هزینه‌های یک پروژه یا یک راه حل می‌باشد.
به طور واقعی، سیستمهای اندکی غیرامکان‌پذیر هستند. به جای آن انتخاب راه حلهای مختلف تمایل به امکان کمتر نسبت به موارد دیگر دارد بگذارید یک نگاه اجمالی‌تر به 4 شرط ممکن بیندازیم.
امکان‌پذیری عملی:
امکان‌پذیری عملی اندازه‌گیری سیستمهای پیشنهاد شده‌ای است که مشکلات را حل می‌کنند و فوایدی را به فرصتها برای شناسایی فرصتها در طول تعریف میدان دید و فازهای تحلیل مشکل و چگونگی رضایتمندی از برطرف شدن نیاز سیستمهای تعریف شده در فاز تحلیل نیازمندیها را ارائه می‌دهد. امکان‌پذیری عملی همچنین سئوال می‌کند که اگر چیزی که امروزه در مورد مشکلات و هزینه راه‌حلها است، باشد و مشکل هنوز هم به بدترین شکل در حال حل شدن است. چهارچوب قطعات (بخش 2) میتواند به عنوان یک مبنا برای تجزیه و تحلیل ضرورت حل مؤثر یک مشکل مورد استفاده قرار گیرد.
امکان‌پذیری تکنیکی:
امروزه بسیار کم از لحاظ تکنیکی غیرممکن است. نتیجتا امکان‌پذیری تکنیکی به چیزی می‌نگرد که عملی و مدلل باشد امکان تکنیکی آدرس دهنده سه مورد منتشره مهم می‌باشد.
1- آیا یک تکنولوژی پیشنهادی یا راه حل عملی است؟
2- آیا ما به طور معمول دارای تکنولوژی ضروری هستیم؟
3- آیا ما دارای متخصصان تکنیکی ضروری هستیم؟
آیا تکنولوژی پیشنهادی یا راه حلها عملی هستند؟
راه‌حلها به طور معمول آماده و حاضر هستند. پرسش این است که آیا تکنولوژی به اندازه کافی اشباع است که بتواند به آسانی برای مشکلات ما به کار رود؟ برخی از موارد اثبات شده برای استفاده از تکنولوژی مرحله‌ای از هنر شبیه می‌باشد اما موارد ثابت شده ترجیح می‌دهند که از تکنولوژی اشباع شده یا بهبود یافته استفاده کنند. یک تکنولوژی اشباع دارای مشتریان بزرگتری برای دستیابی به آگاهی از مشکلات و بهبودی آنها هستند.
آیا ما فعلا تکنولوژی ضروری را دارا هستیم؟
با فرض اینکه راه حلهای تکنولوژی موردنیاز عملی هستند ما باید بعدا از خودمان سئوال کنیم که آیا تکنولوژی در سیستمهای اطلاعاتی ما موجود است یا نه؟ اگر تکنولوژی موجود است ما باید سئوال کنیم که آیا ما دارای ظرفیت هستیم؟ برای مثال آیا پرینتر ما خواهد توانست گزارشات جدیدی را راه‌اندازی کند و نیازمندیهای سیستم جدید را شکل دهد؟
اگر جواب به هر یک از این سئوالات منفی (نه) است، سپس باید از خودمان بپرسیم که آیا می‌توانیم این تکنولوژی را بدست آوریم، تکنولوژی میتواند عملی و یا در دسترس باشد و بله ما به آن نیاز داریم. اما به طور ساده ممکن است قادر به تهیه آن در این زمان نباشیم. بنابراین این بحث در مورد امکان اقتصادی وسعت می‌یابد که این یک امکان تکنیکی صحیح می‌باشد. اگر نتوانیم، از عهده تکنولوژی براییم، سپس جایگزینهایی که نیازمند به تکنولوژی هستند عملی نیستند و از لحاظ تکنیکی امکان‌پذیر نیستند.
آیا ما دارای متخصصان تکنیکی ضروری هستیم؟
این بررسی از امکان تکنیکی اغلب در طول تجزیه و تحلیل امکان‌پذیری فراموش می‌شود حتی اگر یک شرکت دارای تکنولوژی باشد که به این معنا نباشد که او دارای مهارتهای موردنیاز برای کاربرد مناسب آن که تکنولوژی است می‌باشد. برای مثال یک شرکت میتواند دارای یک سیستم مدیریت پایگاه اطلاعاتی باشد (DBMS) بنابراین تحلیلگر و برنامه‌ریزان آماده برای پروژه می‌توانند ناآگاه از این باشندکه DBMS برای بکارگیری به طور مناسب کافی خواهد بود. درست است تمام افراد حرفه‌ای سیستمهای اطلاعاتی می‌توانند تکنولوژی جدید را یاد بگیرند. بنابراین منحنی یادگیری باید در امکانات تکنیکی پروژه فشرده شوند به طور مخصوص میتواند زمانبندی را فشرده نماید.
امکان‌پذیری زمانبندی:
ارائه یک تخصص تکنیکی موجود که به طور مدلل سررسید پروژه هستند وجود دارد چه چیزی امکان زمانبندی پروژه است؟ برخی پروژه‌ها با سررسیدهای بخصوصی آغاز می‌شوند. تعیین این موارد ضروری است که ایا سررسیدها اجباری هستند یا قابل طراحی می‌باشند؟ برای مثال یک پروژه برای توسعه یک سیستم باید با تنظیمات گزارش‌دهی دولتی برخورد کند که دارای سررسیدی است که همزمان با زمانی است که دولت جدید باید آغازگر باشد امتیازات منفی به همراه از دست دادن یک سررسید میتواند آن را با اجبار روبرو سازد اگر سررسیدها نسبت به الزامات طراحی شده باشند، تحلیلگر میتواند زمان‌بندیهای جایگزینی را پیشنهاد دهد.
که این برای رهاسازی یک سیستم اطلاعاتی عملیاتی دو ماه بعد از تحویل یک خطا بدون استفاده از سیستم اطلاعایت در این زمان، ترجیح داده می‌شود (مگر اینکه سررسید به طور قطعی و کاملا اجباری باشد). هنگامیکه از دست دادن آخرین مهلتها میتواند مشکل‌ساز باشد، توسعه سیستمهای نامناسب میتواند خطرناک باشد این یک انتخاب بین کمتر شدن دو مورد ناشناخته است.