Task Tracking System



Дата17.11.2017
Размер360.97 Kb.
Размер360.97 Kb.


Project Overview



Task Tracking System

(PROJECT OVERVIEW )







Изготвили:

Любов Кошкова

Димитър Иванов



Версия на документа:

1.0

Последно обновен на:

12.01.2010



Съдържание:


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

Въведение: 7

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

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

9

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



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

(Deliverables) 11

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

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

Рискове: 15

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

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

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

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

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

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

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

Бюджет: 24

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

Разходи: 24

-Софтуер: 24

- Visual Studio 2005 Professional Edition: 600€ 24

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

-Хардуер: 24

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

- рутер: 100€ 24

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

- Офис: 24

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

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

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

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

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

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

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

Общо:21,500€ 25

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

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

Общо:40,000€ 25

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

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

26

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



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

26


Приложение А 27

ИСКАНЕ ЗА ВНАСЯНЕ НА ПРОМЯНА 28

(ИВП) 28

Име на клиента 28

Име на проекта 28

Фаза на проекта 28

Причина за промяната 28

Описание на промяната 28

Разходи по промяната 28

Одобрена 28

Отхвърлена 28

Чакаща 28

Проектен мениджър 28

Име: 28


Подпис: 28

Дата: 28

Приложение Б 29

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

Приложение В 31

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



Източници: 33



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







Име на проекта:

:

Task Tracking System


Клиент

:

CODIX

Проектен мениджър

:

Марина Тасева

+359886545445
















Проектен спонсор

:

Евлоги Георгиев

+35929732101
















Изпълнителен спонсор

:

Жорж Грийнсмит

+359888717259
















Клиент за контакт

:

Ефтимия Лалова

+359896616906

















Въведение:




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

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

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

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





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

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




  • Цел и функционалност на продукта

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

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


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


  • Администратор – управлява достъпа, поддържа данните, създава резервно копие на базата данни

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

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




  • Име на задачата

  • Информация за естеството на задачата

  • Подзадача на дадена задача

  • Отговорен служител за реализацията и финализирането

  • Приоритет по важност (нисък, нормален, висок)

  • Статус (завършена, закъсняваща)

  • Срок за реализация

Системата предоставя и функции за известяване, под формата на Notifications за:


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

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

  • Изоставаща задача

  • Наближаващ краен срок

  • Изтекъл краен срок


Системата ще позволява възможност за:


  • Генериране на спиък с лични задачи

  • Генериране на списък със задачите на даден потребител на системата

  • Генериране на списък на задачите, които изостват от графика

  • Генериране на списък с успешно финализирани задачи по конкретна дейност

  • Генериране на списък със задачи, във формат, подходящ за принтиране

  • Визуализиране на критичните пътища по дейности

  • Визуализиране на задачи със скорошна активност - ще се показват всики задачи, които са били скоро обновени

  • Добавяне на коментари/бележки по задачите

  • Ъплоуд и даунлоуд на файлове, свързани с конкретна задача



Още ползи от употребата на очакваният продукт на проекта са:


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

    • Ще се увеличат приходите посредством правилно усвоеното работно време

    • Ще прекарвате повече време да работите, по-малко да ръководите






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

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


Разработчиците ще се придържат към традиционният фазов подход, които изисква изпълнението на поредица от стъпки. Този добре познат подход се отличава с пет проектови компонента (4 фази + контрол), които могат да бъдат видяни на фиг 1.

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



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




Stakeholder Name

Вътрешен / Външен

Phone

Email

Любов Георгиева

Кошкова


вътрешен

+359885431114

ljubov.koskova@gmail.com

Димитър

Пламенов


Иванов

вътрешен

+359887273497

dimitar.p.i@gmail.com

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

(Deliverables)





Фаза

Изходен

продукт

Въвеждане

  • Предварителен договор

  • График на проекта




Анализ

  • Спецификация на софтуерните изисквания

  • Стратегия за управление на риска

  • Разчет с необходимите ресурси




Дизайн и планиране

  • План за обучение

  • Документ на дизайна и архитектурата

  • План за имплементация

  • Анализ на критичните приоритети

  • План на тестване




Имплементация

  • Код

  • Премахнати са критичните грешки

Тестване

  • Regression Test  

  • Internal Testing  

  • Unit Testing  

  • Application Testing  

  • Stress Testing

Приключване

  • Документирано е наученото

  • Доклад за проекта

  • Приключен договор



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






Контролна точка

Дата на приключване

Comments

1.

Разработка на график на проекта

14.01.2010

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

2.

Разработка на бизнес изискванията

22.01.2010

Тази дейности описва какво желаят да постигнат клиентите чрез продукта.

3.

Одобряване на Спецификацията на софтуерни изисквания

12.02.2010

Разработена е успешно ССИ, описваща поведението на системата, която ще бъде реализирана. Дейността включва създаването на множество от потребителски случаи, описващи взаимодействието на потребителите със системата

4.

Разработка на план за управление на риска

18.02.2010

Разработва се от проектния мениджър с цел предвиждане на рисковете и създаването на план, смекчаващ отражението им.

5.

Разработка на план за осигуряване на ресурсите

05.03.2010

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

6.


Разработка на документация за дизайна на архитектурата

19.03.2010

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

7.



Генериране на план за тестване

24.03.2010

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

8.

Документиране на планираните задачи по имплементацията

25.03.2010

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

9.

Разработка на сървърната част

15.04.2010

Включва разработката на всички отделни модули в сървърната част.

10.

Разработка на клиентската част

05.05.2010

Включва разработката на всички отделни модули в клиентската част.

11.

Бета тестване

18.05.2010

Версии на софтуера, познати като бета тестване са разпространени в ограничена група от хора, извън екипа програмисти.

12.

Разработка на потребителска документация

28.05.2010

Документите са - technical info, user guide, Helf, FAQ, Installation guide

13.

Внедряване на продукта

03.06.2010

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

14.

Финализиране на проекта

11.06.2010

Приемат се изходните продукти, документира се наученото и приключване на договора.





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

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

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

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


  1. Екипът ще бъде на разположение, когато е необходим за работа

  2. Хардуерните ресурси ще бъдат налице, когато са необходими

  3. Изискваните средства от клиента ще бъдат налице, когато са необходими

  4. Голяма част от екипа ще има опит с използавната технология и среда за разработка

  5. Ще има достъп до експерт и специалисти при нужда по време на разработка

  6. Под оптимално изработено време се подразбира от всички поне 35 часа продуктивна работа на седмица

Общи допускания:

  1. Възникналите проблеми ще бъдат разрешени за кратко време

  2. Организацията на проекта описана в плана на проекта ще бъде ще бъде коректно приложена

  3. Системните компоненти ще могат да се интегрират с минимум преработка

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

  • Сървър

CPU: 2 GHz

RAM: 4 GB

Free Hard Disc Space: 1 GB


  • Клиент:

CPU: 1.6 GHz

RAM: 1 GB

Free Hard Disc Space: 20MB

ОS Windows 97/XP/7





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

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

  • Потребители – средно

Рискове:






Топ 10 рискове



Влияние на риска

1 = Ниско

2 = Средно

3 = Високо

Възм. за контрол

1 = Високо

2 = Средно

3 = Ниско

Вероятност да се случи

( 1–10,

9 =мн. високо)

Изисквания за справяне с проблема

Отговорни лица за справянето с проблема

Критерии за успеваемост

( 1–10,

9 =мн. високо)

Предложения за действия за управление на риска

Най-ключовата част от персонала ще бъде на разположение в ограничено време

3

2

5

Откриване и запознаване със спецификата на проблема

Познания в сферата на чов. психология



Човешки ресурси

Проектен мениджър



9

Изготвяне на работен график и мотивационна програма за готовност на екипа по всяко време

Компютърните ресурси няма да бъдат на разположение непрекъснато

3

1

3

Финансови средства

Управителя

CEO


6

Осигуряване на оборудвано помещение 24 часа


Средствата от клиента няма да бъдат предоставени на време

3

3

10

Познания в сферата на бизнеса и човешката психология

Управител

Финансов експерт




7

Поддържане на регулярни (редовни и предварително планирани) контакти с клиента

Средата на разработка и технологията са нови, а екипа не е запознат с тях

3

1

2

Наличие на опитни кадри или на външно провеждащи се такива обучения


Тийм лидер

Разработчици



10

Провеждане на обучение под формата на семинари и практики

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

3

3

1

Добре организиран и опитен екип от разработчици

Искане за промяна



Проектен мениджър

Аналист


10

Разглеждане на исканията за промяна Попълване на Регистрите за искания

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

3

1

8

Изграждане на по-добри канали за комуникация

Всички членове на екипа

9

Създаване на „група от приятели” към някой мобилен оператор

Проекта има несигурен клиент, проектен мениджър, проектен и инвеститор към днешна дата.

3

3

10

Провеждане на презентации и интервюта с други потенциални клиенти

Проектен мениджър Аналисти


5

Реклама и представяне на възможностите и предимствата от употребата на продукта

Обхвата на проекта е възможно да не е точен

3

2

4

Опит

Комуникативни умения



Проектен мениджър

Аналисти


9

Предефиниране на функционалността и изходните продукти

Проекта зависи от получаването на информация от други външни източници и нейната достоверност

3

2

4

Необходимата степен на компетентност

Повишено внимание



Всички членове на екипа

4

Проверка на достоверността на получаваната информация

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




Основни проектни дейностти

Изискванa

Технология/

Средства

Изисквани Умения/Опит



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

-

Аналитично мислене, познания в областта на бизнеса и търговията, комуникативни умения

Изготвяне на график за изпълнението на проекта


MS Project

Опит в изпълнението на предишни проекти

Разработка на функционалните и нефункционалните изисквания

Z-notation

Последователно аналитично мислене

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

Z-notation

Опит в изпълнението на предишни проекти, последователно аналитично мислене

Изготвяне на план за управлението на риска


-

-

Изготвяне на план за правилното разпределение на ресурсите

-

-

Проектиране на софтуерната архитектура

Java, C#,SQL

Познания в сферата на софтуерните архитектури, ООП, DP, Z-notation, теория на базите данни, шаблони за дизайн

Създаване на модул в сървъра за връзка и комуникация с БД сървъра


JDBC, Java, SQL

ООП, шаблони за дизайн, теория на базите данни

Създаване на таблиците в БД и въвеждане на информация за тестови цели


SQL

теория на базите данни

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


Java, SQL

ООП, шаблони за дизайн

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


Java

ООП, шаблони за дизайн

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


Java

Комуникационни протоколи, ООП, шаблони за дизайн

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


Java

Комуникационни протоколи, ООП, шаблони за дизайн

Създаване на модул в сървъра, реализиращ комуникацията с клиента

Java

Комуникационни протоколи, ООП, шаблони за дизайн, програмиране със сокети

Създаване на функционалностите, нужни за променянето на настройките и поддържането на сървъра


JDBC, Java, SQL

ООП, шаблони за дизайн, теория на базите данни

Сглобяване на  сървъра и превръщането му в многонишково приложение

JDBC, Java, SQL

ООП, шаблони за дизайн, теория на базите данни, многонишково програмиране

Създаване на модул в клиентската част реализиращ комуникацията със сървъра

C#

Комуникационни протоколи, ООП, шаблони за дизайн, програмиране със сокети

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

C#

Комуникационни протоколи, ООП, шаблони за дизайн

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

C#

Комуникационни протоколи, ООП, шаблони за дизайн

Разработка на графичен потребителски интерфейс GUI

C#

ООП, шаблони за дизайн, създаване на графичен интерфейс

Провеждане на предвидените тестове за осигуряване на качеството

Bugzilla, C#

Познания по blackbox и whitebox testing, ООП

Внедряване на системата и повеждане на обучение

     

     

Документиране на новите познания











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

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


Основните ограничения на проекта, произлизат от лимитирания човешки ресурс, с които разполагаме. Този факт ще даде своето отражение в графика на проекта.
Тъй като отговорностите и задълженията ще бъдат равномерно разпределени, времето ще бъде възможно най-оптимизирано, но въпреки всичко то ще бъде прекалено дълго за разработката на проект от такъв тип и мащаб.
Това би довело до усложнения в преговорите с клиента, понеже всеки клиент иска приложението му да бъде разработено възможно най-бързо, най-качествено и на най-ниска цена. Все пак екипа ще трябва да се опита да се впише в най-реалистичния за разработка график, съобразявйки се с клиента, разбира се. От своя страна, това би могло да даде негативни отражения върху качеството.
В идеалния случай тези проблеми биха могли да се избегнат с наемането на външна фирма, за провеждането на автоматизирани тестове. Наемането на такава фирма от своя страна е обвързано с ограничения бюджет от 25000 евро.
Средствата трябва да стигнат за Microsoft SQL 2005, MS Visual Studio, заплати, осигуряване на хардуера, външни консултанти, специалисти и експерти.
Средствата няма да стигнат за тийм билдинг и обучения, което ще наложи разработката на продукта с позната и изпитана технология или ще наложи на екипа да провежда самостоятелно обучение посредством безплатни презентации, туториъли и други достъпни средства в интернет.
Целта на тази стратегия е чрез минимизиране на разходите да се впишем в ограниченият бюджет.



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



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

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

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

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


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

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







Вид комуникация

Участие на възможните заинтересованите лица

Кога ще се осъществиява комуникацията? / Честота на комуникацията

Вътрешна/ Външна

комуникация

e-mail/voice mail

  • Мениджър на проекта

  • Тийм лидер

  • Разработчици

  • Клиент

  • Спонсори на проекта




Ежедневно

Вътрешна и външна

Презентация

  • Аналист

  • Клиент

  • Изпълнителен спонсор

Когато е необходима

Външна

Уъркшоп

Един път в началото на проекта

Външна

Вербална комуникация

Членове на екипа:

  • Мениджър на проекта

  • Тийм лидер

  • Разработчици

  • QA

  • Експерти и специалисти

Ежедневно

Вътрешна и външна

Срещи

  • Клиент

  • Експерт

  • Бизнес консултант

  • Мениджър на проекта

Всяка седмица (четвъртък 12:00) или на всяка завършена фаза с изходен продукт от контролната точка

Външна

Дискусии


Членове на екипа:

  • Мениджър на проекта

  • Тийм лидер

  • Разработчици

  • QA

Когато е необходимо

Вътрешна


Маркетингови проучвания

  • Маркетингов специалист

  • Мениджър на проекта

  • Аналист




В началото на проекта, по време на планирането


Вътрешна и външна



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

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

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


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

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

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

  • Да се идентифицират и контролират промени по обхвата или други непланирани дейности

  • Да се разрешат въпросите или проблемите който могат да възникнат между инвеститорите и екипа относно обхвата или изходните продукти.

  • Да се извържи мониторинг на прогреса и да се изчисли цената на извършените промени.

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

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


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

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

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

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

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




  • Не се прави промяната, поради липса на необходимост и обосновка

  • Избира се алтернативен подход, елиминиращ нуждата от промяна

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





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



Бюджет:



Проектът има свой ясно дефиниран бюджет. Най-общо той описва приходите и разходите, съпътстващи проекта по време на целият жизненият цикъл по изпълнението му. Планираният бюджет е 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. Така проектът ще стане изключително печеливш.

































Приложение А





ИСКАНЕ ЗА ВНАСЯНЕ НА ПРОМЯНА

(ИВП)



Име на клиента


Име на проекта


Фаза на проекта




Причина за промяната


Описание на промяната


Разходи по промяната




Одобрена

Отхвърлена

Чакаща






Проектен мениджър

Име:


Подпис:


Дата:




Приложение Б



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







ИВП №


ИВП - Име

Описание

Финансово оттажение

Одобрена от

Поискана от

Статус




















































































































Приложение В






Milestone


Deliverable

Acceptance Criteria





Document has been reviewed and approved by:


Note:






Document has been reviewed and approved by:


Note:






Document has been reviewed and approved by:


Note:






Document has been reviewed and approved by:


Note:






Document has been reviewed and approved by:


Note:






Document has been reviewed and approved by:


Note:



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





CEO- Chief executive office
GUI – Graphical user interface
OOP – Object-oriented programming
DP – Design patterns/Шаблони за дизайн
JDBC – Java Database Connectivity, API за Java, който определя как клиента може да се свърже с базата данни
FAQ – Frequently asked questions
Z notation – формален език за спецификация, използван за описване и моделиране на компютърни системи
SRS – Software requirements specification
CC- Creative Common
SQL – Structured Query Language



Източници:







  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





Стр.


Сподели с приятели:


©zdrasti.info 2017
отнасят до администрацията

    Начална страница