wiki:filipz3

Version 8 (modified by Filip Gjorgjioski, 5 years ago) ( diff )

--

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

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

*RAD = техника за развој на апликација за која ќе се зборува во Индивидуална задача 4

Постојат 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
вкупно на крај на месец 3810762012030164402085025260296703408038490429004731051720

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

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

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

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

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

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

Attachments (2)

Download all attachments as: .zip

Note: See TracWiki for help on using the wiki.