<![CDATA[انجمن دانشجویان دانشکده آموزشهای الکترونیکی دانشگاه شیراز - مدیریت توسعه نرم افزار]]> https://forums.svus.ir/ Tue, 13 Oct 2026 09:57:34 +0000 MyBB <![CDATA[گواهینامه و استانداردهای تولید نرم افزار در ایران (نماتن)]]> https://forums.svus.ir/Thread-%DA%AF%D9%88%D8%A7%D9%87%DB%8C%D9%86%D8%A7%D9%85%D9%87-%D9%88-%D8%A7%D8%B3%D8%AA%D8%A7%D9%86%D8%AF%D8%A7%D8%B1%D8%AF%D9%87%D8%A7%DB%8C-%D8%AA%D9%88%D9%84%DB%8C%D8%AF-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-%D8%AF%D8%B1-%D8%A7%DB%8C%D8%B1%D8%A7%D9%86-%D9%86%D9%85%D8%A7%D8%AA%D9%86 Fri, 26 Oct 2012 09:56:08 +0000 sarshogh_eng]]> https://forums.svus.ir/Thread-%DA%AF%D9%88%D8%A7%D9%87%DB%8C%D9%86%D8%A7%D9%85%D9%87-%D9%88-%D8%A7%D8%B3%D8%AA%D8%A7%D9%86%D8%AF%D8%A7%D8%B1%D8%AF%D9%87%D8%A7%DB%8C-%D8%AA%D9%88%D9%84%DB%8C%D8%AF-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-%D8%AF%D8%B1-%D8%A7%DB%8C%D8%B1%D8%A7%D9%86-%D9%86%D9%85%D8%A7%D8%AA%D9%86
[img]d:%5CAndishmandCo%5CAdami%5CResearch%5Cnamatan.jpg[/img]
[img]d:%5CAndishmandCo%5CAdami%5CResearch%5Cnamatan.gif[/img]
استاندارد تولید نرم افزار و در نتیجه اخذ گواهی " گواهینامه فنی نرم افزار " برای محصولات نرم افزاری در ایران

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

جهت اطلاعات بیشتر به ضمیمه فراجعه فرمایید 4 4
.pdf   NMTN3.FinalReport.pdf (اندازه 1.28 MB / تعداد دانلود: 247) -->
NMTN3.FinalReport.pdf
دفعات دانلود حجم فایل نوع فایل
247 1.28 MB .pdf
]]>
[img]d:%5CAndishmandCo%5CAdami%5CResearch%5Cnamatan.jpg[/img]
[img]d:%5CAndishmandCo%5CAdami%5CResearch%5Cnamatan.gif[/img]
استاندارد تولید نرم افزار و در نتیجه اخذ گواهی " گواهینامه فنی نرم افزار " برای محصولات نرم افزاری در ایران

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

جهت اطلاعات بیشتر به ضمیمه فراجعه فرمایید 4 4
.pdf   NMTN3.FinalReport.pdf (اندازه 1.28 MB / تعداد دانلود: 247) -->
NMTN3.FinalReport.pdf
دفعات دانلود حجم فایل نوع فایل
247 1.28 MB .pdf
]]> <![CDATA[اصول تهیه RFP برای پروژه های فناوری اطلاعات]]> https://forums.svus.ir/Thread-%D8%A7%D8%B5%D9%88%D9%84-%D8%AA%D9%87%DB%8C%D9%87-RFP-%D8%A8%D8%B1%D8%A7%DB%8C-%D9%BE%D8%B1%D9%88%DA%98%D9%87-%D9%87%D8%A7%DB%8C-%D9%81%D9%86%D8%A7%D9%88%D8%B1%DB%8C-%D8%A7%D8%B7%D9%84%D8%A7%D8%B9%D8%A7%D8%AA Sun, 07 Oct 2012 18:08:44 +0000 Armin]]> https://forums.svus.ir/Thread-%D8%A7%D8%B5%D9%88%D9%84-%D8%AA%D9%87%DB%8C%D9%87-RFP-%D8%A8%D8%B1%D8%A7%DB%8C-%D9%BE%D8%B1%D9%88%DA%98%D9%87-%D9%87%D8%A7%DB%8C-%D9%81%D9%86%D8%A7%D9%88%D8%B1%DB%8C-%D8%A7%D8%B7%D9%84%D8%A7%D8%B9%D8%A7%D8%AA مدیریت پروژه های فناوری اطلاعات

اصول تهیه RFP برای پروژه های فناوری اطلاعات

فرنود حسنی

کلمه های کلیدی: پروژه- مدیریت پروژه- فناوری اطلاعات – برنامه ریزی- بودجه - RFP-Request for Proposal

درآمد:

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

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

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

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

مقدمه:

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

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

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

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

RFP چیست؟

اگر تا کنون در پروژه های مختلف فعالیت کرده باشید یا در جلسات مقدماتی یک مناقصه حضور پیدا کرده اید حتما عبارتRFP بارها به گوش شما خورده، شاید هم در آگهی های مناقصه یا در روزنامه ها و مجلات این عبارت را شنیده باشید.RFP یا درخواست طرح پیشنهادی خلاصه ای از عبارت سه کلمه ای           Request for Proposal می باشد.

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

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

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

شرکت های پیمانکار مناقصه ها با خواندن RFP و نوشتن طرح پیشنهادی خود به تشریح توانایی های خود برای تامین نیاز ها و  درخواست های لحاظ شده و تعیین شده برای چهارچوب پروژه می کنند.

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

محتوای یک طرح پیشنهادی شامل موارد زیر است:

  •       خلاصه مدیریتی- خلاصه ای از تمام پروژه که در یک یا چند صفحه اطلاعات کلی و لازم را در اختیار خواننده می گذارد.
  •       شرح ضرورت- تشریح ضرورت انجام پروژه و تاثیرات آن در کسب و کار
  •       تشریح پروژه-  تشریح چگونگی اجرا و ارزیابی پروژه
  •       اطلاعاتی در مورد سازمان
  •       برنامه زمانی پروژه
  •       بودجه
  •       نتایج پروژه

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

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

از RFP زمانی استفاده می شود که:

1-      بایستی برای ارزیابی و انتخاب یک خدمات دهنده، فرآیندی کارشناسی، منصفانه و رقابتی صورت گیرد.

2-      برای به انجام رساندن نیازهایی معین و جدید در سازمان نیاز به پاسخ هایی متناسب با شرایط زمانی باشد نه راه حل های آماده و در دسترس

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

تهیه RFP چه مزیت هایی دارد؟

1-      شناخت نیازهای واقعی سازمان و یا بخشی که قرار است پروژه ای در آن انجام شود.

2-      جمع آوری اطلاعات دقیق بر اساس مشکلات واقعی و نیازهای کاربران

3-      دستیابی به تخمین درستی از هزینه و زمان مورد نیاز برای پروژه

4-      امکان مقایسه شرکت های مختلف ارائه دهنده خدمات مشابه

5-      کمک به برنامه ریزی و تصمیم گیری دقیق و آگاهانه

6-      کاهش شکایت های احتمالی مجریان و کارفرمایان

7-      کمک به تنظیم دقیق قرداد

8-      فراهم شدن امکان دریافت پیشنهاد های تکمیلی و راه حلهای جدید برای اجرای بهتر پروژه

9-      افزایش توان مدیر پروژه

دانلود کامل مقاله:

دیدن لینک ها برای شما امکان پذیر نیست. لطفا ثبت نام کنید یا وارد حساب خود شوید تا بتوانید لینک ها را ببینید.

منبع نوشتار:

دیدن لینک ها برای شما امکان پذیر نیست. لطفا ثبت نام کنید یا وارد حساب خود شوید تا بتوانید لینک ها را ببینید.

]]> مدیریت پروژه های فناوری اطلاعات

اصول تهیه RFP برای پروژه های فناوری اطلاعات

فرنود حسنی

کلمه های کلیدی: پروژه- مدیریت پروژه- فناوری اطلاعات – برنامه ریزی- بودجه - RFP-Request for Proposal

درآمد:

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

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

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

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

مقدمه:

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

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

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

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

RFP چیست؟

اگر تا کنون در پروژه های مختلف فعالیت کرده باشید یا در جلسات مقدماتی یک مناقصه حضور پیدا کرده اید حتما عبارتRFP بارها به گوش شما خورده، شاید هم در آگهی های مناقصه یا در روزنامه ها و مجلات این عبارت را شنیده باشید.RFP یا درخواست طرح پیشنهادی خلاصه ای از عبارت سه کلمه ای           Request for Proposal می باشد.

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

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

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

شرکت های پیمانکار مناقصه ها با خواندن RFP و نوشتن طرح پیشنهادی خود به تشریح توانایی های خود برای تامین نیاز ها و  درخواست های لحاظ شده و تعیین شده برای چهارچوب پروژه می کنند.

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

محتوای یک طرح پیشنهادی شامل موارد زیر است:

  •       خلاصه مدیریتی- خلاصه ای از تمام پروژه که در یک یا چند صفحه اطلاعات کلی و لازم را در اختیار خواننده می گذارد.
  •       شرح ضرورت- تشریح ضرورت انجام پروژه و تاثیرات آن در کسب و کار
  •       تشریح پروژه-  تشریح چگونگی اجرا و ارزیابی پروژه
  •       اطلاعاتی در مورد سازمان
  •       برنامه زمانی پروژه
  •       بودجه
  •       نتایج پروژه

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

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

از RFP زمانی استفاده می شود که:

1-      بایستی برای ارزیابی و انتخاب یک خدمات دهنده، فرآیندی کارشناسی، منصفانه و رقابتی صورت گیرد.

2-      برای به انجام رساندن نیازهایی معین و جدید در سازمان نیاز به پاسخ هایی متناسب با شرایط زمانی باشد نه راه حل های آماده و در دسترس

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

تهیه RFP چه مزیت هایی دارد؟

1-      شناخت نیازهای واقعی سازمان و یا بخشی که قرار است پروژه ای در آن انجام شود.

2-      جمع آوری اطلاعات دقیق بر اساس مشکلات واقعی و نیازهای کاربران

3-      دستیابی به تخمین درستی از هزینه و زمان مورد نیاز برای پروژه

4-      امکان مقایسه شرکت های مختلف ارائه دهنده خدمات مشابه

5-      کمک به برنامه ریزی و تصمیم گیری دقیق و آگاهانه

6-      کاهش شکایت های احتمالی مجریان و کارفرمایان

7-      کمک به تنظیم دقیق قرداد

8-      فراهم شدن امکان دریافت پیشنهاد های تکمیلی و راه حلهای جدید برای اجرای بهتر پروژه

9-      افزایش توان مدیر پروژه

دانلود کامل مقاله:

دیدن لینک ها برای شما امکان پذیر نیست. لطفا ثبت نام کنید یا وارد حساب خود شوید تا بتوانید لینک ها را ببینید.

منبع نوشتار:

دیدن لینک ها برای شما امکان پذیر نیست. لطفا ثبت نام کنید یا وارد حساب خود شوید تا بتوانید لینک ها را ببینید.

]]> <![CDATA[سوالات امتحان پایان ترم مدیریت توسعه نرم افزار - دی ماه ۹۰]]> https://forums.svus.ir/Thread-%D8%B3%D9%88%D8%A7%D9%84%D8%A7%D8%AA-%D8%A7%D9%85%D8%AA%D8%AD%D8%A7%D9%86-%D9%BE%D8%A7%DB%8C%D8%A7%D9%86-%D8%AA%D8%B1%D9%85-%D9%85%D8%AF%DB%8C%D8%B1%DB%8C%D8%AA-%D8%AA%D9%88%D8%B3%D8%B9%D9%87-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-%D8%AF%DB%8C-%D9%85%D8%A7%D9%87-%DB%B9%DB%B0 Tue, 17 Jan 2012 18:09:32 +0000 Armin]]> https://forums.svus.ir/Thread-%D8%B3%D9%88%D8%A7%D9%84%D8%A7%D8%AA-%D8%A7%D9%85%D8%AA%D8%AD%D8%A7%D9%86-%D9%BE%D8%A7%DB%8C%D8%A7%D9%86-%D8%AA%D8%B1%D9%85-%D9%85%D8%AF%DB%8C%D8%B1%DB%8C%D8%AA-%D8%AA%D9%88%D8%B3%D8%B9%D9%87-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-%D8%AF%DB%8C-%D9%85%D8%A7%D9%87-%DB%B9%DB%B0 سوالات کامل یادم نیست. ممکنه به مرورتکمیل بشه.
۱- عوامل قابل بررسی در مدیریت ریسک را نام ببرید.
۲- استراتژیهای برخورد با ریسک را نام ببرید و یکی را توضیح دهید.
۳- RFP چیست چه کسی آن را تهیه میکند و در تهیه آن چه تخصصهایی مورد نیاز است؟
۴-

۵-
۶- مدییت پیکربندی چیست؟
۷- بخشهای مدیریت پیکربندی را نام ببرید.
۸- مراحلی که تا پیش از عقد قرارداد در پروژه وجود دارد چیست؟
۹-
۱۰- ]]> سوالات کامل یادم نیست. ممکنه به مرورتکمیل بشه.
۱- عوامل قابل بررسی در مدیریت ریسک را نام ببرید.
۲- استراتژیهای برخورد با ریسک را نام ببرید و یکی را توضیح دهید.
۳- RFP چیست چه کسی آن را تهیه میکند و در تهیه آن چه تخصصهایی مورد نیاز است؟
۴-

۵-
۶- مدییت پیکربندی چیست؟
۷- بخشهای مدیریت پیکربندی را نام ببرید.
۸- مراحلی که تا پیش از عقد قرارداد در پروژه وجود دارد چیست؟
۹-
۱۰- ]]> <![CDATA[اسلایدهای مدیریت پیکربندی و نیروی انسانی مناسب برای چاپ]]> https://forums.svus.ir/Thread-%D8%A7%D8%B3%D9%84%D8%A7%DB%8C%D8%AF%D9%87%D8%A7%DB%8C-%D9%85%D8%AF%DB%8C%D8%B1%DB%8C%D8%AA-%D9%BE%DB%8C%DA%A9%D8%B1%D8%A8%D9%86%D8%AF%DB%8C-%D9%88-%D9%86%DB%8C%D8%B1%D9%88%DB%8C-%D8%A7%D9%86%D8%B3%D8%A7%D9%86%DB%8C-%D9%85%D9%86%D8%A7%D8%B3%D8%A8-%D8%A8%D8%B1%D8%A7%DB%8C-%DA%86%D8%A7%D9%BE Sat, 14 Jan 2012 06:22:11 +0000 masoud]]> https://forums.svus.ir/Thread-%D8%A7%D8%B3%D9%84%D8%A7%DB%8C%D8%AF%D9%87%D8%A7%DB%8C-%D9%85%D8%AF%DB%8C%D8%B1%DB%8C%D8%AA-%D9%BE%DB%8C%DA%A9%D8%B1%D8%A8%D9%86%D8%AF%DB%8C-%D9%88-%D9%86%DB%8C%D8%B1%D9%88%DB%8C-%D8%A7%D9%86%D8%B3%D8%A7%D9%86%DB%8C-%D9%85%D9%86%D8%A7%D8%B3%D8%A8-%D8%A8%D8%B1%D8%A7%DB%8C-%DA%86%D8%A7%D9%BE فایل های پاورپوینت فصل 7 و مدیریت پیکربندی رو به صورت سند ورد و مناسب برای چاپ آماده و خدمتتون اررسال کردم .موفق باشید.
.docx   mtn.docx (اندازه 257.08 KB / تعداد دانلود: 191) -->
mtn.docx
دفعات دانلود حجم فایل نوع فایل
191 257.08 KB .docx
]]> فایل های پاورپوینت فصل 7 و مدیریت پیکربندی رو به صورت سند ورد و مناسب برای چاپ آماده و خدمتتون اررسال کردم .موفق باشید.
.docx   mtn.docx (اندازه 257.08 KB / تعداد دانلود: 191) -->
mtn.docx
دفعات دانلود حجم فایل نوع فایل
191 257.08 KB .docx
]]> <![CDATA[تمرين]]> https://forums.svus.ir/Thread-%D8%AA%D9%85%D8%B1%D9%8A%D9%86 Fri, 02 Dec 2011 18:01:03 +0000 siz1389]]> https://forums.svus.ir/Thread-%D8%AA%D9%85%D8%B1%D9%8A%D9%86 کسي ميتونه کمک کنه؟]]> کسي ميتونه کمک کنه؟]]> <![CDATA[معرفی مدل Extreme Programming در تولید نرم افزار]]> https://forums.svus.ir/Thread-%D9%85%D8%B9%D8%B1%D9%81%DB%8C-%D9%85%D8%AF%D9%84-Extreme-Programming-%D8%AF%D8%B1-%D8%AA%D9%88%D9%84%DB%8C%D8%AF-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1 Mon, 14 Nov 2011 20:02:34 +0000 Armin]]> https://forums.svus.ir/Thread-%D9%85%D8%B9%D8%B1%D9%81%DB%8C-%D9%85%D8%AF%D9%84-Extreme-Programming-%D8%AF%D8%B1-%D8%AA%D9%88%D9%84%DB%8C%D8%AF-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1 Extreme.Programming


XP مخفف Extreme Programming یا برنامه نویسی به روش سریع است. در اوایل دهه نود Kent Beck در این فکر بود که روشی بهتر برای طراحی نرم افزار پیدا کند که سر انجام در سال 1966 به کمک همکارش Ward Cunningham در شروع پروژه ای به نام Daimler Chrysler به مفهومی رسید که به نتیجه آن Extreme Programming شد XP. شامل مجموعه از ارزشها، اصول و روشهای مرتبط به هم است که وقتی آن ها را اجرا و رعایت کنیم، روش XP را انجام داده ایم.


مراحل تولید نرم افزار در متدولوژی


1- مقداردهی اولیه: پروژه این مرحله که معمولا توسط یک نفر از اعضاء طراح سیستم، در محل کار کاربر انجام می گیرد و شامل اهداف زیر می باشد(انجام این مرحله غالبا برای کاربر هزینه ای نخواهد داشت):

بدست آوردن دید کلی از پروژه

تعیین بهترین فناوری پیاده سازی

تعیین و معرفی بهترین ترم افزارها بعنوان ابزار پیاده سازی

تشریح متدولوژی پیاده سازی برای کاربر

ارائه مستندات و سوابق کاری و شرایط شرکت برای آشنایی و توجیه هر چه بیشتر کاربر جهت عقد قرارداد

2- تعیین اولویت ها: این اولین قدم در هر پروژه نرم افزاری می باشد. هنگامی که یک قرارداد امضاء گردیده است، اولویت های آن نیز بصورت کلی مشخص گردیده است. برای تعیین دقیق اولویت ها باید از بالاترین سطح شروع کرد و به سمت سطوح سطوح پایین حرکت کرد. این بدان معناست که مشخص نماییم چه قسمتهایی برای کاربر بترتیب مهم می باشد.

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

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

چه عملیات و توابعی باید انجام گیرند.

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

هر طرح نسخه میانی بعنوان یک پیشنهاد باید به تایید کاربر برسد

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

6- طرح نسخ جزئی: طرح نسخه جزئی یک توصیف تکنیکی از طرح نسخه میانی است که به فعالیتهای برنامه نویس یک تا سه روزه شکسته شده است. این فعالیت ها به دو بخش آزمون و پیاده سازی تقسیم می شوند. بخاطر داشته باشیدکه طرح نسخه میانی یک سری از نیازهای عملیاتی هستند که کاربر و اعضاء تیم پروژه بر روی آن بتوافق رسیده اند و در یک دوره زمانی یک تا سه هفته ای قابل پیاده سازی می باشد.

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

8- پیاده سازی نسخه جزئی: پیاده سازی نسخه جزئی عبارت است از پیاده سازی فرم ها، توابع، اشیاء روالهای ذخیره شده که باید در یک دوره یک تا سه روزه پیاده سازی گردند. هنگامیکه یک فعالیت تایید گردد، تستهای آنها نوشته شده و پیاده سازی آنها آغاز می گردند. تمام عملیات در انتهای پیاده سازی هر نسخه جزئی مرور می گردد. همانطور که قبلا گفته شددر این روش کد نویسی با روش برنامه نویسی زوجی (Pair Programming) انجام می پذیرد.

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

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

11- انتشار نسخه نهایی: هنگامیکه هر و (کاربر و تیم پروژه) از نسخه نهایی رضایت داشتند، آن را بصورت یک محصول نهایی ارائه خواهند نمود. در غیر اینصورت دوباره با تعیین نیازها یک نسخه جدید ایجاد شده و دوباره مرپورد آزمون قرار خواهد گرفت.

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

13- پشتیبانی: یکی از نگرانی های بجای کاربران همیشه مسئله پشتیبانی می باشد. متدولوژی XPDM SSW با طرح سطوح مختلف پشتیبانی برای کاربران مختلف ایم مسئله مهم را در نظر می گیرد. بنابراین با ارائه یک طرح در زمینه روند و چگونگی چشتیابنی نیلزهای کاربران در این زمینه برطرف خواهد گردید.

14- پیاده سازی بیشتر:با توچه به اینکه نیازها (خصوصا نیازهای تجاری) بطور مداوم در حال تغییر و تحول میباشد، بنابراین احتیاج است که سیستم همواره در این حال گسترش و سازگاری با تغییرات باشد. با توجه به قابلیت انعطاف و پویایی متدولوژی XP این عمل با انجام مستمر مراحل آن بسادگی انجام پذیر خواهد بود.]]> Extreme.Programming


XP مخفف Extreme Programming یا برنامه نویسی به روش سریع است. در اوایل دهه نود Kent Beck در این فکر بود که روشی بهتر برای طراحی نرم افزار پیدا کند که سر انجام در سال 1966 به کمک همکارش Ward Cunningham در شروع پروژه ای به نام Daimler Chrysler به مفهومی رسید که به نتیجه آن Extreme Programming شد XP. شامل مجموعه از ارزشها، اصول و روشهای مرتبط به هم است که وقتی آن ها را اجرا و رعایت کنیم، روش XP را انجام داده ایم.


مراحل تولید نرم افزار در متدولوژی


1- مقداردهی اولیه: پروژه این مرحله که معمولا توسط یک نفر از اعضاء طراح سیستم، در محل کار کاربر انجام می گیرد و شامل اهداف زیر می باشد(انجام این مرحله غالبا برای کاربر هزینه ای نخواهد داشت):

بدست آوردن دید کلی از پروژه

تعیین بهترین فناوری پیاده سازی

تعیین و معرفی بهترین ترم افزارها بعنوان ابزار پیاده سازی

تشریح متدولوژی پیاده سازی برای کاربر

ارائه مستندات و سوابق کاری و شرایط شرکت برای آشنایی و توجیه هر چه بیشتر کاربر جهت عقد قرارداد

2- تعیین اولویت ها: این اولین قدم در هر پروژه نرم افزاری می باشد. هنگامی که یک قرارداد امضاء گردیده است، اولویت های آن نیز بصورت کلی مشخص گردیده است. برای تعیین دقیق اولویت ها باید از بالاترین سطح شروع کرد و به سمت سطوح سطوح پایین حرکت کرد. این بدان معناست که مشخص نماییم چه قسمتهایی برای کاربر بترتیب مهم می باشد.

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

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

چه عملیات و توابعی باید انجام گیرند.

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

هر طرح نسخه میانی بعنوان یک پیشنهاد باید به تایید کاربر برسد

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

6- طرح نسخ جزئی: طرح نسخه جزئی یک توصیف تکنیکی از طرح نسخه میانی است که به فعالیتهای برنامه نویس یک تا سه روزه شکسته شده است. این فعالیت ها به دو بخش آزمون و پیاده سازی تقسیم می شوند. بخاطر داشته باشیدکه طرح نسخه میانی یک سری از نیازهای عملیاتی هستند که کاربر و اعضاء تیم پروژه بر روی آن بتوافق رسیده اند و در یک دوره زمانی یک تا سه هفته ای قابل پیاده سازی می باشد.

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

8- پیاده سازی نسخه جزئی: پیاده سازی نسخه جزئی عبارت است از پیاده سازی فرم ها، توابع، اشیاء روالهای ذخیره شده که باید در یک دوره یک تا سه روزه پیاده سازی گردند. هنگامیکه یک فعالیت تایید گردد، تستهای آنها نوشته شده و پیاده سازی آنها آغاز می گردند. تمام عملیات در انتهای پیاده سازی هر نسخه جزئی مرور می گردد. همانطور که قبلا گفته شددر این روش کد نویسی با روش برنامه نویسی زوجی (Pair Programming) انجام می پذیرد.

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

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

11- انتشار نسخه نهایی: هنگامیکه هر و (کاربر و تیم پروژه) از نسخه نهایی رضایت داشتند، آن را بصورت یک محصول نهایی ارائه خواهند نمود. در غیر اینصورت دوباره با تعیین نیازها یک نسخه جدید ایجاد شده و دوباره مرپورد آزمون قرار خواهد گرفت.

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

13- پشتیبانی: یکی از نگرانی های بجای کاربران همیشه مسئله پشتیبانی می باشد. متدولوژی XPDM SSW با طرح سطوح مختلف پشتیبانی برای کاربران مختلف ایم مسئله مهم را در نظر می گیرد. بنابراین با ارائه یک طرح در زمینه روند و چگونگی چشتیابنی نیلزهای کاربران در این زمینه برطرف خواهد گردید.

14- پیاده سازی بیشتر:با توچه به اینکه نیازها (خصوصا نیازهای تجاری) بطور مداوم در حال تغییر و تحول میباشد، بنابراین احتیاج است که سیستم همواره در این حال گسترش و سازگاری با تغییرات باشد. با توجه به قابلیت انعطاف و پویایی متدولوژی XP این عمل با انجام مستمر مراحل آن بسادگی انجام پذیر خواهد بود.]]> <![CDATA[معرفی مدل Scrum در توسعه نرم افزار]]> https://forums.svus.ir/Thread-%D9%85%D8%B9%D8%B1%D9%81%DB%8C-%D9%85%D8%AF%D9%84-Scrum-%D8%AF%D8%B1-%D8%AA%D9%88%D8%B3%D8%B9%D9%87-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1 Mon, 14 Nov 2011 18:44:25 +0000 Armin]]> https://forums.svus.ir/Thread-%D9%85%D8%B9%D8%B1%D9%81%DB%8C-%D9%85%D8%AF%D9%84-Scrum-%D8%AF%D8%B1-%D8%AA%D9%88%D8%B3%D8%B9%D9%87-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1 روش scrum
در روش‌هاي قديمي و معمول ساخت نرم‌افزار، طراحان نرم‌افزار معمولاً ابتدا فرض مي‌كنند كه تمامي نيازهاي كاربران سيستم را درك كرده‌اند. اما هميشه نيازهاي كاربران سيستم در ابتدا مشخص نيست و كاربران ممكن است در همان مراحل ابتدايي، نيازهاي خود را تغيير دهند و اين چيزي است كه برنامه‌نويسان و طراحان سيستم هميشه از آن شكايت مي‌كنند و به دنبال راه‌حلي براي رفع اين موضوع مي‌گردند. به‌عنوان مثال مدل قديمي آبشاري (waterfall) را در نظر بگيريد.
اين مدل حاوي مشكلات فراواني است كه به صورت مستقيم به غيرقابل ‌انعطاف‌بودن اين مدل ارتباط دارد. اين مدل مانند يك جاده يك طرفه مي‌باشد كه وقتي اتومبيل در آن حركت مي‌كند، نمي‌تواند مسير خود را تغيير دهد و در جهت ديگري حركت كند. در ابتداي كار كاربر سيستم ممكن است نظراتي در مورد سيستم داشته باشد ولي نمي‌تواند ببيند كه سيستم چگونه كار خواهد كرد و در نتيجه ممكن است وقتي كه سيستم آماده شد، از ساختار و كارايي آن راضي نباشد و تقاضاي تغيير در سيستم را بنمايد. در نتيجه اگر بتوانيم كاربر را از ابتدا در جريان ساخت نرم‌افزار قرار دهيم، ممكن است كه اين مشكل حل شود؛ زيرا مي‌تواند نظرات خود را در طول مدت ساخت و قبل از اتمام كار اعلام كنند و در نتيجه از نرم‌افزار تهيه شده راضي باشد.
امروزه يكي از روش‌هاي توليد نرم‌افزار كه به خصوص براي پروژه‌هاي نرم‌افزاري كوچك مورد استفاده قرار مي‌گيرد و توسط بسياري از اساتيد و صاحب‌نظران مورد تأييد قرار گرفته است، روش SCRUM است. با استفاده از اين روش كه روشي به اصطلاح iterative ( تكراري يا چرخشي ) مي‌باشد، مي‌توان نرم‌افزارهاي كوچك را با كيفيت بالا تهيه نمود. در اين روش كه به روش هوشمند يا Agile نيز مشهور است، مديريت قوي توليد نرم‌افزار وجود دارد كه به برنامه‌نويسان اجازه مي‌دهد با استفاده از آن در پروژه‌ها به سرعت نرم‌افزار موردنظر را تهيه نمايند. اسم Scrum در حقيقت از بازي راگبي گرفته شده است (در بازي راگبي Scrum تيمي متشكل از هشت نفر است كه با همكاري بسيار نزديك با يكديگر بازي مي‌كنند).
در اين روش هر عضو از گروه موظف به درك وظيفه خود در پروژه است و بايد يك هدف مشخص را در تمامي مراحل عملياتي يا فازهاي اجرايي دنبال كند. لازم به ذكر است كه در Scrum هر فاز عملياتي سيستم به Sprint مشهور است.

روش Scrum همانند پروسه‌هاي داراي مرحله برنامه‌ريزي مقدماتي يا Initial Planning است. در اين فاز اعضاي تيم بايد يك نقشه مقدماتي و يك معماري سيستم قابل تغيير به وجود آورند. بعد از اين فاز يك سري از Sprintها به صورت مرتب و جزء جزء نرم‌افزار مورد نظر را به وجود مي‌آورند. انجام دادن هر Sprint ممكن است از يك تا چهار هفته به طول بينجامد و مجموع اين Sprintها نرم‌افزار كاملي را به‌وجود مي آورند.
فهرست تكاليف در هر Sprint به Backlog مشهور است كه تكاليف تيم عملياتي در هر Sprint را مشخص مي‌كند. اين Backlog در هر Sprint بروز مي‌شود و هر تكليف براساس اهميتي كه دارد در فهرست تكاليف تعيين اولويت مي‌گردد. هر فرد در گروه يك كار يا تكليف خاص از اين فهرست را به عهده مي‌گيرد و موظف مي‌شود تا شروع Sprint بعدي آن را به اتمام برساند. وقتي كه يك Sprint شروع شد، ديگر انجام هيچ تغييري در تكاليف امكان ندارد و حتي درخواست‌كننده نرم‌افزار نيز حق تغيير يا درخواست نياز ديگري در نرم‌افزار را نخواهد داشت.
البته درخواست‌كننده مي‌تواند از قسمتي از نرم‌افزار كه بايد در هر مرحله توليد شود بكاهد، اما نمي‌تواند تاريخ تحويل آن قسمت را تغييردهد. شايد بتوان گفت كه اين كار باعث ايجاد نظم در گروه مي‌شود و تاريخ تحويل نرم‌افزار به تعويق نخواهد افتاد. علاوه بر اين، در طول هر Sprint گروه موظف است روزانه جلساتي جهت بررسي روند پيشرفت و قابليت‌هاي نرم‌افزار داشته باشد كه اين نيز به هماهنگي بيشتر گروه كمك خواهد كرد. در اين جلسات كه معمولاً به صورت روزانه است، سه گروه مي‌توانند شركت كنند: گروه تهيه‌كننده نرم‌افزار، مديريت، و درخواست‌كنندگان نرم‌افزار.


در طول اين جلسات مسئول جلسه كه اغلب مدير پروژه است، از تمامي اعضاي تيم سه سؤال مي پرسد:
1- مسئوليت شما (تكاليف) از جلسه قبلي تاكنون چه بوده است و آيا توانسته‌ايد اين تكاليف را به اتمام برسانيد؟
2- در طول اين دوره به چه مشكلاتي برخورده‌ايد؟
3- بر طبق فهرست وظايف، مسئوليت شما از حالا تا جلسه بعدي چه خواهد بود؟
مدير Scrum در حقيقت مسئوليت شناسايي تكاليف محوله به اعضا، بررسي روند تكميلي ساخت نرم‌افزار، بررسي قابليت‌هاي اعضاي گروه و فعاليت در راستاي كم كردن ريسك در پروژه را داراست.
اما چه تفاوتي بين Scrum و ديگر روش‌هاي توليد نرم‌افزار وجود دارد؟ در جواب اين سؤال بايد يادآورشد كه در Scrum هر مرحله يا Sprint قسمتي از نرم‌افزار را آماده مي كند. در اين روش مي توان پيشرفت در توليد نرم‌افزار را در هر مرحله به خوبي احساس نمود. علاوه بر اين، گروه مي‌تواند پس از اتمام هر Sprint تصميم‌گيري‌كند كه آيا مي خواهد به كار روي پروژه ادامه دهد يا انجام پروژه مذكور غيرممكن است. روش Scrum وقتي مي‌تواند بيشتر مفيد باشد كه در ابتداي پروژه نيازهاي كاربران به صورت دقيق مشخص نباشد و يك گروه كوچك مسئول پروژه نرم افزاري باشد.


شايد اين سؤال در ذهن شما به وجود آيد كه چرا Scrum ممكن است براي توليد نرم‌افزارهاي كوچك راه حل خوبي باشد؟ در جواب مي‌توان گفت، از آن جايي كه در تيم‌هاي كوچك، اعضاي گروه بايد از تمامي مسائل پروژه آگاه باشند و در Scrum تمامي مراحل ساخت توسط تمامي اعضاي گروه قابل مشاهده است. لذا اين روش مي‌تواند روش مناسبي باشد.


معايب روش Scrum
مزاياي استفاده از Scrum بسيار است، اما اين روش چند اشكال نيز دارد. از جمله:

1-Scrum روش جديدي است و با روش‌هاي مرسوم تفاوت‌هاي زيادي دارد.
2- برخي از برنامه‌نويسان حرفه‌اي ممكن است از تكاليفي كه مدير Scrum به ايشان مي‌دهد راضي نباشند و بخواهند روش قديمي خود را اجرا نمايند و در صورت اجبار، در روند اجراي پروژه كارشكني كرده و مشكل‌آفريني كنند.
3- از آنجا كه مدير Scrum هم از نظر كيفي و هم كمي بايد پروژه را مديريت كند، Scrum نياز به مديريت بسيار قدرتمند دارد.
4-Scrum را مي‌توان به عنوان روش توليد نرم‌افزار نام برد، اما اين روش بيشتر روش مديريت پروژه هوشمند خوبي است و نمي‌توان آن را به صورت منفرد استفاده نمود و مي‌توان گفت براي حصول اطمينان از موفقيت پروژه‌هاي نرم‌افزاري (به خصوص در سطح كوچك) بايد اين روش را با روش‌هاي ديگر ادغام نمود Scrum را از آن جهت مي‌توان روش خوبي برشمرد كه روشي تحقيقي براساس تخمين، اولويت‌بندي، عملكرد گروه و بررسي نتايج است كه اگر به صورت صحيح مورد استفاده قرار گيرد و قبل از استفاده به صورت كامل آموزش داده شود، مي‌تواند راندمان پروژه‌هاي نرم‌افزاري، به خصوص توليد نرم‌افزارهاي كوچك را به صورت بسيار محسوسي بالا ببرد.
[عکس: Scrum%20Overview%20Diagram.png]
]]> روش scrum
در روش‌هاي قديمي و معمول ساخت نرم‌افزار، طراحان نرم‌افزار معمولاً ابتدا فرض مي‌كنند كه تمامي نيازهاي كاربران سيستم را درك كرده‌اند. اما هميشه نيازهاي كاربران سيستم در ابتدا مشخص نيست و كاربران ممكن است در همان مراحل ابتدايي، نيازهاي خود را تغيير دهند و اين چيزي است كه برنامه‌نويسان و طراحان سيستم هميشه از آن شكايت مي‌كنند و به دنبال راه‌حلي براي رفع اين موضوع مي‌گردند. به‌عنوان مثال مدل قديمي آبشاري (waterfall) را در نظر بگيريد.
اين مدل حاوي مشكلات فراواني است كه به صورت مستقيم به غيرقابل ‌انعطاف‌بودن اين مدل ارتباط دارد. اين مدل مانند يك جاده يك طرفه مي‌باشد كه وقتي اتومبيل در آن حركت مي‌كند، نمي‌تواند مسير خود را تغيير دهد و در جهت ديگري حركت كند. در ابتداي كار كاربر سيستم ممكن است نظراتي در مورد سيستم داشته باشد ولي نمي‌تواند ببيند كه سيستم چگونه كار خواهد كرد و در نتيجه ممكن است وقتي كه سيستم آماده شد، از ساختار و كارايي آن راضي نباشد و تقاضاي تغيير در سيستم را بنمايد. در نتيجه اگر بتوانيم كاربر را از ابتدا در جريان ساخت نرم‌افزار قرار دهيم، ممكن است كه اين مشكل حل شود؛ زيرا مي‌تواند نظرات خود را در طول مدت ساخت و قبل از اتمام كار اعلام كنند و در نتيجه از نرم‌افزار تهيه شده راضي باشد.
امروزه يكي از روش‌هاي توليد نرم‌افزار كه به خصوص براي پروژه‌هاي نرم‌افزاري كوچك مورد استفاده قرار مي‌گيرد و توسط بسياري از اساتيد و صاحب‌نظران مورد تأييد قرار گرفته است، روش SCRUM است. با استفاده از اين روش كه روشي به اصطلاح iterative ( تكراري يا چرخشي ) مي‌باشد، مي‌توان نرم‌افزارهاي كوچك را با كيفيت بالا تهيه نمود. در اين روش كه به روش هوشمند يا Agile نيز مشهور است، مديريت قوي توليد نرم‌افزار وجود دارد كه به برنامه‌نويسان اجازه مي‌دهد با استفاده از آن در پروژه‌ها به سرعت نرم‌افزار موردنظر را تهيه نمايند. اسم Scrum در حقيقت از بازي راگبي گرفته شده است (در بازي راگبي Scrum تيمي متشكل از هشت نفر است كه با همكاري بسيار نزديك با يكديگر بازي مي‌كنند).
در اين روش هر عضو از گروه موظف به درك وظيفه خود در پروژه است و بايد يك هدف مشخص را در تمامي مراحل عملياتي يا فازهاي اجرايي دنبال كند. لازم به ذكر است كه در Scrum هر فاز عملياتي سيستم به Sprint مشهور است.

روش Scrum همانند پروسه‌هاي داراي مرحله برنامه‌ريزي مقدماتي يا Initial Planning است. در اين فاز اعضاي تيم بايد يك نقشه مقدماتي و يك معماري سيستم قابل تغيير به وجود آورند. بعد از اين فاز يك سري از Sprintها به صورت مرتب و جزء جزء نرم‌افزار مورد نظر را به وجود مي‌آورند. انجام دادن هر Sprint ممكن است از يك تا چهار هفته به طول بينجامد و مجموع اين Sprintها نرم‌افزار كاملي را به‌وجود مي آورند.
فهرست تكاليف در هر Sprint به Backlog مشهور است كه تكاليف تيم عملياتي در هر Sprint را مشخص مي‌كند. اين Backlog در هر Sprint بروز مي‌شود و هر تكليف براساس اهميتي كه دارد در فهرست تكاليف تعيين اولويت مي‌گردد. هر فرد در گروه يك كار يا تكليف خاص از اين فهرست را به عهده مي‌گيرد و موظف مي‌شود تا شروع Sprint بعدي آن را به اتمام برساند. وقتي كه يك Sprint شروع شد، ديگر انجام هيچ تغييري در تكاليف امكان ندارد و حتي درخواست‌كننده نرم‌افزار نيز حق تغيير يا درخواست نياز ديگري در نرم‌افزار را نخواهد داشت.
البته درخواست‌كننده مي‌تواند از قسمتي از نرم‌افزار كه بايد در هر مرحله توليد شود بكاهد، اما نمي‌تواند تاريخ تحويل آن قسمت را تغييردهد. شايد بتوان گفت كه اين كار باعث ايجاد نظم در گروه مي‌شود و تاريخ تحويل نرم‌افزار به تعويق نخواهد افتاد. علاوه بر اين، در طول هر Sprint گروه موظف است روزانه جلساتي جهت بررسي روند پيشرفت و قابليت‌هاي نرم‌افزار داشته باشد كه اين نيز به هماهنگي بيشتر گروه كمك خواهد كرد. در اين جلسات كه معمولاً به صورت روزانه است، سه گروه مي‌توانند شركت كنند: گروه تهيه‌كننده نرم‌افزار، مديريت، و درخواست‌كنندگان نرم‌افزار.


در طول اين جلسات مسئول جلسه كه اغلب مدير پروژه است، از تمامي اعضاي تيم سه سؤال مي پرسد:
1- مسئوليت شما (تكاليف) از جلسه قبلي تاكنون چه بوده است و آيا توانسته‌ايد اين تكاليف را به اتمام برسانيد؟
2- در طول اين دوره به چه مشكلاتي برخورده‌ايد؟
3- بر طبق فهرست وظايف، مسئوليت شما از حالا تا جلسه بعدي چه خواهد بود؟
مدير Scrum در حقيقت مسئوليت شناسايي تكاليف محوله به اعضا، بررسي روند تكميلي ساخت نرم‌افزار، بررسي قابليت‌هاي اعضاي گروه و فعاليت در راستاي كم كردن ريسك در پروژه را داراست.
اما چه تفاوتي بين Scrum و ديگر روش‌هاي توليد نرم‌افزار وجود دارد؟ در جواب اين سؤال بايد يادآورشد كه در Scrum هر مرحله يا Sprint قسمتي از نرم‌افزار را آماده مي كند. در اين روش مي توان پيشرفت در توليد نرم‌افزار را در هر مرحله به خوبي احساس نمود. علاوه بر اين، گروه مي‌تواند پس از اتمام هر Sprint تصميم‌گيري‌كند كه آيا مي خواهد به كار روي پروژه ادامه دهد يا انجام پروژه مذكور غيرممكن است. روش Scrum وقتي مي‌تواند بيشتر مفيد باشد كه در ابتداي پروژه نيازهاي كاربران به صورت دقيق مشخص نباشد و يك گروه كوچك مسئول پروژه نرم افزاري باشد.


شايد اين سؤال در ذهن شما به وجود آيد كه چرا Scrum ممكن است براي توليد نرم‌افزارهاي كوچك راه حل خوبي باشد؟ در جواب مي‌توان گفت، از آن جايي كه در تيم‌هاي كوچك، اعضاي گروه بايد از تمامي مسائل پروژه آگاه باشند و در Scrum تمامي مراحل ساخت توسط تمامي اعضاي گروه قابل مشاهده است. لذا اين روش مي‌تواند روش مناسبي باشد.


معايب روش Scrum
مزاياي استفاده از Scrum بسيار است، اما اين روش چند اشكال نيز دارد. از جمله:

1-Scrum روش جديدي است و با روش‌هاي مرسوم تفاوت‌هاي زيادي دارد.
2- برخي از برنامه‌نويسان حرفه‌اي ممكن است از تكاليفي كه مدير Scrum به ايشان مي‌دهد راضي نباشند و بخواهند روش قديمي خود را اجرا نمايند و در صورت اجبار، در روند اجراي پروژه كارشكني كرده و مشكل‌آفريني كنند.
3- از آنجا كه مدير Scrum هم از نظر كيفي و هم كمي بايد پروژه را مديريت كند، Scrum نياز به مديريت بسيار قدرتمند دارد.
4-Scrum را مي‌توان به عنوان روش توليد نرم‌افزار نام برد، اما اين روش بيشتر روش مديريت پروژه هوشمند خوبي است و نمي‌توان آن را به صورت منفرد استفاده نمود و مي‌توان گفت براي حصول اطمينان از موفقيت پروژه‌هاي نرم‌افزاري (به خصوص در سطح كوچك) بايد اين روش را با روش‌هاي ديگر ادغام نمود Scrum را از آن جهت مي‌توان روش خوبي برشمرد كه روشي تحقيقي براساس تخمين، اولويت‌بندي، عملكرد گروه و بررسي نتايج است كه اگر به صورت صحيح مورد استفاده قرار گيرد و قبل از استفاده به صورت كامل آموزش داده شود، مي‌تواند راندمان پروژه‌هاي نرم‌افزاري، به خصوص توليد نرم‌افزارهاي كوچك را به صورت بسيار محسوسي بالا ببرد.
[عکس: Scrum%20Overview%20Diagram.png]
]]> <![CDATA[تمامی اسلایدها و منابع درس مدیریت توسعه نرم افزار]]> https://forums.svus.ir/Thread-%D8%AA%D9%85%D8%A7%D9%85%DB%8C-%D8%A7%D8%B3%D9%84%D8%A7%DB%8C%D8%AF%D9%87%D8%A7-%D9%88-%D9%85%D9%86%D8%A7%D8%A8%D8%B9-%D8%AF%D8%B1%D8%B3-%D9%85%D8%AF%DB%8C%D8%B1%DB%8C%D8%AA-%D8%AA%D9%88%D8%B3%D8%B9%D9%87-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1 Sat, 12 Nov 2011 19:20:11 +0000 Armin]]> https://forums.svus.ir/Thread-%D8%AA%D9%85%D8%A7%D9%85%DB%8C-%D8%A7%D8%B3%D9%84%D8%A7%DB%8C%D8%AF%D9%87%D8%A7-%D9%88-%D9%85%D9%86%D8%A7%D8%A8%D8%B9-%D8%AF%D8%B1%D8%B3-%D9%85%D8%AF%DB%8C%D8%B1%DB%8C%D8%AA-%D8%AA%D9%88%D8%B3%D8%B9%D9%87-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1 - حجم فایلها به دلیل اینکه از نسخه PDF آنها به جای SWF استفاده شده بسیار کمتر شده است.
- سرعت چاپ بالاتر است و پرینتر سریعتر آنها را چاپ میکند.
- حاشیه های سفید زاید حذف شده است تا حداکثر سایز در هنگام پرینت ۴ اسلاید در هر صفحه (۸ اسلاید در هر برگ پشت و رو) امکانپذیر باشد و خوانا بودن مطالب حفظ شود.
- برخی صفحات زاید حذف شده است.
- تمامی اسلایدهای جلسات تا این تاریخ (۵ جلسه اول تا میانترم) در یک فایل جمع آوری شده است.

فایلها عبارتند از:
- فایل شماره ۱: سرفصل مصوب درس به همراه متن تفصیلی و کتابی جلسه اول
- فایل شماره ۲: اسلایدهای جلسه اول تا پنجم مناسب جهت چاپ که میتوانید هنگام چاپ تنظیم کنید در هر صفحه ۴ اسلاید چاپ شود. (در حال حاضر در هر صفحه ۱ اسلاید قرار داده شده تا به صورت سلیقه ای در هنگام چاپ قابل تغییر باشد)
- و کلیه اسناد رسمی مرتبط با فاز ۱ و ۲ و ۳ استاندارد نماتن که تا کنون توسط شورای عالی انفورماتیک کشور منتشر شده است در فایلهای بعدی قرار دارد. دکتر خیامی فقط مستندات فاز ۲ را قرار دادند.

لطفا در صورتی که مشکلی در فایلها مشاهده کردید سریعا اطلاع دهید تا اصلاح شود.

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

رمز کلیه فایلها:

کد:
www.svus.ir

.rar   S1-SDM-Text.rar (اندازه 2.4 MB / تعداد دانلود: 146) -->
S1-SDM-Text.rar
دفعات دانلود حجم فایل نوع فایل
146 2.4 MB .rar

.rar   SDM, S1-S5 (Slides).rar (اندازه 2.15 MB / تعداد دانلود: 164) -->
SDM, S1-S5 (Slides).rar
دفعات دانلود حجم فایل نوع فایل
164 2.15 MB .rar

.rar   Namatan Phase 1.rar (اندازه 1.69 MB / تعداد دانلود: 137) -->
Namatan Phase 1.rar
دفعات دانلود حجم فایل نوع فایل
137 1.69 MB .rar

.rar   Namatan phase 2.rar (اندازه 2.82 MB / تعداد دانلود: 124) -->
Namatan phase 2.rar
دفعات دانلود حجم فایل نوع فایل
124 2.82 MB .rar

.rar   Namatan phase 3.rar (اندازه 1.47 MB / تعداد دانلود: 105) -->
Namatan phase 3.rar
دفعات دانلود حجم فایل نوع فایل
105 1.47 MB .rar

.zip   SDM Fonts (Mitra).zip (اندازه 69.85 KB / تعداد دانلود: 69) -->
SDM Fonts (Mitra).zip
دفعات دانلود حجم فایل نوع فایل
69 69.85 KB .zip

]]> - حجم فایلها به دلیل اینکه از نسخه PDF آنها به جای SWF استفاده شده بسیار کمتر شده است.
- سرعت چاپ بالاتر است و پرینتر سریعتر آنها را چاپ میکند.
- حاشیه های سفید زاید حذف شده است تا حداکثر سایز در هنگام پرینت ۴ اسلاید در هر صفحه (۸ اسلاید در هر برگ پشت و رو) امکانپذیر باشد و خوانا بودن مطالب حفظ شود.
- برخی صفحات زاید حذف شده است.
- تمامی اسلایدهای جلسات تا این تاریخ (۵ جلسه اول تا میانترم) در یک فایل جمع آوری شده است.

فایلها عبارتند از:
- فایل شماره ۱: سرفصل مصوب درس به همراه متن تفصیلی و کتابی جلسه اول
- فایل شماره ۲: اسلایدهای جلسه اول تا پنجم مناسب جهت چاپ که میتوانید هنگام چاپ تنظیم کنید در هر صفحه ۴ اسلاید چاپ شود. (در حال حاضر در هر صفحه ۱ اسلاید قرار داده شده تا به صورت سلیقه ای در هنگام چاپ قابل تغییر باشد)
- و کلیه اسناد رسمی مرتبط با فاز ۱ و ۲ و ۳ استاندارد نماتن که تا کنون توسط شورای عالی انفورماتیک کشور منتشر شده است در فایلهای بعدی قرار دارد. دکتر خیامی فقط مستندات فاز ۲ را قرار دادند.

لطفا در صورتی که مشکلی در فایلها مشاهده کردید سریعا اطلاع دهید تا اصلاح شود.

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

رمز کلیه فایلها:

کد:
www.svus.ir

.rar   S1-SDM-Text.rar (اندازه 2.4 MB / تعداد دانلود: 146) -->
S1-SDM-Text.rar
دفعات دانلود حجم فایل نوع فایل
146 2.4 MB .rar

.rar   SDM, S1-S5 (Slides).rar (اندازه 2.15 MB / تعداد دانلود: 164) -->
SDM, S1-S5 (Slides).rar
دفعات دانلود حجم فایل نوع فایل
164 2.15 MB .rar

.rar   Namatan Phase 1.rar (اندازه 1.69 MB / تعداد دانلود: 137) -->
Namatan Phase 1.rar
دفعات دانلود حجم فایل نوع فایل
137 1.69 MB .rar

.rar   Namatan phase 2.rar (اندازه 2.82 MB / تعداد دانلود: 124) -->
Namatan phase 2.rar
دفعات دانلود حجم فایل نوع فایل
124 2.82 MB .rar

.rar   Namatan phase 3.rar (اندازه 1.47 MB / تعداد دانلود: 105) -->
Namatan phase 3.rar
دفعات دانلود حجم فایل نوع فایل
105 1.47 MB .rar

.zip   SDM Fonts (Mitra).zip (اندازه 69.85 KB / تعداد دانلود: 69) -->
SDM Fonts (Mitra).zip
دفعات دانلود حجم فایل نوع فایل
69 69.85 KB .zip

]]> <![CDATA[سوال]]> https://forums.svus.ir/Thread-%D8%B3%D9%88%D8%A7%D9%84 Thu, 10 Nov 2011 14:23:09 +0000 masoud]]> https://forums.svus.ir/Thread-%D8%B3%D9%88%D8%A7%D9%84 من دوتا سوال دارم:
1- آیا کیفیت فقط مربوط به نیازمندی های غیرعملیاتی نرم افزاره؟(صفحه 2 از جزوه فصل اول سطر 4) یا مربوط به هر دوی نیاز های عملیاتی و غیر عملیاتی ؟(ادامه همین فصل)
2-در مورد این ابزارهای کنترل کیفیت پروژه تو جزوه تحلیل Pareto، نمونه گیری آماری و شش سیگما اومدند.آیا مثلا نمونه گیری آماری هم جزو این ابزارهاست یا روشی در خدمت به ابزارهای دیگه.به نظر میاد اینا از یه سنخ نیستند.
ممنون میشم راهنمایی کنید.
]]> من دوتا سوال دارم:
1- آیا کیفیت فقط مربوط به نیازمندی های غیرعملیاتی نرم افزاره؟(صفحه 2 از جزوه فصل اول سطر 4) یا مربوط به هر دوی نیاز های عملیاتی و غیر عملیاتی ؟(ادامه همین فصل)
2-در مورد این ابزارهای کنترل کیفیت پروژه تو جزوه تحلیل Pareto، نمونه گیری آماری و شش سیگما اومدند.آیا مثلا نمونه گیری آماری هم جزو این ابزارهاست یا روشی در خدمت به ابزارهای دیگه.به نظر میاد اینا از یه سنخ نیستند.
ممنون میشم راهنمایی کنید.
]]> <![CDATA[جزوات چهار جلسه اول درس مدیریت توسعه نرم افزار برای پرینت]]> https://forums.svus.ir/Thread-%D8%AC%D8%B2%D9%88%D8%A7%D8%AA-%DA%86%D9%87%D8%A7%D8%B1-%D8%AC%D9%84%D8%B3%D9%87-%D8%A7%D9%88%D9%84-%D8%AF%D8%B1%D8%B3-%D9%85%D8%AF%DB%8C%D8%B1%DB%8C%D8%AA-%D8%AA%D9%88%D8%B3%D8%B9%D9%87-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-%D8%A8%D8%B1%D8%A7%DB%8C-%D9%BE%D8%B1%DB%8C%D9%86%D8%AA Fri, 04 Nov 2011 08:05:09 +0000 f.marjani]]> https://forums.svus.ir/Thread-%D8%AC%D8%B2%D9%88%D8%A7%D8%AA-%DA%86%D9%87%D8%A7%D8%B1-%D8%AC%D9%84%D8%B3%D9%87-%D8%A7%D9%88%D9%84-%D8%AF%D8%B1%D8%B3-%D9%85%D8%AF%DB%8C%D8%B1%DB%8C%D8%AA-%D8%AA%D9%88%D8%B3%D8%B9%D9%87-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-%D8%A8%D8%B1%D8%A7%DB%8C-%D9%BE%D8%B1%DB%8C%D9%86%D8%AA


جلسه 1 : .pdf   jalase1.pdf (اندازه 1.39 MB / تعداد دانلود: 129) -->
jalase1.pdf
دفعات دانلود حجم فایل نوع فایل
129 1.39 MB .pdf


جلسه 2 : .pdf   jalase2-chapter1-Modiriyate Tosee.pdf (اندازه 1.82 MB / تعداد دانلود: 112) -->
jalase2-chapter1-Modiriyate Tosee.pdf
دفعات دانلود حجم فایل نوع فایل
112 1.82 MB .pdf


جلسه 3 : .pdf   jalase3-chapter2-ModiriyateTosee.pdf (اندازه 1.23 MB / تعداد دانلود: 115) -->
jalase3-chapter2-ModiriyateTosee.pdf
دفعات دانلود حجم فایل نوع فایل
115 1.23 MB .pdf


جلسه 4 : .pdf   jalase4Tosee.pdf (اندازه 2.42 MB / تعداد دانلود: 116) -->
jalase4Tosee.pdf
دفعات دانلود حجم فایل نوع فایل
116 2.42 MB .pdf

]]>


جلسه 1 : .pdf   jalase1.pdf (اندازه 1.39 MB / تعداد دانلود: 129) -->
jalase1.pdf
دفعات دانلود حجم فایل نوع فایل
129 1.39 MB .pdf


جلسه 2 : .pdf   jalase2-chapter1-Modiriyate Tosee.pdf (اندازه 1.82 MB / تعداد دانلود: 112) -->
jalase2-chapter1-Modiriyate Tosee.pdf
دفعات دانلود حجم فایل نوع فایل
112 1.82 MB .pdf


جلسه 3 : .pdf   jalase3-chapter2-ModiriyateTosee.pdf (اندازه 1.23 MB / تعداد دانلود: 115) -->
jalase3-chapter2-ModiriyateTosee.pdf
دفعات دانلود حجم فایل نوع فایل
115 1.23 MB .pdf


جلسه 4 : .pdf   jalase4Tosee.pdf (اندازه 2.42 MB / تعداد دانلود: 116) -->
jalase4Tosee.pdf
دفعات دانلود حجم فایل نوع فایل
116 2.42 MB .pdf

]]> <![CDATA[تمرين سري سوم توسعه نرم افزار]]> https://forums.svus.ir/Thread-%D8%AA%D9%85%D8%B1%D9%8A%D9%86-%D8%B3%D8%B1%D9%8A-%D8%B3%D9%88%D9%85-%D8%AA%D9%88%D8%B3%D8%B9%D9%87-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1 Sun, 30 Oct 2011 07:26:45 +0000 siz1389]]> https://forums.svus.ir/Thread-%D8%AA%D9%85%D8%B1%D9%8A%D9%86-%D8%B3%D8%B1%D9%8A-%D8%B3%D9%88%D9%85-%D8%AA%D9%88%D8%B3%D8%B9%D9%87-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1
يک سوال ديگه:

من اشتباها تمرين سري 1 را با لينک سري 3 فرستادم 17 حالا تمرين سري 3 را چجوري بفرستم 106
]]>
يک سوال ديگه:

من اشتباها تمرين سري 1 را با لينک سري 3 فرستادم 17 حالا تمرين سري 3 را چجوري بفرستم 106
]]> <![CDATA[فایل جلسه چهارم]]> https://forums.svus.ir/Thread-%D9%81%D8%A7%DB%8C%D9%84-%D8%AC%D9%84%D8%B3%D9%87-%DA%86%D9%87%D8%A7%D8%B1%D9%85 Mon, 24 Oct 2011 07:35:44 +0000 mousavian]]> https://forums.svus.ir/Thread-%D9%81%D8%A7%DB%8C%D9%84-%D8%AC%D9%84%D8%B3%D9%87-%DA%86%D9%87%D8%A7%D8%B1%D9%85
فایل جلسه چهارم درس مدیریت توسعه نرم افزار را با فرمت پی دی اف

موفق باشید
ببخشید فایلش یادم رفت


]]>
فایل جلسه چهارم درس مدیریت توسعه نرم افزار را با فرمت پی دی اف

موفق باشید
ببخشید فایلش یادم رفت


]]> <![CDATA[فرمت جواب تمرینات ]]> https://forums.svus.ir/Thread-%D9%81%D8%B1%D9%85%D8%AA-%D8%AC%D9%88%D8%A7%D8%A8-%D8%AA%D9%85%D8%B1%DB%8C%D9%86%D8%A7%D8%AA Sun, 23 Oct 2011 14:38:18 +0000 masoud]]> https://forums.svus.ir/Thread-%D9%81%D8%B1%D9%85%D8%AA-%D8%AC%D9%88%D8%A7%D8%A8-%D8%AA%D9%85%D8%B1%DB%8C%D9%86%D8%A7%D8%AA ممکنه در مورد فرمت تمرینات درس توضیح بفرمایید.پی دی اف باید باشه.چند صفحه باید باشه؟ و...
ممنون
]]> ممکنه در مورد فرمت تمرینات درس توضیح بفرمایید.پی دی اف باید باشه.چند صفحه باید باشه؟ و...
ممنون
]]> <![CDATA[فايل صوتي جلسه دوم كلاس مديريت توسعه نرم افزار ]]> https://forums.svus.ir/Thread-%D9%81%D8%A7%D9%8A%D9%84-%D8%B5%D9%88%D8%AA%D9%8A-%D8%AC%D9%84%D8%B3%D9%87-%D8%AF%D9%88%D9%85-%D9%83%D9%84%D8%A7%D8%B3-%D9%85%D8%AF%D9%8A%D8%B1%D9%8A%D8%AA-%D8%AA%D9%88%D8%B3%D8%B9%D9%87-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1 Wed, 12 Oct 2011 14:30:05 +0000 sheisi]]> https://forums.svus.ir/Thread-%D9%81%D8%A7%D9%8A%D9%84-%D8%B5%D9%88%D8%AA%D9%8A-%D8%AC%D9%84%D8%B3%D9%87-%D8%AF%D9%88%D9%85-%D9%83%D9%84%D8%A7%D8%B3-%D9%85%D8%AF%D9%8A%D8%B1%D9%8A%D8%AA-%D8%AA%D9%88%D8%B3%D8%B9%D9%87-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1
لينك دانلود :

دیدن لینک ها برای شما امکان پذیر نیست. لطفا ثبت نام کنید یا وارد حساب خود شوید تا بتوانید لینک ها را ببینید.


رمز فايل : svus1389
]]>
لينك دانلود :

دیدن لینک ها برای شما امکان پذیر نیست. لطفا ثبت نام کنید یا وارد حساب خود شوید تا بتوانید لینک ها را ببینید.


رمز فايل : svus1389
]]> <![CDATA[فايل صوتي جلسه اول كلاس مديريت توسعه نرم افزار]]> https://forums.svus.ir/Thread-%D9%81%D8%A7%D9%8A%D9%84-%D8%B5%D9%88%D8%AA%D9%8A-%D8%AC%D9%84%D8%B3%D9%87-%D8%A7%D9%88%D9%84-%D9%83%D9%84%D8%A7%D8%B3-%D9%85%D8%AF%D9%8A%D8%B1%D9%8A%D8%AA-%D8%AA%D9%88%D8%B3%D8%B9%D9%87-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1 Tue, 11 Oct 2011 05:01:38 +0000 sheisi]]> https://forums.svus.ir/Thread-%D9%81%D8%A7%D9%8A%D9%84-%D8%B5%D9%88%D8%AA%D9%8A-%D8%AC%D9%84%D8%B3%D9%87-%D8%A7%D9%88%D9%84-%D9%83%D9%84%D8%A7%D8%B3-%D9%85%D8%AF%D9%8A%D8%B1%D9%8A%D8%AA-%D8%AA%D9%88%D8%B3%D8%B9%D9%87-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1
فايل صوتي جلسه اول كلاس مجازي أقاي دكتر خيامي را از لينك زير دانلود كنيد :

دیدن لینک ها برای شما امکان پذیر نیست. لطفا ثبت نام کنید یا وارد حساب خود شوید تا بتوانید لینک ها را ببینید.


رمز فايل : svus1389
]]>
فايل صوتي جلسه اول كلاس مجازي أقاي دكتر خيامي را از لينك زير دانلود كنيد :

دیدن لینک ها برای شما امکان پذیر نیست. لطفا ثبت نام کنید یا وارد حساب خود شوید تا بتوانید لینک ها را ببینید.


رمز فايل : svus1389
]]>