Универзитет “Гоце Делчев”

Факултет за информатика

Тема

Управување со динамиката на проектот

Подготвил:

Прегледал:

Одобрил:

: Наставни цели

Откако оној кој што ќе го прочита нашиот проект, тој ќе биде во можност:

Прва цел: да објасни зошто е битен планот за динамика на еден проект;

Втора цел: да посочи колку видови на план за динамика на проектот постојат;

Трета цел: да дефинира што се спаѓа во стуктурата на планот за динамика на проектот;

Четврта цел: да идентификува барем пет различни методи за проценка на квалитетот на

еден проект од вкупно десет;

Петта цел: да наброи кои се и да ги опише активностите за планот за динамика на

проектот;

Шеста цел: да ја објасни разликата помеѓу изминато време и време потребно да се

изработи еден проект;

Седма цел: да објасни што се тоа проектни пресвртници;

Вовед

Темата на нашиот проект е управување со динамиката на еден проект. Динамиката на еден проект

е многу важна затоа што таа се занимава со прашањето „кога“. Тоа значи дека овде станува збор

за тоа од кога ќе започне проектот, кога ќе заврши проектот, кога треба да биде завршена секоја

од неговите фази и друго. За еден проект е многу битно да има изработено план за динамика на

проектот. Тој план треба да биде јасен и прецизен со точно дефинирани активности и задачи кои

треба да се исполнат за да проектот биде успешно завршен. За проектот се битни три работи:

време, ресурси и буџет. Значи дека проектот има ограничено време кога треба да започне и кога

треба да заврши, точно се знае времето. Постојат ресурси кои членовите на тимот треба да ги

искористат при изработката на планот и секако да не го надминат буџетот. На тоа треба да

внимаваат членовите на тимот. Понекогаш за некои проекти има многу малку време, па не можат

да бидат завршени, или пак самите членови на тимот не се согласуваат, не комуницирале добро

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

спаѓале во лоши проекти. Во лоши проекти ќе спаѓаат и оние кои го надминале буџетот или

немаат доволно ресурси за да го завршат проектот. Сето ова се случува поради тоа што немаат

добар план за динамика на проектот. Значи дека тие проекти не направиле добра проценка за тоа

како ќе се одвиваат работите при изработката на проектот. Секогаш е потребно да има направено

и резервен план. Тој се прави за ако нешто тргне погрешно, да се разработува резервниот план,

резервните анализи за да не се губи време што понатаму. Од времето ќе ни тргнe на лошо и

буџетот, кој ако не оди работата како што треба би можело или да си го повлечат купувачите или

пак тој да си тече и ако се надмине да треба да си плаќаме од својот сопствен џеб. Многу од

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

вината си ја префрлаат самите меѓу себе. Многу често се среќава како карактеристика дека

проектите настојуваат се да завршат одеднаш. Сите задачи, фази и активности сакаат да ги

завршат одеднаш. Тоа според наше мислење не е добро бидејќи секоја активност или задача

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

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

проектот се прави прв и после од него ќе се гледаат активностите кои треба да се извршат. Друга

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

сакаме да ни биде готов проектот на време. Тоа се прави сепак поради искуството кое го има

професионалецот. За една задача да биде комплетна таа треба да има проценка.

“Наједноставната и најважната задача на еден проект е поставување на реални очекувања.

Нереалните очекувања базирани на несоодветни проценки се единствените и најголемите

причини за софтверско пропаѓање.”

Изрека од Farrell, Shafer, “Quality Software Project Management”

Активностите или задачите се карактеризираат со напор – колку работа ќе треба да се вложи за да

се заврши активноста, ресурси – колку ресурси ќе бидат достапни за активноста, траење – колку ќе

трае активноста.

1. Видови динамика

Постојат два вида на динамика и тоа динамика по улоги и процесна динамика.

1.1. Динамика по улоги

Во овој процес на планирање на динамиката станува збор за тоа кој за што е задолжен. Тоа значи

дека секој член од тимот си има свои задачи кои треба да ги исполни. При тоа задачите мора да

бидат јасно дефинирани за да знае тој што ја обработува на што да посвети внимание. Освен тоа

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

Во исто време не може еден член од тимот да работи две задачи. Тоа се прави со цел проектот да

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

Помеѓу членовите во тимот треба да има соработка. Тие треба да комуницираат еден со друг, да

си ги пренесуваат мислењата, да си ги искажуваат идеите кои ги имаат. На тој начин може многу

побрзо и подинамично да им тече работата а ќе им биде и позабавно преку разговор да се

постигне целта. Од некои истражувања кои се направени се докажало дека во големите компании

луѓето се плашат да си помагаат помеѓу себе, да си ги искажуваат своите мислења и ставови. Тоа

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

унапреден кога станува збор за работата.

1.2. Процесна динамика

Во овој тип на динамика на проектот станува збор за тоа дека еден проект треба да се извршува

фаза по фаза. Односно секој чекор треба одделно да се разработува. Бидејќи чекорите во

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

кога имаме неколку чекори тие се извршуваат еден по еден.

2. Структура на планот за динамика на проектот

- Карактеристики на проектот. Проектите се состојат од низа на задачи кои треба да се

извршат и задачи кои се извршени. Тука спаѓаат ресурси, развојот на проектот, донесување

на одлуки и друго.

- Циклус на повторна работа. Во овој циклус имаме четири чекори. Прв чекор е дека имаме

оригинална работа која треба да ја завршиме. Потоа одиме на чекор два – работата е

завршена. Меѓутоа иако задачата е завршена сепак треба да се провери дали постојат

некои грешки. Затоа одиме на чекор три – неоткриена повторна работа, и чекор четири –

повторната работа е завршена и доколку имало грешки тие се пронајдени.

- Контрола на проектот. Моделирање, анализирање и напредување на работата на проектот

се задачи на контрола на проектот. Тоа значи дека треба да се внимава на проектот, да се

следи до каде сме со работата, дали има некои грешки, ако има да се поправат, да се

следат согласувањата со тимот итн.

- Планот за динамика на проектот се состои и од мрежни дијаграми и Barr Charts кои ќе ги

опишеме подоле во нашиот проект.

3. Методи

Подоле се опишани некоку методи кои се најмногу користени и најмногу употребувани методи.

Методите не можат точно да бидат дефинирани, но ќе бидат објаснети за да бидат разбирливи.

Секој од методите исто така е склон на грешки и зависи од големината на задачата која се

анализира.

3.1. Метод на аналогија

Овој метод е еден од најстарите, но најзначаен метод од сите методи. Овој метод зависи од

логиката на наоѓање сличен проект со тековниот проект и проект кој претходно бил поставен во

употреба. Значи тука се бараат сличностите кои постојат помеѓу проектите. Оваа сличност се

однесува на:

Типот на бизнисите кои се вклучени

Големината на апликациите

Генерален опфат на системот

Технички методи, стандарди и јазици коои се користат

Онаму кај што ќе се сретнат некои разлики помеѓу некоја од овие области тие треба да бидат

изменети. На пример имаме еден постар проект кој бил развиен од COBOL и еден нов проект кој

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

побрзо за разлика од постариот. Значајни се неколку карактеристики кои постојат помеѓу

постарите проекти и поновите проекти. Тоа се културата на компанијата на купувачот, на кое ниво

се наоѓа купувачот во врска со компјутерите односно како тој се снаоѓа со нив, растот на

подршката за проектот и други. Најголемата предност на методот на аналогија на проектот е дека

проценката се врши на целиот проект. Недостаток е дека постои опасност помеѓу два проекти да

има сличности, oдносно да бидат употребени слични или исти алатки.

3.2. Метод за анализа на работата

Кај овој метод проценката се прави уште пред да започне деталната анализа за проектот.

Генералната идеја се состои во тоа да се процени вкупната работа која ќе биде потребна да се

изврши се додека се заврши проектот. Постојат три поврзани работи со овој метод. Тоа се

големина, блискост и комплексност.

- Големина. Големината уште се означува со Ѕ. Тоа е фактор кој го одредува бројот на луѓето

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

Ѕ = 1 проект кој е составен од една личност

Ѕ = 2 мал проект кој е составен до четири лица

Ѕ = 3 среден проект кој содржи до дванаесет лица

Ѕ = 4 голем проект кој содржи до триесет лица

Ѕ = 5 многу голем проект кој содржи повеќе од триесет лица

Ѕ = 6 на оваа точка неможеме да ја дефинирaме големината

- Блискост. Блискоста уште се означува со F. Блискоста е фактор кој се однесува на тоа како

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

F = 1 Од луѓето кои што работат на проектот сите фактори се познати затоа што проектот е

сличен со некој претходен проект.

F = 2 Апликациите или технниките им се добро познати на развивачите на планот за

динамика на проектот, но тие користат непознат хардвер, оперативен систем, јазик или

друг софтверски пакет.

F = 3 Невообичаени апликации или техники кои им се познати само на неколку луѓе кои

што не се друштвени, но затоа користат заеднички хардвер, софтвер, јазик и др.

F = 4 Апликации или техники кои се нови за развивачите на планот за динамика на

проектот, но познати на IT индустријата.

F = 5 Апликации или техники кои им се нови на развивачите на планот за динамика на

проектот, но стандардни за IT индустријата, користат непознат хардвер, софтвер јазици и

др.

F = 6 Голем елемент на иновација.

F = 9 Блискоста не можеме да ја опишеме.

- Комплексност. Комплексноста уште се означува со С. Таа е фактор кој ни ги покажува

типовите на техники кои што се применуваат при изработката на проектот.

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

С = 2 еден од горе наведените фактори не е точен.

С = 3 два или повеќе од горе наведените фактори не се точни.

С = 4 неколку конструкции на мемории перформанси и друго.

С = 5 комплексоста неможеме да ја опишеме овој пат.

3.3. Метод на програмирање

Методот на програмирање започнува од различна точка за разлика од методот на анализа за

работа. Овој метод во суштина се занимава со нешто кога ќе тргне на лошо, односно кога некоја

програма нема да работи како што треба. Тоа значи дека таа програма не ја извршува правилно

својата функција. Па затоа се користи овој метод. Овде во суштина станува збор за тоа колкав број

на линии на код се испишува во програмата. Меѓутоа сето тоа не е возможно, бидејќи еден

програмер не може однапред да знае колку линии на код ќе испише. Тоа може да го предвиди

само некој искусен програмер. Меѓутоа и во тој случај не е сигурно дека ќе може со сигурност да

каже колку линии на код би испишал во неговата програма се додека не заврши со неа. Во врска

со програмите постојат три категории за завршување на програмите. Тоа се: мал програм кој трае

пет дена, среден програм кој трае десет дена и голем програм кој трае петнаесет дена.

3.4. Директна проценка за план за динамика на проектот

Оваа метода има најмногу детали. Таа зависи од тоа дали членовите на тимот ќе направат

ревизија односно дали после завршувањето на проектот ќе се навратат на фазите од проектот и ќе

извршат проверка. На почетокот на секој проект нема доволно информации за да точно се

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

работа. Тоа се прави за да не дојдеме во лоша ситуација ако не го завршиме навремено проектот.

Сепак времето и работата не се единствените работи на кои треба да се внимава. Тука е и буџетот,

кој не треба да се заборава. Затоа што ако го надминеме буџетот после тоа ќе се најдеме во лоша

ситуација и ќе треба целиот трошок да падне на нас. Овој метод се користи за развивање на

планови за подчекорите на проектот.

3.5. DELPHI метод

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

потоа следи складирање на сите нивни проценки и да се дојде до посакуваната цел, а тоа е да се

добие добра и точна проценка за планот за динамика на проектот. Се додека луѓето имаат

различни искуства и секако различно интелектуално ниво и во пристапот и користењето на

хардвер и софтвер, пристапот има неколку чекори.

Секој проценувач на планот за динамика на проектот ќе треба да направи анонимна

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

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

успешно проценетата активност.

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

спецификации. После тој исход тие може да се задоволни или пак да не бидат задоволни.

А секој после тоа има право да оди кај стручните лица и доколку сака да му се укаже на

неговите грешки.

Најважното од се тука е дека со тоа што сето тоа се прави на анонимен начин се придонесува до

чување на личните несогласувања помеѓу тимот во текот на работата на проектот. Во суштина тука

се работи за тоа дека тој што заслужува повеќе, повеќе треба и да добие. Значи оној кој е добар

проценувач, кој добро си ги извршува своите задилжениа секако дека треба да биде награден за

тоа. Доколку станува збор за оној проценувач кој не е толку добар на овој начин, преку

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

3.6. СоСоМо

Овој метод бил развиен од Barry W. Boehm. Овој метод се состои во три верзии, и тоа:

Основен СоСоМо. Негова формула е MM = 2.4(KDSI)1.05. Овде ММ ни означува работата на

човек во месеци. Од пресметките докажано е дека човекот има 152 работни часови за

деветнаесет дена.

Средниот СоСоМо во себе ги вклучува атрибутите на производот (реалност, комплексност,

итн.), задачите на компјутерот (извршно време, меморија, итн.), персоналот (способност,

искуство, познавање на јазици, итн.), на проектот (користење на модерни алатки, итн.).

Деталниот СоСоМо ни дава детална проценка за планот за динамика за проектот и тоа

фаза по фаза.

3.7. 2СоСоМо

Овој метод претставува продолжение на првиот СоСоМо. Тој води сметка за некои од клучните

драјвери на разликите кои постојат помеѓу проектите, иновативноста, флексибилноста, степенот

на кој се поправа опфатот на проектот и друго.

3.8. СоСоМопроценка на извршно време

Овој метод ни покажува дека распоредот на проектот може да биде компресиран под седумдесет

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

недостаток на СоСоМо равенството е дека тоа зависи од бројот на испорачани изворни

инструкции – помалку или повеќе линии на код.

3.9. Метод на анализа нафункција

Овој метод бил развиен од AJ Albrecht и JE Gaffney. Тука се обрнува внимание на проценка на

големината на софтверскиот систем. Се анализира системот во ознаки на процесирање на

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

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

друго.

3.10. PERT метод

Се базира на тоа дека проценката е неизвесна, се користи рангови на траење. Се користи изразот

очекувана вредност за да се утврди траењето. Има три проценки, тоа се :

Оптимистичка – која трае пет дена

Средна – која трае седум дена

Песимистичка – која трае дванаесет дена

Предност е што се пресметува несигурноста. Недостатоци се време и труд, пресметувањето на

непознати ресурси претставува голем проблем, се користи само за големи, комплексни проекти.

4. Видови на активности

4.1. Проценка за подршка на активности

Една причина зошто некои проекти го преминуваат времето или буџетот е бидејки

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

заедно. Релативно е полесно да се идентификуваат главните задачи од проектот како што

се спроведување на интервјуа, пишување кодови и изведување системски тестови. Но

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

големо време од изработката на проектот. На пример активноста може да биде

дефинирана како преглед на програмската спецификација Х, но што во врска со

справувањето со резултатите од тој преглед. Пример: проверка на програмската

спецификација Х после прегледот и повторен преглед на програмската спецификација Х и

повторно пуштање во употреба на програмската спецификација Х после вториот преглед.

Многу важно е дека сите овие активности за подршка се грижат за проценката. Проект

менаџерот треба да земе во предвид дали има некои специфични задачи кои ќе се

додадат на овој проект и кои ќе бидат додадени на профилот. Има три основни начини на

профили за овие активности за подршка: со експлицитна проценка како што е додавање

на задача наречена преглед на квалитетот и број на денови кои се потребни за да се

изведе проектот, со додавање на проценти на врвот на еден од основните активности- да

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

квалитетот, со поврзување на активноста со времетраењето на проектот- за пример еден

ден неделно да се покрие менаџирањето на проектот. Додека дозволувањата се

изводливи не е премногу важно кој приод ќе се усвои. Како и да е важно е користениот

метод да е документиран како што треба. Активностите за подршка кои треба да бидат

искористени во профилот се дискутирани подолго. Некои од овие активности можат да

бидат пресметани како дел од други специфицирано проценети задачи. На пример: некој

може да додаде 5 до 10 проценти на врвот на дизајн на задачата за да дозволи прегледи

на квалитет. Други активности како што се проект менаџментот, се повеќе поврзани со

времетраењето на проектот.

4.2. Поделени активности

Тимско лидерство и супервизија

Постои одамна воспоставено и генерално сигурно правило дека тим лидерот треба да

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

треба да претставува 20 % од програмскиот напор за време на кодирањето, тестирањето

на единицата и тестирањето на системот. Тимското лидерство за време на други фази од

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

нешта ке зависат од искуството на индивидуалните аналитичари и дизајнери. Сликата за

10-20 проценти од напорот за функционална спецификација, системски дизајн и

програмска спецификација е корисна отскочна даска.

Програми и документација за операциите

Документацијата на која се мисли овде не е за дизајн на документацијата на продукцијата

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

што е прирачникот за операции кој резултира од програмската работа. 7 % е добра

проценка овде.

Контрола на квалитетот

Проект менаџерот треба да одлучи каква форма треба да завземе контролата на

квалитетот.

Осигурување на квалитетот

Дали изработувачите поседуваат специјалисти за квалитет на осигурување или се дел од

регуларниот ИСО 9001 надгледувачки и реакредитативен процес. Проект менаџерот треба

да го дискутира ова прашање со одделот за квалитет кога проектот ќе почне, и да го

распореди прегледот на квалитетното осигурување како експлицитни активности во

проектниот план.

Прегледи на корисникот

Уште еднаш потребите овде варираат од проект до проект. На крајот корисниците ќе

треба да направат преглед на главните документи како што е функционалната

спецификација и некој надоместок мора да биде направен за: презентација на

документите на претставниците на корисниците, дискусија со корисниците за да ги

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

Преглед на работата од трета страна

Ако кооперантите се искористени да изведат некој дел од работата некој надоместок

мора да биде направен за додавање на контрола на работата на нивната работа. 10% од

проценетиот напор на третата страна е добар генерален водич.

Преглед после имплементацијата

Некој напор треба да биде дозволен за изведување на преглед после имплементацијата

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

така секогаш ценетите мерки да бидат зачувани за придонес кон наредните проекти.

4.3. Експлицитни активности

Со активностите дискутирани подолу ние треба да се запрашаме што точно ни треба за

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

Корисничка документација

Овде се зборува за корисничките водичи и прашања кои треба да се одлучи колку

екстензивни или професионални треба да бидат и каква форма треба да завземат.

Технички тренинг на персоналот

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

делува на поминатото време на проектот и нема да влијае на буџетот на проектот. Ова

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

издржат проектната работа- можеби тренинг на нов јазик или верзија на јазикот. Треба да

биде запаметено дека не е само персоналот вклучен во ова туку исто така има буџет кој

треба да биде платен за предвидениот тренинг.

Запознавање

Челеновите на тимот имаат потреба од запознавање во овие случаи: во бизнисот на

корисниците, правилата и регулативите на корисниците, посебно ако работат на

ограничени или сајтови критични со безбедноста, стандардите и методите кои ќе бидат

користени на проектот, техничката природа – оперативниот систем, програмскиот јазик,

алатките итн. Напорот посветен на запознавањето се разликува значително од проект до

проект. Проект менаџерот треба да направи некои подесувања од тоа колку запознавање

од кој вид е потребно имајки ги вештините, искуството и позадината на доделениот

персонал.

Креирање на податоци, конверзија и преминување

Тешкотијата од конвертирањето на податоците од стар систем и преминувањето на

податоците во нов систем е често или заборавено или потценето. Ова може да биде

активност за трошење на време и може да влучи користење на додатен персонал како

што е персоналот за подготовка на податоците ако директно конверзирање на

податоците не е возможно.

4.4. Активности за поминато време

Проблемот со активностите за поминато време е тоа што времетраењето на проектот

станува поделено само тогаш кога деталното планирање на проектот настапува. Во овој

случај имаме проценување и распоредување и тоа може да биде видено како итеративен

процес.

Проект менаџмент

Голема одлука може да биде донесена кога: Проект менаџерот со целосно работно време

ќе биде искористен на проектот, ако проект менаџерот со пола работно време биде

искористен, дали тие изведуваат некоја друга активност, можеби како бизнис аналитичар

на овој проект или го исполнуваат останатото време со работа на друг проект.

Менаџмент на системи и техничка подршка

Улогата за поддршка на системскиот менаџмент и техничката поддршка можат да бидат

потребни за дизајнерските одделенија. Ако е целовремено вклучување може да биде

пресметано како 18 дена месечно со намалено координирање.

Менаџмент со конфигурација

Допуштеност може да биде направена за да се среди менаџментот на конфигурациските

процедури на почетокот на проектот и да се работи со нив подоцна. На поголеми проекти

може да има целосен менаџмент на конфигурација во случајот кога 18 дена месечно се

дозволени.

Менаџмент за имплементација

Ако целовремен имплементациски менаџмент е потребен тогаш на нив им треба неколку

недели за подготовка плус вообичаeните 18 дена месечно за време на самата

имплементација.

Администрирање на податоци

Уште една нетривијална активност, дел од голем проект каде улогата на целосно работно

време може да биде идентификувано.

Проект канцеларија

Имањето на проект канцеларијата или на некој друг вид на подршка за проектот е многу

вредна и битна за трошоците. Го ослободува проект менаџерот од некоја рутиснка работа

како што е забележување на работењето и му озвозможува на него или неа всушност да

го менаџира проектот.

Со договарачки менаџмент

Ако содоговарачите се вклучени напорот мора да биде посветен за да се менаџира со нив.

Контролата на квалитетот на содоговарачите беше веќе спомената но во зависнот од

големината со договорот може да има потреба за: секојдневни состаноци за преглед на

напредокот. Повеќе состаноци за добивање согласност и подоцнежно прегледување на

ставките на договорот. Проверување и авторизација со гласање. Интервјуирање на

персоналот на содоговарачите.

4.5. Другифактори кои влијаат на проценката

Досега во дискутираното имавме тенденција да претпоставуваме дека аналитичарите се

менливи, дека програмерите имаат еднакви нивоа на вештини и способности и дека сите

проекти имаат сличности. Како и да е очигледно е дека ниедна од овие работи не е точна

во реалноста и проценувањето мора да биде подесено да прикаже профил во различни

облици кој може да се појави кај луѓето од проект во проект.

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

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

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

подолги од стандардните. Искусен програмер користејки нов јазик за првпат е исто така

бавен на почетокот но разликата е помалку назначена. Запознавањето исто така треба да

биде дискутирано, но паметен проект менаџер исто така ќе си додаде уште време за да ги

комплетира анализите и дизајнерските работи со неискусен персонал.

Користење на персонал со договор

Во пораст се компании кои имаат корист од програмерите по договор. Во теоријата

програмерот по договор поседува добри технички способности и така продуктивноста

нема да трпи. Како и да е вработените од надвор се со непознат квантитет освен ако не

работеле за некои компании претходно, па и така постои некоја почетна забавеност

додека се научат на локалните методи и стандарди.

Корисничко вклучување и достапност

Проектниот менаџер треба да има видување пред работата да почне, за тоа колку

достапни и посветени корисниците ќе бидат на проектот. Ако корисниците се

заинтересирани за развивањето, тогаш добивањето пристап до прегледите и фактите за

нив ке биде многу лесно.

Корисничка подршка за време на прифаќањето

Корисниците можат да имаат различен пристап кон ова. Некои радосно го прифаќаат

изведувањето на тестовите, некои едноставно сакаат да набљудуваат како системските

тестови се изведувани од развивачите.

Инсталација и пуштање во работа

Зависно од бројот на локации на кои системот треба да биде имплементиран ова може да

биде доста опфатна активност и треба да биде дозволена за проценка.

Гаранција

Видот и траењето на гаранцијата може да биде дискутирана и одлучена за време на

договорните преговори. Како и да е некој надоместок треба да биде направен за работата

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

Тримесечна гаранција 5%

Шестмесечна гаранција 3%

Дванаесетмесечна гаранција 10%

5. Распоред на динамиката на проектот

Управувањето со динамиката на проектите во праксата уште е познато и под името scheduling.

Кога сите задачи ќе се подредат, управувањето со динамиката на проектот може да започне.

Постојат два типа на динамика на проектот, а тоа се: Математичка анализа и Bar Charts. Во

математичката анализа можеме да ги вброиме мрежните диаграми (PERT, CPM, GERT). Разликата

помеѓу мрежниот дијаграм и управувањето со динамиката на проектот е календар кој се заснова

на должината на работните недели и одмори. Основните разлики во овие управувања на

проектите се:

- WBS дефинира ,,што‘‘

- Мрежен дијаграм дефинира ,,како‘‘

- Управувањето со динамиката дефинира ,,кога‘‘

- RAM дефинира ,,кој‘‘

5.1. Мрежен дијаграм

Тој е развиен во 1950 година. За да еден проект биде комплетен потрбна му е и графичка

репрезентација, каде поубаво може да се забележат задачите и врските кои постојат помеѓу нив.

Постојат две форми за мрежните дијаграми.

АОА – активност на стрелка

АОN – активност на јазол

Секоја задача си има траење и идентификација. Има еден почетен и еден краен настан.

слика 1:АОА и АОN, извор Project Scheduling

АОА се состои од кругови кои претставуваат настани, линиите претставуваат задачи.

АОN се состои од задачи на јазлите, стрелки кои ја покажуваат зависноста помеѓу задачите.

Ако одредени ресурси се доделуваат во тоа време, управувањето со динамиката на проектот, исто

така, мора да ја земе во предвид достапноста на ресурсите и отсуствата на ресурсите за одмор и

слободно време. Многу проект менаџмент софтверски пакети имаат нивоа на ресурси така што за

секој ресурс се користи еднаква количина на време во секоја работна недела. Додавањето на

специфични ресурси во управувањето на динамиката на проектот генерално ќе го продолжи

врметраењето на проектот. Критичниот пат на управувањето со динамиката на проектот може да

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

подредувањето на ресурсите. Графичка претстава на управувањето со динамиката на проектот

може да се претвори во проширен мрежен дијаграм и цртањето на јазлите во таквото управување

со динамиката на проектот може да изгледа како на слика 2 прикажана подолу. Пример за таков

дијаграм е претставен на слика 3.

Слика2: Јазли, извор Project Menagement for Information System

Слика3: Мрежен дијаграм, извор IRM.Press 1.Project.Menagement for Information System

Графичкото претставување на управувањето со динамиката на проектот, сепак е Gantt дијаграм,

кој е еден од најкористените графици во проект менаџментот. Тој бил именуван по Henry Gantt,

кој прв го развил за време на првата светска војна во армијата на САД. Тој бил механички инженер

и менаџмент консултант и неговите табели подоцна биле вклучени во големите американски

инфраструктурни проекти како што е браната Hoover Dam и меѓудржавниот автопат. Еден пример

е прикажан на слика 4. На Gantt дијаграмот секоја задача е претставена како хоризонтална лента

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

означуваат почеток и крај на одредена задача. Секоја задача е означена со WBS код и опис.

Постојат повеќе варијации на основниот Gantt дијаграм, повеќе информации можат да се додадат

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

релациите, засенчување во лентите за процендуално прецизирање на задачите, боење на лентите

за да се покажат задачи на критичен пат, WBS хиерархија и т.н. Проблем со Gantt дијаграм е тоа

што отсликува дури и дистрибуција на напор од почетокот до крајот на задачата (особено кога се

користи засенчувањето на ленти). Друг проблем со традиционалниот Gantt дијаграм е големиот

простор кој го зафаќа на компјутерските екрани или на испечатеното особено за големите

проекти.

Слика4: Гант дијаграm, Извор http://www.rff.com/gantt1.htm

Проект менаџерите треба да се фокусираат на управувањето на проектот, а не на управувањето со

динамиката на проектот. ИТ човековите ресурси во голема мера се професионалци, тие можат да

работат различен број часови во денот, тие од време на време може да бидат повикани да

помогнат на друго лице или на друг проект, тие можат да бидат ослободени од обврските на некој

ден, поради одредена причина кога тие тоа би го посакале. Како што спомнавме претходно,

проценките вклучуваат значителна несигурност и продуктивноста зависи од чекори на поединци.

Овие фактори одсекогаш играле главна улога во ИТ управувањето со динамиката на проектите,

една од најдобрите дискусии за ова е опфатена во книгата на Frederick Brooks со наслов The

Mythical Man-Mounth (1975). Многу компании трошат драгоцено време со управувањето со

динамиката на проектот, кои постојано ја менуваат динамиката, обидувајќи се со вметнување на

индивидувални достапни ресурси. Правило за овој работен пакет е да има одреден временски

период за извештај, кој трае една до две недели во повеќето организации. Изработка на ресурсни

задачи на ниво (или специфични или општи ресурси) е повеќе разумен пристап за ИТ проектите.

Со други зборови, секој WBS работен пакет после секој напор (во работните часови) е

детерминиран, само се доделува едно или повеќе лица на тој пакет во зависност од работните

периоди (недели). Нереалните управувања со динамиката на проектот е една од основните

причини за кризи и неуспеси во проектот. Според Јанг (2003), постојат седум работи кои треба да

се сторат пред некој да може да изврши реално управување со динамиката на проектот:

Одредување на обемот и барањата

Прототип на најголемите технички ризици

Креирање модел за кориснички интерфејс

Обрнување внимание на индустриско-стандардни проценки за слични проекти

Секој да создаде динамика за управување на своите задачи

Прифаќање само видливи, мерливи статусни извештаи

Поделба на сите задачи се додека за секоја задача се потребни една или две недели за

извршување

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

Процесот на одредувањето на роковите и динамиката го одредува потребното време како и

редоследот низ кој се движи проектот. Роковите се основните сретства за контрола.

Управувањето со динамиката на проектот може да се распореди по :

Фазен пристап

Предности кај овој пристап се подобрата контрола и низок ризик, недосток е тоа што ресурсите и

времето не се најефикасно искористени.

Паралелен пристап

Предност кај овој пристап е краткото време и ефикасното искористување на ресурсите, додека

тешката контрола и конфликтите се недостатоци.

Како што веќе погоре спомнавме со помош на Gantt дијаграмот најдобро можеме да ја

претставиме динамиката по која се одвива проектот. Gantt дијаграмот ни претставува најдобар

алат за комуникација, тој ги индицира клучните рокови и обично содржи 10-15 активности или

групи на активности. Мора да биде ускладен со структурата на задачите. Тој треба обавезно да се

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

Линиите претставуваат време, а не количина на обврски.

• Предности:

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

ускладени и лесно видливи;

-го прикажува статусот на елементите на проектот;

-ги идентификува елементите кои се пред или после рокот.

• Недостатоци:

-не ја покажува зависноста помеѓу активностите;

-не е можна анализа на осетливоста;

-не е видлив вистинскиот напредок на проектот (елементите кои каснат не значи и проект кој

касни);

-целокупниот напредок на проектот не е доволен.

5.2. Критичен пат

Сите проекти имаат критичен пат. Критичен пат е патот кој што се изминува таму каде

активностите имаат траење нула. Ако некој проект нема критичен пат, тогаш сигурно има некоја

грешна пресметка.

5.3. Метод на критичен пат

Постои временски оптимизиран проект. Тоа значи дека не постојат резерви. Дека целиот тим е во

работа, никој не одмара, сите се ангажирани. Задачите кои немаат критичен пат може да започнат

порано или покасно од крајниот рок за проектот. Доколку патот се скрати, односно активностите

се скратат тогаш критичниот пат се менува во друг, пократок од дадениот.

Слика5: критичен пат 1,извор Project Scheduling

Исто така треба да знаеме, да направиме план колку би траел проектот. Затоа има две техники:

чекор напред и чекор назад.

Чекор напред се користи за да се определи најран почеток (ES) и најран завршеток (EF) на

проектот. Оваа техника работи од лево кон десно, со додавање на времиња на секоја

патека. По завршувањето на неколку задачи, најраниот почеток за наредната задача е

најголема од извршувањето на најраниот завршеток.

Слика6: чекор напред 1, извор Project Scheduling

Чекор назад се користи за да се определи најкасниот почеток (LF) и најкасниот завршеток

(LS) на проектот. Почнува на крајниот јазел. Се одзема траењето од јазелот со најран

почеток.

5.4. Пресвртници

Тие имаат траење нула. Пресвртниците ги идентификуваат критичните точки во планот за

динамика на проектот. Се означуваат со превртен триаголник или со дијамант. Често се користат

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

Слика7: milestones, извор Project Scheduling

Понекогаш се нарекуваат и “bar charts” или уште се нарекуваат и Gantt chart. Пресвртниците

претставуваат точка на која нашиот продукт, продуктот од проектот, е прифатен од страна на

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

се случува и кога ги има премалку. Тоа значи дека ќе треба внимателно да се изберат.

5.5. Распоред и поминато време

Распоредот на проектот кој вообичаено зема форми на дијаграм покажува две работи:

Секвенца во која работата може да биде изведена.

Датите на кои ние планираме да започнат и завршат.

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

активност. Развитокот на работниот распоред да е неменлив интерактивен процес. Ние

правиме некои иницијални претпоставки за развивање на распоред од прва рака,

споредување на резултатите со нашите посакувани очекувања - делумично од термините

за завршувањето на проектот - и прераспоред толку пати колку што е потребно да се

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

треба да ја објасниме разликата помеѓу напорот и поминатото време. Оваа разлика е

најважна за разбирање на процесот на распоредување. Да претпоставиме дека сме

извршиле задача која бара дваесет дена напор (работа). Претпоставуваме дека имаме

само една личност достапна за да ја изврши работата. Тогаш ако личноста не е отсутна за

периодот кој опфаќа дваесет дена работа, таа работа ќе биде завршена. Ако имаме

достапни двајца луѓе и работата може да биде поделена тогаш работата од дваесет дена

може да биде извршена за десет дена. Со четворица луѓе работата ќе биде извршена за

пет дена.

Во продукција на нашиот проект за планирање на распоредот, битно е да задржиме

динстинкција помеѓу напорот и поминатото време во умот. Вообичаено проект менаџерот

не може да направи многу за напорот (работата) за да се изведе некоја активност, ако

големината на работата е инхерентна со задачата. Но проектниот менаџер мора и да

настојува да влијае на поминатото време со поставување на точниот број на ресурси во

секоја задача.

- Развиток на распоред

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

развиеме почетниот распоред мора да одлучиме колку долго проектот ќе издржи со еден

аналитичар доделен на работата. Ова покажува дека поминатото време за проектот ќе

биде сума од сите активности-триесет и три дена. Знаеме како и да е дека корисникот

бара физибилити студијата да биде побрза, така да, да ја истражиме нашата мрежа за да

видеме кои активности можат да бидат извршени паралелно. Најдовме дека: интервјуата

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

други системи. Анализираните потреби можат да бидат извршени парарлелно со

истражувачките пакети и истражувачкиот хардвер. Ако имаме достапен втор аналитичар

тогаш ние можеме да ја искористиме предноста на оваа паралелност. Во овој план ние

користиме еден аналитичар од интервјуата за однесување и друг од истражувањата на

другите системи, тогаш ако еден аналитичар е доделен на пакетите за истражување,

другиот прво го извршува анализирањето на потребите и тогаш истражувањето на

хардверот. Од работењето на ова ние го скративме потрошеното време за дваесет и еден

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

ја поделиме работата повторно и да ја намалуваме временската скала повеќе.

Слично ние имаме користено различни аналитичари на секој од побарувањата на

анализата, истражувачките пакети и истражувачкиот хардвер, но во овој случај ние не

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

активност на истражувачкиот хардвер. Резултатот можеме да го понудиме на нашиот

корисник за седумнаесет поминати дена. Исто така физибилити студијата е едноставен

пример кој илустрира приод кој е користен колкава и да е големината на проектот.

Постојат како и да е некои други фактори кои треба да се земат во обзир за развивањето

на проектот за распоред.

- Работи кои се земат во обзир за распоредот

Овде претпоставувавме дека една од задачите на нашиот распоред може да биде

поделена и ако ја поделиме активноста на двајца луѓе секој ќе изврши половина од

работата, додека со математички мерки ниедна од овие претпоставки вообичаено не е

точна во практиката. Да претпоставиме дека имаме активност за аналитичарот да

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

аналитичарот треба: да изучи материјал потребен за изработка и да одлучи каков

критериум на оценување ќе биде искористен; да ја прочита техничката литература за

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

критериумот на оценување; да ги постави резултатите од оценувањето едно до друго на

табла и да ги спореди; да напише преглед документирајки ги забелешките.

Ако ја поделиме оваа работа помеѓу двајца аналитичари тогаш ќе пронајдеме дека не

сите од овие подзадачи можат да бидат поделени целосно на половина. И двајцата

аналитичари ќе треба да го изучуваат истиот потребен материјал и најверојатно на нив ќе

им биде потребно подолго време да го развијат критериумот на оценување пред да има

дискусија или расправа помеѓу нив. Еден аналитичар може да прегледа четири податочни

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

внесува понатамошна дискусија и доколку еден компјутер е достапен ќе има

задоцнување додека едниот аналитичар го чека другиот да заврши. Конечно прегледот

може да биде со поделен напор и понатаму ќе има додатна работа околу тоа дали стилот

на документот е целосен. Во продолжение постојат проекти како IS развиток кој внесува

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

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

големина на комуникацијата очигледно расте со големината на тимот. Ако една личност

троши еден час неделно во комуникацијата со секој член на тимот, тогаш во тим со две

лица секој од лицата ќе потроши по еден час неделно, но во тим со осум лица, повеќе од

еден ден неделно ќе биде потребен за комуницирање помеѓу тимот. Како заклучок

можеме да кажеме дека за развитокот на нашиот распоред не можеме да земеме

активност од n денови напор и да го поделиме помеѓу двајца луѓе за да произведеме

поминато време од n/2.

Исто така може да постои предупредување дека многу од проект планираните пакети не

се свесни за овој факт и повеќе би поделиле задача едноставно од бројот на ресурсите

кои се однесуваат на неа, така што овие прашања произведени од планот на својот

сопственост се внесени во профилот.

Друго прашање кое треба да го земеме во предвид е дали активностите кои ние ги

идентификуваме во нашиот продукт и структурата на работата е се што ни треба за да

продолжиме со распоредот. Во нашата физибилити студија ние претпоставивме дека

истражувачките пакети и истражувачкиот хардвер може да почнат кога аналитичарите се

спремни, кога ги завршиле интервјуата за однесување и анализирањето на другите

системи. Но всушност ние треба да напишеме за информација на пакетите и хардверот но

можеби и нема да го добиеме одговорот за времето кога сакаме да ги започнеме нашите

истражувања, доколку ги дозволиме овие работи. Тогаш нашиот распоред ќе биде

невозможно тесен и нема да дозволува ни најмали закаснувања.

Многу важно прашање е и достапноста на ресурсите. Доколку се знае времето колку ќе

трае проектот (пример две, три, пет недели, денови, години..), ние можеме да очекуваме

и да знаеме кога нашиот персонал заминува и кога ќе пристига на работа за да си ги

исполни своите обврски и да ги внесеме нив во нашиот план. Но што да правиме во случај

на непланирано отсуство како што е боледувањето? Во развивањето на целокупниот

проектен план е потребно планот да нема помалку од 100% достапност на персоналот.

Ние прикажавме како лично со целосно работно време е достапен околу 18 дена месечно

како што е подолу прикажано:

Вкупно работни денови по година (52х5) 260

Помалку банкарски одмори (обично Велика Британија) 8

Помалку празници (да речеме) 25

Помалку друго нерабтно време (боледување,тренинг...) 15

212

Поделуваме со 12 за да се прикаже просечниот број месечно 17.66

Или поделува со 52 за да го дадеме просечниот број на денови неделно 4.07

Ова ја прикажува просечната достапност на околу 85% вкупно од 4.25денови од работна

недела со 5дена.

- Најважни проекти

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

изведеме за да го комплетираме нашиот проект. Комплетирањето треба да биде

одбележано со важна значајност – точката на која нашиот продукт е прифатен од

корисникот и на кој начин тие прифаќаат да го платат. Како и да е ние треба да

произведеме и други значајности за време на проектот: Тие придонесуваат корисни

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

проектот како многу битен. Тие можат да бидат искористени да му го прикажат

напредокот на корисникот. Значајностите треба да бидат избрани внимателно. Ако се

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

како битни точки во проектот. Ако сепак се премалку, контролата се губи. Вообичаено

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

копмплементирањето на спецификацијата на крајот од тестот за прифатливост. Нашиов

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

средни важности.

Резиме

Од сето она што го истраживме во врска со нашата тема, ние можеме едногласно да кажеме дека

за да еден проект биде успешен треба да се направи проценка, план за динамика на проектот.

Прво се прави проценката. За да се видат задачите и активностите кои ќе ги имаат членовите на

тимот, како тие треба да се распределат. Потоа треба да се обрне внимание и на времето, кога е

почетокот а кога е крајот на проектот. Потребно е да се обезбедат соодветни ресурси и истите да

се искористат при планирањето на проектот. И на крај секако да се внимава и на буџетот, кој сепак

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

методи кои се применуваат при план за динамика на проектот, исто така се спомнати и

активностите на проектот и неговиот распоред со помош на дијаграмите.

Литература

Bibliography

Brandon, D. IRM.Press.Menagement.for.Modern.Information.Systems. IRM Press.

Chart, с. G. (н.д.). Повратено од http://www.rff.com/gantt1.htm

Ford, J. M. System dynamics applied to project.

pert. (n.d.). Retrieved from http://www.rff.com/sample_pert.htm

Villafiorita, A. Project Scheduling.

Yeates, J. C. Project menagement for Information Systems.