Въведение

Тази статия разглежда проект за автоматизация на проект за поддръжка в софтуерна компания. Проектът включва автоматизиране на отделни и разнородни процеси в централизиран механизъм за наблюдение чрез инструмент, разработен за тази цел.

Тази статия изброява обхвата и различните аспекти, като планиране на ресурси и график, заедно с мрежовата диаграма и структурата на разбивка на работата.

Обхват на проекта

Обхватът на проекта е да се разработи инструмент за автоматизация за централизиране на процесите на работния поток. Това включва:

• Разработване на таблото за управление, както и на базата данни, необходима за тази цел.

• Изброяване на функционалните изисквания, които включват наблюдение на процесите за съответствие със SLA и дефиниране на пропускателната способност.

• Поддържане на права за достъп с различни нива на контрол за различните нива на управление.

Функциите за отчитане на работното време и други административни функции не са част от инструмента и следователно са извън обхвата му. Обхватът е пряко свързан с резултата от резултатите, които включват компонентите на предния и задния край, както беше обсъдено по-горе.

Планиране на ресурси и график

Проектът включва екип от шестима служители, посветени на проекта, с ръководител на екипа, който да наблюдава екипа за разработка.

Ресурсите ще бъдат разделени на два екипа:

1. Единият екип е отговорен за дизайна и разработката, а другият екип се занимава с изискванията и тестването.

2. Вторият екип ще има функционалната експертиза в определянето на изискванията, както и в превръщането им в използваеми спецификации за първия екип.

Освен това, експертният опит на този екип ще бъде използван за тестване, тъй като те разбират обхвата и функционалните аспекти на същото.

Графикът на проекта ще бъде за период от два месеца. Първите няколко седмици ще бъдат посветени на изискванията на различните заинтересовани страни, а следващият месец ще бъде посветен на действителното проектиране и кодиране. Последните няколко седмици ще бъдат прекарани в тестване и внедряване на инструмента.

Мрежова диаграма

Критичният път е както е посочен по-горе. Тъй като този проект включва директна разработка, критичният път би бил същият като този на фазите на SDLC.

Ефект от срива на графика

В случай на срив на графика, фазата на изискванията може да се обедини с фазата на проектиране с паралелни дейности. Това би включвало излизане отвъд нормалния „водопад“ модел на SDLC и вместо това използване на гъвкава методология.

Ефект от нивото на зареждане на ресурсите

Двата екипа от ресурси могат да се използват взаимозаменяемо, като е необходимо да се изпълни изискването уменията на ресурсите да са еднакви.

Оценка на риска

Планът за управление на риска за проекта ще включва следните елементи, изброени като потенциални рискове, и планове за тяхното смекчаване:

• Риск, свързан с ресурсите: разделен на два компонента по отношение на риска от придобиване на знания и отпадане. Първият компонент се смекчава чрез обучение и споделяне на знания, а вторият компонент се смекчава чрез документиране на процесите и управление на знанията

• Пълзене на обхвата: Всякакви промени в обхвата трябва да бъдат одобрени от всички заинтересовани страни, като разходите се поделят.

• отклонение: Всяко отклонение в бюджета, дължащо се на ограничения във времето, разходите или качеството („тройното ограничение“), трябва да бъде разгледано от всички заинтересовани страни. Това трябва да се постигне чрез редовно отчитане на състоянието и идентифициране на потенциални проблеми, които да бъдат решени от различните заинтересовани страни.

• Технологии: Всяка промяна в технологията би представлявала непосредствен риск за проекта и трябва да се гарантира, че за него е избрана подходяща технология.

Заключение

Тази статия се опитва да изобрази някои аспекти на процесите за управление на проекти, като използва пример с инструмент за автоматизация на проект за поддръжка в софтуерна компания. Макар че това в никакъв случай не е изчерпателно, то разглежда някои от въпросите, изброени в заданието.