Планиране на уеб проекти на практика - PDF безплатно изтегляне
Университет за приложни науки Гелзенкирхен Зимен семестър 2010/11 Семинарна работа Планиране на уеб проекти на практика Лектор: проф. Д-р Hammer Изпратено от: Karsten Nolte Bilholtstr. 40 59399 Olfen Телефон: +49 2595 385679 E-Mail: [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. С метода на Pert усилията за всеки работен пакет се оценяват в три варианта: 1. най-добрият случай Отразява стойността, ако всичко може да бъде обработено без проблеми и без време за обучение. 2. среден случай Е стойността, която се очаква при нормално изпълнение с известно време за обучение. 3. най-лошия случай Определя случая, в който един проблем следва следващия. Средният случай има четири пъти по-голяма тежест от другите два случая. bestcase + 4 среден случай + най-лошия очакван случай = 6 На фиг. 6.2 можете да видите пример за оценка на усилията за работен пакет, използващ метода на Pert. Фигура 6.2: Пример на Excel за метода на Pert (оценка в три точки) 14
ГЛАВА 6. ПЛАНИРАНЕТО може да включва не само подкрепа за планиране. Наред с други неща, те ви подкрепят в: 1. Създаване на структура на разбивка на работата 2. Създаване на план на проекта, както е показано на фиг. 6.3 3. Създаване и визуализация на зависимости в работни пакети 4. Планиране на ресурси (кога кой служител какво прави?) Кой инструмент трябва да използвате за вашия уеб проект Не мога да ви кажа. Той се основава предимно на сложността на проекта и по този начин на необходимите организационни и планиращи усилия. Ако вашият проект е много сложен, препоръчвам търговски продукт като За да използвате 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] Angermeier, Dr. Г.: Специализираното списание в Интернет за успешно управление на проекти - фактори за успех. http://www.projektmagazin.de/glossar/gl-0398.html, 2010 г. Грифан, проф. Д.: Лекция по управление на проекти по проекта за програмиране. 2010 [Ham09] Hammer, проф. Д-р N.: Планирайте, проектирайте и внедрете уебсайтове. Springer, 2009 [Hop10] Hoppe, Michael: „Перфектният уебсайт“ как изглежда? http://www.wwweb-solutions.de/perfekte-website.html, 2010 [KW10] [Mar10] Konzept-Welt.de: проект за планиране на проекта концепция за въвеждане на проекта. http://www.konzept-welt.de/konzepte/projektplanung.html, 2010 г. Мартин, Тобиас: Първоначално планиране и комуникация като ключ към успеха Успешно изпълнявайте уеб проекти от А до Я. http://t3n.de/magazin/anfangsplanung-kommunikation-schlussel-erffekt- 223111 /, 2010 [Sch10] Schneider, Patrick: Concept. http://item.is/konzeption, 2010 [SEL10] SELFHTML: планирайте уеб проекти. http://de.selfhtml.org/projekt/planen.htm, 2010 [Zen10] Zentec.de: Индикатори за успешни технологични проекти - 10 показателя за успешни проекти. http://www.zentec.de/226-0- изследователски проекти-показатели за успех.html, 2010 г. 26
11 Affidavit С настоящото заявявам, че съм написал този семинарен доклад самостоятелно и без външна помощ и че не съм използвал други източници или ресурси освен дадените. Дата, подпис 27