Индивидуална задача 3 - Студија за изводливост

Feasibility study или студија за изводливост во управување на еден проект претставува проценка на практичноста на истиот тој предложен проект. Најчесто студиите за изводливост се во склоп на DSDM методологија каде што се вклучува овој елемент. Имено, DSDM или Dynamic Systems Development Method претставува еден framework (на македонски - конструкција или скелет) кој е изграден околу RAD (Rapid Application Development)* .

*RAD = техника за развој на апликација

Постојат 5 типа на студија на изводливост и тоа:

• Легална изводливост - се извршува за да се провери дали предложениот план или проект соодветствува на на легалните и етички барања
• Економска изводливост - вклучува анализа на приходите за да се прикажи колку добро (или лошо) еден процес ќе биде завршен
• Техничка изводливост - се извршува за да се валидираат и потврдат техничките карактеристики, ресурси и можности и да се претворат идеите во функционални системи
• Операциска изводливост - се извршува за да се разбере добро дали предложен систем/проект/план ги решава проблемите
• Временска (распоредувачка) изводливост - претставува мерка колку е прифатливо времетраењето на проектот

---

За овој потсистем, поради неговата природа, не нарушува никакви легални или етички барања бидејќи системот единствено претставува управување со релациите на корисниците, или попрецизно корисниците на опрема кои ги пријавуваат своите дефекти. Затоа, баш поради таа причина, легалната изводливост се отфрла.

1. Економска изводливост
Во склоп на економската изводливост за овој потсистем ќе се покаже според следната анализа дека не се потребни големи расходи. Од друга страна, бидејќи има постојано дефекти од различна природа, започнувајќи од најредовното одржување на телата на фотоапаратите, до конкретни и специфични проблеми, значи дека ќе има постојано приходи кај сервисерите.

• Од претходни реални искуства, едно редовно одржување изнесува од 1500 - 2000 денари, или ќе го заокружиме на 30 евра, за поголема прегледност и подоцнежен визуелен приказ на приходите.
  
  
• Ticketing system-от е предвидено да биде завршен за околу два цели месеци, за кој е потребен еден web девелопер, со придонеси од 600еу на месечна база во времетраење од 2 месеци
• За успешно да се поправи и заврши еден дефект, просечно е потребно два часа, со што тука се вклучува и одговарањето и затворање на тикетот
• Секој ден од понеделник до сабота работат двајца сервисери по 8 часа (09.00 - 17.00), што значи дека можат заедно двајцата можат да извршат 8 дефекти дневно или 240еу на ден
• Ако сервисерите работат по 24 дена месечно, приходите ќе бидат 1440еу на неделна база или 5760еу на месечна база
• За одржување на базата на податоци и целиот систем потребни се по 50еу на месечна база или 600еу на годишна база
• Плата за сервисерите изнесува по 400еу / сервисер на месечна база или вкупно 800еу за вработени на месечна база

Следната табела ги прикажува сите замислени приходи и расходи во склоп на овој потсистем

месец	јан	фев	мар	апр	мај	јун	јул	авг	сеп	окт	ное	дек
развој	600	600	0	0	0	0	0	0	0	0	0	0
база на податоци	50	50	50	50	50	50	50	50	50	50	50	50
плата за сервисери	800	800	800	800	800	800	800	800	800	800	800	800
кирија за простор	500	500	500	500	500	500	500	500	500	500	500	500
вкупно расходи	1950	1950	1350	1350	1350	1350	1350	1350	1350	1350	1350	1350
приход од дефекти	5760	5760	5760	5760	5760	5760	5760	5760	5760	5760	5760	5760
вкупен придонес по месец	3810	3810	4410	4410	4410	4410	4410	4410	4410	4410	4410	4410
вкупно на крај на месец	3810	7620	12030	16440	20850	25260	29670	34080	38490	42900	47310	51720

Следната 3Д пита прикажува како ќе се зголемуваат приходите со текот на месеците

2. Техничка изводливост

Ресурсите потребните за техничката изводливост се минимални, затоа што потребно е да се направи апликација каде што ќе можат да се пријавуваат дефектите, при што нејзиното користење е доста лесно и доста интиутивно. Дополнително користењето на CRM за решавањето на тикетите во секој случај претставува open source систем, кој треба да содржи (и воедно да се одржува база на податоци) за соодветни агенти (кои претставуваат сервисерите) и корисниците (кои претставуваат корисниците на опрема).

Одговарањето е брзо и ефикасно, а временскиот интервал од два часа за секој дефект го прави потсистемот доста ефективен и флуиден.

3. Операциска изводливост

Целта на една студија на операциска изводливост е да покаже дали и колку добро еден предложен проект / систем / потсистем / план го решава проблемот. Сепак тука постои една мала модификација на операциската изводливост. Некои од стандардните сервиси се неминовни и мора да се извршат на секои два месеци. Некои од дефектите се непредвидливи, па секако ќе мора да се креира тикет за да се поправи дефектот од страна на сервисерите во најбрз можен рок.

Во секој случај, намерата при операциската изводливост е корисниците да реагираат навреме и да постапат соодветно во случај кога немаат физички пристап до сервисерите, кога немаат пристап до алати или пак географскиот фактор на достапност е минимален.

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

4. Временска изводливост

CPM или Critical Path Method* претставува методологија за проценка на вкупното време потребно за реализација на целиот проект, пред воопшто да започне работата на проектот. Тука е вклучено од самата идеја, до обука на вработените и функционалноста на целиот систем. Тоа значи дека се мапираат најклучните чекори и елементи и задачи во проектот и на крај се добива некоја престава за вкупното време.

---

МЕСЕЦ 1

Активност бр.1: Фаза бр.1 - фаза на истражување - Итерација бр.1
Времетраење: 3-4 дена
Подактивности:
Сослушување на корисничките барања
Разговарање за потребите и можностите на апликација

Активност бр.2: Фаза бр.2 - Планирање на барања - Итерација бр.1
Времетраење: 5-7 дена
Подактивности:
Опис на кориснички барања
Изработка на визијата на потсистемот
Дефинирање на целите, ограничувањата, барањата, приходите и расходите на потсистемот
Креирање на случаи на употреба и дефинирање на круцијални актери (вработени) во склоп на проектот

Активност бр.3: Фаза бр.3 - Кориснички дизајн - Итерација бр.1
Времетраење: 7 дена
Подактивности:
Анализа
Дефинирање на кориснички дизајн
Креирање на кориснички дизајн
Планирање за тестирање
Тестирање

Активност бр.4: Фаза бр.3 - Кориснички дизајн - Итерација бр.2
Времетраење: 7-10 дена
Подактивности:
Комуникација со клиентите и вршење поправки на кориснички дизајн
Анализа
Дефинирање на кориснички дизајн
Креирање на кориснички дизајн
Планирање за тестирање
Постојана интеграција

Активност бр.5: Фаза бр.3 - Кориснички дизајн - Итерација бр.3
Времетраење: 5-7 дена
Подактивности:
Комуникација со клиентите и вршење поправки на кориснички дизајн
Повторно анализа
Планирање за тестирање
Дефинирање на конечен кориснички дизајн
Финално тестирање
Испраќање кон продукција и продукциска фаза

---

МЕСЕЦ 2

Активност бр.6: Фаза бр.4 - продукциска фаза - Итерација бр.1
Времетраење: 2 недели
Подактивности:
Дизајн и имплементација на корисничките барања
Првична верзија на апликацијата - прв прототип

Активност бр.7: Фаза бр.4 - продукциска фаза - Итерација бр.2
Времетраење: 2 недели
Подактивности:
Дизајн и имплементација на корисничките барања
Креирање втор прототип
Првични тестирања

---

МЕСЕЦ 3

Активност бр.8: Framework & Correction - Итерација бр.3
Времетраење: 1 недела
Подактивности:
Тестирање на корисничките барања и поправање грешки
Креирање финален прототип
Финални тестирања

Активност бр.9: Финална активност пред испорака - Итерација бр.2
Времетраење: 1 недела
Подактивности:
Испорака на софтверското решение
Обука на вработените
Одржување на апликацијата

Вкупно траење: 80 дена ~ скоро 12 недели ~ 3 месеци