wiki:filipz3

Version 4 (modified by Filip Gjorgjioski, 4 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

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

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

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

Attachments (2)

Download all attachments as: .zip

Note: See TracWiki for help on using the wiki.