به‌طور کلی، توصیه می‌شود که در پایان هر پروژه، زمانی را به تحلیل و مستندسازی آنچه گذشت، دستاوردها، نقاط ضعف و قوت، راه‌کارها، ریسک‌ها (مخاطرات) و چگونگی تسکین‌شان، و به …
ادامه مطلبآزمونِ پذیرشِ فراورده، آخرین عملِ آزمودن سیستم، پیش از استقرار نهایی سیستم نرمافزاری است. هدف این آزمون، تأیید آمادگی نرم‌افزار برای عملیاتی‌شدن و انجام وظیفه‌مندی‌ها (کارکردها) است. سه استراتژی مرسوم …
ادامه مطلببا وجودی‌که این هدف عمدتاً در شرکت‌هایی که تولیداتشان را وارد بازار می‌نمایند، مصداق دارد، برخی اقدامات مرتبط با این هدف می‌تواند در پروژه‌های که باید فراورده‌ی نرمافزاری برای تعداد …
ادامه مطلبهنگامیکه باید فراورده‌ی نرمافزاری خود را جایگزین یک سیستم موجود نمایید، انتقال نرم و تدریجی سیستمِ جدید، کار بسیار پیچیده‌ای است. داده‌های فعلی سیستم موجود را باید انتقال داد و حتی …
ادامه مطلبدر طی فاز انتقال باید اطمینان یابیم که همه‌ی کاربران، نیروهای عملیاتی، و نیز تیم نگهداری، آموزش‌های لازم و مناسبی را برای بکارگیری سیستم گذرانده باشند. این آموزش‌ها فرصتی نیز برای آزمودنِ …
ادامه مطلباولین نسخه‌ی عملیاتیِ سیستم، یعنی نسخه‌ی بِتا، در انتهای فازِ ساخت، به‌دست آمده است. در طی فازِ انتقال، باید آزمون بِتا را روی این نسخه‌ی عملیاتی انجام شود؛ این آزمون، بازخوردهای بسیاری را از …
ادامه مطلبکلیدیترین هدف فاز ساخت، توسعه‌ی تکرارشونده‌ی یک فراورده‌ی نرمافزاری کامل است به گونه‌ای که فراورده‌ی حاصل آماده‌ی انتقال به محیط کابران باشد. به منظور تحقق این هدف، اقدامات زیر می‌تواند انجام شود: …
ادامه مطلبدر تمام فازهای چرخه‌ی توسعه‌ی نرم‌افزار، در فکر تولید مقرون به‌صرفه‌ی فراورده‌ی نرمافزاری هستیم. اگر تنها در فاز ساخت به این موضوع بیاندیشیم، مسلماً شکست خواهیم خورد و به این هدف دست پیدا …
ادامه مطلبدر طول فازِ استارتاپ، فرایندِ مناسبِ پروژه و جزئیات پراکتیس‌های مورد استفاده‌ی تیم را تعریف و مستند می‌نماییم. در این فاز ابزارهای مورد نیاز، خروجی‌ها و دستاوردهای مطلوب، و ملاحظاتی از …
ادامه مطلبدر طول فاز معماری، عمدتاً با ریسک‌های فنی، ریسک‌های مرتبط با جلبِ توافق روی نیارمندی‌های سیستم، و نیز ریسک‌های مرتبط با راه‌اندازی و آماده‌سازی بستر و محیط تولید روبرو هستیم که باید …
ادامه مطلب