معرفی

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

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

محدوده پروژه

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

• توسعه داشبورد و همچنین پایگاه داده مورد نیاز برای چنین هدفی.

• فهرست کردن الزامات عملکردی که شامل نظارت بر فرآیندها برای انطباق با SLA و تعریف توان عملیاتی است.

• حفظ حقوق دسترسی با سطوح مختلف کنترل برای لایه‌های مختلف مدیریت.

ثبت زمان و سایر عملکردهای اداری بخشی از ابزار نیستند و از این رو خارج از محدوده هستند. محدوده مستقیماً با خروجی نتایج مرتبط است که شامل اجزای front-end و back-end است، همانطور که در بالا بحث شد.

برنامه‌ریزی منابع و زمان‌بندی

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

منابع به دو تیم تقسیم می‌شوند:

1. یک تیم مسئول طراحی و توسعه و تیم دیگر جنبه‌های الزامات و آزمایش را انجام می‌دهد.

2. تیم دوم تخصص عملکردی در ترسیم الزامات و همچنین تبدیل آنها به مشخصات قابل استفاده برای تیم اول را خواهد داشت.

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

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

نمودار شبکه

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

تأثیر بهم خوردن برنامه زمانی

در صورت بروز مشکل در برنامه، فاز نیازمندی‌ها می‌تواند با فاز طراحی و با فعالیت‌های موازی ادغام شود. این امر مستلزم فراتر رفتن از مدل «آبشاری» معمولی SDLC و به جای آن داشتن یک روش چابک است.

تأثیر بارگذاری سطح منابع

دو تیم منابع می‌توانند به جای یکدیگر استفاده شوند، با این شرط که مجموعه مهارت‌های منابع یکسان باشد.

ارزیابی ریسک

طرح مدیریت ریسک برای پروژه شامل موارد زیر به عنوان ریسک‌های بالقوه و برنامه‌های کاهش آنها خواهد بود:

• ریسک منابع: از نظر ریسک اکتساب دانش و فرسایش به دو جزء تقسیم می‌شود. جزء اول با آموزش و اشتراک‌گذاری دانش و جزء دوم با مستندسازی فرآیندها و مدیریت دانش کاهش می‌یابد.

• خزش دامنه: هرگونه تغییر در محدوده باید توسط همه ذینفعان تأیید شود و هزینه‌های آن نیز باید بین آنها تقسیم شود.

• واریانس: هرگونه اختلاف در بودجه به دلیل محدودیت‌های زمانی، هزینه‌ای یا کیفی ("محدودیت سه‌گانه") باید توسط همه ذینفعان مورد بررسی قرار گیرد. این کار باید با گزارش منظم وضعیت و شناسایی مسائل بالقوه‌ای که باید توسط ذینفعان مختلف حل شوند، انجام شود.

• فن آوری: هرگونه تغییر در فناوری، ریسک فوری برای پروژه ایجاد می‌کند و باید اطمینان حاصل شود که فناوری مناسب برای آن انتخاب شده است.

نتیجه

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