Планирање веб-проекти во пракса - PDF бесплатно преземање
Универзитет за применети науки Гелзенкирхен Зимски семестар 2010/11 Семинарска работа Планирање на веб-проекти во пракса Предавач: проф. Чекан Поднесено од: Карстен Нолте Билхолтстрст. 40 59399 Олфен Телефон: +49 2595 385679 Е-пошта: [email protected] Предмет семестар: 7 Поднесување: 27 октомври 2010 година
Содржина 1 Список на слики IV 2 Вовед 1 3 Веб-проекти воопшто 2 3.1 Зошто воопшто да планирате. 2 3.2 Карактеристики на добрите веб-страници. 3 3.3 Дел од глобална платформа. 4 4 Идеја за проект 5 4.1 Дали вакво нешто веќе постои. 5 4.2 Која е разликата? 5 4.3 Дали вреди воопшто. 6 4.4 Истражување. 6 5 Дефиниција на проектот 7 5.1 Заинтересирани страни. 7 5.2 Опсег на функции. 9 5.3 Период. 10 5.4 Трошоци. 10 5.5 Квалитет. 10 5.6 Магичен квадрат. 12 6 Планирање 13 6.1 Структурирање. 13 6.2 Проценка на напорот. 14 6.3 Планирање на трошоците. 15 6.4 План на проектот. 16 6.5 Алатки за поддршка. 16 7 Контрола и управување 18 7.1 Индикатори за успех. 18 7.2 Состаноци. 18 7.2.1 Комуникација. 19 II
Содржина 7.3 Пријавување. 19 7.3.1 Протокол за акција. 20 7.4 Управување со верзијата. 20 7.4.1 Субверзија. 22 8 Завршување 24 8.1 Тест за прифаќање. 24 8.2 Конечна анализа на проектот. 24 9 Заклучок 25 10 Библиографија 26 11 Доверба 27 III
1 Список на слики 3.1 Зошто не успеваат проектите. 2 5.1 Пример матрица за комуникација (содржина: www.t3n.de). 8 5.2. Пример употреба дијаграм на случаи. 9 5.3 Магичен квадрат или ѓаволски плоштад. 12 6.1 Пример план за структура на проектот (содржина: www.t3n.de). 13 6.2 Пример во Excel Метод на Pert (проценка во три точки). 14 6.3 OpenProj пример Гант дијаграм (дијаграм за шипки). 16 7.1 Пример за протокол за акција. 21 7.2 Кориснички интерфејс RapidSVN. 23 IV
Во оваа семинарска работа општо се занимавам со планирање на веб-проекти во пракса. Наидов на оваа тема преку мојата работа во itemis AG. Мојата работа беше таму да развијам веб-базирана услуга за кратки URL-адреси, особено за itemis AG. Овој проект траеше целиот период од три месеци на мојата активност и бараше многу од мене во однос на планирањето. Така, добив идеја да разгледам подетално предмет на планирање веб-проекти. На овој начин, би сакал критички да ги испитам искуствата што ги направив и да добијам одредена компетентност во самото планирање.
2 Вовед Во продолжение, семинарскиот труд се занимава со основниот пристап кон веб-проектите и аспектите што треба да се разгледаат. Не станува збор за прецизно распоредување, туку за сензибилизација за најважните фактори при планирање веб-проект. Информациите и принципите за планирање опишани во следните поглавја во основа можат да се применат на кој било вид веб-проект. Сепак, фокусот е повеќе на средни и големи проекти. Се обидувам да ви дадам широк преглед на планирање веб-проекти и сепак, секој сега и тогаш, детално опишувам неколку техники/методи. 1
3 Веб-проекти воопшто 3.1 Зошто воопшто да планирате? Бројни студии покажаа дека проектите пропаѓаат главно поради слаба комуникација помеѓу инволвираните и слаба подготовка на проекти. Честопати тоа е исто така недостаток на ресурси или претпоставки кои се премногу оптимистички расположени за текот на проектот. Сл. 3.1 прикажува уште неколку причини за неуспех на веб-проекти. Слика 3.1: Зошто проектите пропаѓаат Со цел да се спротивстават на овие фактори, кои честопати доведуваат до неуспех на проектот, некој ги планира своите планови на структуриран начин. Развојот на план исто така гарантира дека можете побрзо да реагирате на новите барања и да ги процените можните ефекти навремено. Покрај тоа, целите на веб-проектите честопати се нејасно формулирани и бараат дополнителни спецификации. Но, квалитетот и напорот исто така не се лесни за мерење во нематеријален проект, што доведува до натамошен проблем со цената 2
5 Дефиниција на проектот 5.1 Заинтересирани страни Заинтересирани страни е термин за сите луѓе кои се вклучени, погодени или заинтересирани за вашиот проект. Треба да ги дефинирате сите засегнати страни во вашиот веб-проект и да ги ставите во групи. Групите тогаш би можеле на пр. биде: 1. Менаџмент 2. Управување со проект од клиент 3. Тим на проект 4. Управување со производ од клиент 5. Уредување од клиент 6. Маркетинг од клиент 7. Целна група од клиент (купувачи, хобисти, експерти, деца и сл.) Тогаш тоа би било предност ако размислите за следниве прашања: 1. Што очекуваат соодветните групи на засегнати страни од резултатот на проектот? 2. Како се засегнати индивидуалните групи заинтересирани страни од резултатот на проектот? 3. Колку се моќни индивидуалните групи заинтересирани страни? 4. Која е нивната релевантност за вашиот проект? 5. Врз основа на резултатите од прашањата 1 до 4, кој тип на комуникација е неопходен за оваа засегната група? 6. Како би сакале вие, како проект-менаџер, да комуницирате со оваа група? Кога сте одговориле на овие прашања, резултатите може да се визуелизираат добро во комуникациска матрица, како што може да се види на сл. 5.1. 7-ми
ГЛАВА 5. ДЕФИНИЦИЈА НА ПРОЕКТОТ Слика 5.1: Пример матрица за комуникација (содржина: www.t3n.de) 8
ГЛАВА 5. ДЕФИНИЦИЈА НА ПРОЕКТОТ 5.2 Опсег на функции Ако сте решиле да ја имплементирате вашата идеја за проект по обемни и критички размислувања, време е да ги дефинирате сите функционални барања на вашата веб-страница. Најдобар начин да го направите ова е да ги поделите барањата на мора, опционални и посакувани критериуми и да снимате точно кога е исполнето соодветното барање. Задолжителните критериуми мора да бидат исполнети по завршувањето на проектот. Од друга страна, изборните критериуми треба да бидат исполнети ако е можно, но не мора. Посакуваните критериуми не се неопходни за главната задача на веб-страницата, но би биле корисни. На крајот, треба да се создаде таканаречен прирачник за производство (сториборд) со детален опис на сите функции на вашата веб-страница. Слика 5.2: Пример дијаграм за употреба, Покрај тоа, треба да ги претставите сите можни случаи на употреба во дијаграмот за употреба како што е прикажано на Сл. 5.2, од една страна да внесете структура во вашиот развој и од друга страна да дефинирате какви било почетни објекти и методи. Создавањето на графиконот ве принудува и на: 9
ГЛАВА 5. ДЕФИНИЦИЈА НА ПРОЕКТОТ Квалитетот не се цени толку на почетокот, колку фактор како што е времето или функционалниот опсег на проектот. Тоа е затоа што не е толку лесно да се измери квалитетот. Тешко е да се измери, како спецификација за време или низа функции во апликацијата. Како и да е, квалитетот е од огромно значење и треба да се цени максимално. 11
ГЛАВА 5. ДЕФИНИЦИЈА НА ПРОЕКТОТ 5.6 Магичен квадрат Овие четири својства на проектот, кои сега треба да ги дефинирате, можат да бидат прикажани шематски како што е прикажано на Слика 5.3. Слика 5.3: Магичен квадрат или ѓаволски квадрат Овие четири фактори заедно формираат поле на напнатост. Ако на пр. обидете се да ги намалите трошоците во вашиот проект, ќе биде тешко да се одржи планираниот квалитет. Или, ако планирате да го завршите проектот побрзо од планираното, функционалноста може брзо да се изгуби. Целта на планирањето на проектот е да се минимизираат параметрите на оптоварување (трошоци и време) и да се максимизираат параметрите за изведба (квалитет и функционалност). Не е невообичаено да се прават компромиси. 12-ти
6 Планирање 6.1 Структура Кога ќе го дефинирате проектот целосно, време е да го структурирате. За да го направите ова, целиот проект е поделен на работни пакети со помош на планирање на структурата на проектот, што може да се спроведе и контролира независно. Демонтирањето продолжува сè додека не можат јасно да се доделат сите работни пакети на група за развивачи или на личност и обемот на работа на пакетот да биде јасно доделен. На слика 6.1 можете да видите типичен пример за структура на распаѓање на работата. Слика 6.1: Пример план за структура на проектот (содржина: www.t3n.de) При дефинирање на работен пакет, треба да бидете сигурни дека тој е технички јасно разграничен од другите за да се избегне подоцнежен паралелен развој. Покрај тоа, треба да биде можно да се спроведе работниот пакет во јасна временска рамка. Треба да се формулира на таков начин што резултатот што може да се провери е достапен по завршувањето. Со мојот проект во itemis AG, не ми беше лесно да создадам ваква структура за разградување на работата, бидејќи не можам јасно да одделам некои работи. 13-ти
ГЛАВА 6. ПЛАНИРАЕ 6.2 Проценка на трошоците Кога ќе ги одредите сите работни пакети за вашиот веб-проект, тогаш треба да го процените времето потребно за секој поединечен пакет во таканаречената проценка на напорот. Бидејќи сè уште сте на самиот почеток на вашиот проект, веројатно ќе ви биде релативно тешко да го процените времето потребно за одделните работни пакети. Затоа, би сакал да ја искористам оваа можност да ве запознаам со испробаниот метод што го запознав во itemis AG. Тоа е таканаречениот метод на Перт. Со методот Pert, напорот за секој работен пакет се проценува во три варијанти: 1. најдобар случај Ја одразува вредноста ако сè може да се обработи без проблеми и без обука. 2. просечен случај Дали вредноста се очекува со нормално спроведување со одредено време на обука. 3. најлошо случај Го дефинира случајот во кој еден проблем го следи следниот. Просечниот случај има четири пати поголема тежина од другите два случаи. најдобра случај + 4 просечна случај + најлоша случајна очекувана случај = 6 На слика 6.2 можете да видите пример за проценка на напор на работен пакет користејќи го методот Pert. Слика 6.2: Пример во Excel за методот Pert (проценка во три точки) 14
ГЛАВА 6. ПЛАНИРАЕ може да опфаќа поддршка за планирање. Меѓу другото, тие ве поддржуваат во: 1. Создавање структура за разградување на работата 2. Создавање план за проект како на слика 6.3 3. Создавање и визуелизација на зависности во работни пакети Не можам да ти кажам. Тоа првенствено се заснова на комплексноста на проектот, а со тоа и на потребните организациски и плански напори. Ако вашиот проект е многу сложен, препорачувам комерцијален производ како што е Да се користи MS-Project. Ако не е толку обемно, би препорачал образец за Excel или OpenProj. За време на мојата пракса во itemis AG, ја креирав структурата за распаѓање на работата, заедно со проценката на напорот (метод Pert), во образец на Excel. 17-ти
ГЛАВА 7. КОНТРОЛА И КОНТРОЛА Слика 7.2: Интерфејс RapidSVN 23
8 Заклучок 8.1 Тест за прифаќање Пред да го завршите вашиот веб-проект, треба повторно да го тестирате опширно. Идеално, овие треба да бидат тест случаи што ги дефиниравте на почетокот на дефиницијата на проектот. Исто така, треба да одвоите една недела за критички да го испитате квалитетот и разбирливоста на дизајнот. Притоа, вознемирувачките ситници честопати може да се решат без напор и со малку дополнителен напор. 8.2 Конечна анализа на проектот Кога ќе го завршите тестот за прифаќање и сите проблеми со забите се отстранети, треба да направите финална анализа на проектот со преглед на вашиот веб-проект. Во оваа крајна анализа, тогаш ги споредувате планираните и реалните податоци едни со други, како и спроведувањето на функционалните и нефункционалните барања. Исто така, треба да проверите дали се исполнети сите рокови и како беше соработката во тимот за развој. Врз основа на резултатите, тогаш треба да бидете во можност да одлучите што евентуално треба да се смени или задржи во идните проекти. Не заборавајте да ги документирате вашите наоди од веб-проектот. 24
9 Заклучок Сумирајќи, велам дека од суштинско значење е да се планираат поголеми веб-проекти сеопфатно, бидејќи тоа ви помага да ги следите работите. Напорот што го вложувате во вашиот веб-проект на почетокот, обично секогаш се исплати на крајот. Ако правилно планирате, тешко дека треба да се запрашате што понатаму за време на развојот, бидејќи имате фиксен план што го следите. Ова доведува до заштеда на време и избегнување конфликти. Со презентирани сите фази и методи за планирање веб-проекти, се подразбира дека не можете да ги примените 1: 1 на ист начин за секој проект. Секогаш зависи од индивидуалната комплексност на веб-проектот, барањата и очекувањата на клиентот. 25-ти
10 Библиографија [Ang10] [Gri10] Анжермаер, Др. Г.: Специјалното списание на Интернет за успешно управување со проекти - фактори на успех. http://www.projektmagazin.de/glossar/gl-0398.html, 2010 Грифан, проф. Д: Предавање за управување со проекти за проектниот програм. 2010 [Ham09] Чекан, проф. Д-р. Н.: Планирајте, дизајнирајте и имплементирајте веб-страници. Спрингер, 2009 [Хоп10] Хоп, Мајкл: „совршената веб-страница“ како изгледа? http://www.wwweb-solutions.de/perfekte-website.html, 2010 [KW10] [Мар10] КонзептВелт.де: проект за планирање на проект, почеток на концепт за воведување проект. http://www.konzept-welt.de/konzepte/projektplanung.html, 2010 Мартин, Тобијас: Почетното планирање и комуникација како клуч за успехот Успешно изведување на веб-проекти од А до Ш. http://t3n.de/magazin/anfangsplanung-kommunikation-schlussel-erffekt- 223111 /, 2010 [Sch10] Шнајдер, Патрик: Концепт. http://item.is/konzeption, 2010 [SEL10] SELFHTML: планирајте веб-проекти. http://de.elfhtml.org/projekt/planen.htm, 2010 [Zen10] Zentec.de: Индикатори за успешни технолошки проекти - 10 индикатори за успешни проекти. http://www.zentec.de/226-0- истражувачки проекти-индикатори за успех.html, 2010 26
11 Доверба со ова изјавувам дека ја напишав оваа семинарска работа независно и без надворешна помош и дека не користев други извори или помагала освен наведените. Датум, потпис 27