Task Tracking System

(PROJECT OVERVIEW )

Детайли на проекта:

Име на проекта:	:	Task Tracking System
Клиент	:	CODIX
Проектен мениджър	:	Марина Тасева +359886545445
Проектен спонсор	:	Евлоги Георгиев +35929732101
Изпълнителен спонсор	:	Жорж Грийнсмит +359888717259
Клиент за контакт	:	Ефтимия Лалова +359896616906

Въведение:

Очакваният продукт при финализиране на този проект е да се създаде средство, чрез което ще се оптимизаира и улесни създаването и проследяването на задачи в жизнения път на проекта.

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

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

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

Обхвата на проекта ще бъде разгледан в стандартните направления :

• 
  Цел и функционалност на продукта
  
• 
  Информацията, която се предоставя на потребителите и ползата от употребата на софтуерното приложение
  

Целта на софтуерното приложение е всеки потребител на системата да бъде в течение на състоянието на задачите и текущите си задължения за даден проект.

• 
  Администратор – управлява достъпа, поддържа данните, създава резервно копие на базата данни
  
• 
  Потребител - управител, функционален мениджър, проектен мениджър – разпределя дейностите, тийм лидер – разпределя задачите, софтуерен архитект, разработчик, аналист, QA
  

Според нивото на достъп на логнатия потребител, системата ще позволява филтриране и проследяване на дейностите и задачите по критерии:

• 
  Име на задачата
  
• 
  Информация за естеството на задачата
  
• 
  Подзадача на дадена задача
  
• 
  Отговорен служител за реализацията и финализирането
  
• 
  Приоритет по важност (нисък, нормален, висок)
  
• 
  Статус (завършена, закъсняваща)
  
• 
  Срок за реализация
  

• 
  Нова добавена задача или възложена подзадача
  

• 
  Идентифицирана промяна в приоритета или информацията за естеството на задачата и нейната крайна цел в глобален мащаб
  
• 
  Изоставаща задача
  
• 
  Наближаващ краен срок
  
• 
  Изтекъл краен срок
  

• 
  Генериране на спиък с лични задачи
  
• 
  Генериране на списък със задачите на даден потребител на системата
  
• 
  Генериране на списък на задачите, които изостват от графика
  
• 
  Генериране на списък с успешно финализирани задачи по конкретна дейност
  
• 
  Генериране на списък със задачи, във формат, подходящ за принтиране
  
• 
  Визуализиране на критичните пътища по дейности
  
• 
  Визуализиране на задачи със скорошна активност - ще се показват всики задачи, които са били скоро обновени
  
• 
  Добавяне на коментари/бележки по задачите
  
• 
  Ъплоуд и даунлоуд на файлове, свързани с конкретна задача
  
  
  

• 
  Обхвата и бюджета на проекта ще бъдат успешно контролирани
  
• 
  Ще се увеличат приходите посредством правилно усвоеното работно време
  
• 
  Ще прекарвате повече време да работите, по-малко да ръководите
  

Подход към проекта:

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

Фиг. 1 Типична фазова разработка на проекта

Основни заинтересовани лица:

Изходни продукти от проекта:

(Deliverables)

Ключови контролни точки:

Допускания/Предпоставки за неуспех:

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

Допусканията са потенциалните точки на неуспех за проекта. С оглед на намаляването на рисковете за проекта тук ще бъдат изброени всички възможни допускания с цел те да бъдат обект на мониторинг и контрол по време на процеса на разработка.

Допускания към ресурсите:

1. 
   Екипът ще бъде на разположение, когато е необходим за работа
   
2. 
   Хардуерните ресурси ще бъдат налице, когато са необходими
   
3. 
   Изискваните средства от клиента ще бъдат налице, когато са необходими
   
4. 
   Голяма част от екипа ще има опит с използавната технология и среда за разработка
   
5. 
   Ще има достъп до експерт и специалисти при нужда по време на разработка
   
6. 
   Под оптимално изработено време се подразбира от всички поне 35 часа продуктивна работа на седмица
   

7. 
   Възникналите проблеми ще бъдат разрешени за кратко време
   
8. 
   Организацията на проекта описана в плана на проекта ще бъде ще бъде коректно приложена
   
9. 
   Системните компоненти ще могат да се интегрират с минимум преработка
   
10. 
    При внедряване минималните системни изисквания ще бъдат покрити
    

• 
  Сървър
  

RAM: 4 GB

Free Hard Disc Space: 1 GB

• 
  Клиент:
  

RAM: 1 GB

Free Hard Disc Space: 20MB

ОS Windows 97/XP/7

11. 
    Изискванията към уменията за работа с компютър на потребителите ще бъдат покрити
    

• 
  Администратор – отлично
  
• 
  Потребители – средно
  

Рискове:

Ключови изисквания към ресурсите:

Ограничения:

Както всеки проект и този се сблъсква с ограниченията налагани му от факторите на средата.

Взаимносвързани проекти:

Тъй като проекта е част от мащабна схема за оптимизиране на работата и оползотворяване на човешките ресурси, за в бъдеще той ще си взаимодейства с предстоящите за разработка средства за успешно прилагане на утвърдените практики в Управлението на проекти.

Очаква се настоящият проект да оказва влияние и да си взаимодейства с планираните за бъдеща разработка проекти.

Критерии за одобрение:

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

План за комуникация:

План за управление на промените:

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

Ключовите цели , които трябва да бъдат постигнати са:

• 
  Установяване на процес за контролиране на промените, дефиниращ метод чрез който предложените промени да бъдат приети или отхвърлени на базата на анализ. Анализа ще установи отражението на промените върху графика, бюджета и обхвата.
  
• 
  Употреба на процеруди, чрез които членовете на екипа и заинтересованите лица да могат да пускат искания за промени, които да бъдат разглеждани от мениджъра на проекта или друго носещо отговорност лице.
  
• 
  Промяната трябва да се дефинира като активност засягаща обхвата, графика, изходните продукти или разходите по проекта.
  
• 
  Да се идентифицират и контролират промени по обхвата или други непланирани дейности
  
• 
  Да се разрешат въпросите или проблемите който могат да възникнат между инвеститорите и екипа относно обхвата или изходните продукти.
  
• 
  Да се извържи мониторинг на прогреса и да се изчисли цената на извършените промени.
  

За да бъдат постигнати по време на проекта гореизброените цели

ще се използват следните вътрешни документи:

• 
  Искане за промени (ИП)
  
• 
  Регистър за промени(РП)
  

Документите са представени в Приложение А и Б.

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

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

• 
  Не се прави промяната, поради липса на необходимост и обосновка
  
• 
  Избира се алтернативен подход, елиминиращ нуждата от промяна
  
• 
  Промяната се прави по стандартната процедура. Промяната се вписва в РП с неоходимата я съпровождаща информация: име на промяната, описание, приоритет, име на инициатора на промяната, дата на поискване и приемане
  

Финансов анализ

Бюджет:

Проектът има свой ясно дефиниран бюджет. Най-общо той описва приходите и разходите, съпътстващи проекта по време на целият жизненият цикъл по изпълнението му. Планираният бюджет е 25,000€.

Разходи:

-Софтуер:

- Visual Studio 2005 Professional Edition: 600€

- Microsoft SQL Server 2005 Workgroup Edition: 3,000€

-Хардуер:

- 2 компютърни конфигурации: 2,000€

- рутер: 100€

- офис обурудване: 500€

- Офис:

- наем за 6 месеца: 1,500€

- интернет достъп за 6 месеца: 200€

- консумативи за 6 месеца: 600€

- Заплащане на труда:

- заплати за 6 месеца: 12,000€

- бизнес срещи: 500€

- ползване услугите на външни консултанти: 500€

Общо:21,500€

Планирани приходи:

- Договор с codix: 40,000€

Общо:40,000€

Възвръщаемост на инвестицията:

ВНИ е количествен критерии, използван за оценяване на ефективността на даден проект или за срявняването му с други проекти, за да се избере най-печелившият. Широката му употреба се обуслава от неговата простота и лекотата за боравенето с получените от него резултати. Формулата за пресмятането му е:

В нашия случай ВНИ = (40 000 – 21 500)/21 500 = 0.86 което е един сравнително добър коефициент за проект от подобен клас.

От друга страна трябва да се вземе в предвид, че авторското право върху продуктът принадлежи на организацията разработчила софтуера и, след незначителни модификации, той може да бъде продаден за подобна стойност и на друга компания, което от своя страна ще повиши значително ВНИ. Примери за това са, ако продуктът бъде продаден на още 1 или 2 клиента ВНИ ще бъде съответно 2.72 и 4.58. Така проектът ще стане изключително печеливш.

Приложение А

Приложение Б

РЕГИСТЪР ЗА ВНАСЯНЕ НА ПРОМЯНА

Приложение В

Използвана терминология

Източници:

1. 
   http://www.projectmanagement.com/pm/process/PMprocessMain.cfm?ID=11506
   
2. 
   http://www.projectperfect.com.au/wp_index.php
   
3. 
   http://www.its.monash.edu.au/staff/projects/project-management/glossary.html
   
4. 
   http://www.mpmm.com/project-management-methodology.php