Планування веб-проектів на практиці - PDF скачати безкоштовно
Університет прикладних наук Гельзенкірхен Зимовий семестр 2010/11 Робота в семінарі Планування веб-проектів на практиці Лектор: Проф. Hammer Представлено: Karsten Nolte Bilholtstr. 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 за методом Перта (триточкова оцінка). 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. Це так званий метод Перта. За методом Перта зусилля для кожного робочого пакету оцінюються у трьох варіантах: 1. найкращий випадок Відображає цінність, якщо все можна обробити без проблем та без навчання. 2. середній випадок - це значення, яке очікується при нормальному виконанні з певним часом навчання. 3. гірший випадок Визначає випадок, коли одна проблема слідує за наступною. Середній випадок у чотири рази перевищує вагу інших двох справ. найкращий регістр + 4 середній регістр + найгірший очікуваний регістр = 6 На рис. 6.2 ви можете побачити приклад для оцінки зусиль робочого пакету з використанням методу Перта. Малюнок 6.2: Приклад методу Перта в Excel (трибальна оцінка) 14
ГЛАВА 6. ПЛАНУВАННЯ може не лише охоплювати підтримку планування. Серед іншого, вони підтримують вас у: 1. Створенні структури розподілу робіт 2. Створенні плану проекту, як на рис. 6.3 3. Створення та візуалізації залежностей у робочих пакетах 4. Плануванні ресурсів (коли який співробітник що робить?) Який інструмент вам слід використовувати для вашого веб-проекту Я не можу тобі сказати. Це в першу чергу базується на складності проекту і, отже, на необхідних організаційних та планувальних зусиллях. Якщо ваш проект дуже складний, я рекомендую комерційний продукт, такий як Використовувати MS-Project. Якщо це не так обширно, я б рекомендував шаблон Excel або OpenProj. Під час стажування в itemis AG я створив структуру розподілу робіт разом із оцінкою зусиль (метод Перта) у шаблоні 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, проф. Д-р. Н.: Плануйте, розробляйте та впроваджуйте веб-сайти. Springer, 2009 [Hop10] Хоппе, Майкл: «Ідеальний веб-сайт», як він виглядає? http://www.wwweb-solutions.de/perfekte-website.html, 2010 р. [KW10] [березень 10] Konzept-Welt.de: планування проекту старт проекту концепція введення проекту. 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.selfhtml.org/projekt/planen.htm, 2010 [Zen10] Zentec.de: Показники успішних технологічних проектів - 10 показників успішних проектів. http://www.zentec.de/226-0- дослідницькі проекти-показники успіху.html, 2010 р. 26
11 Свідчення. Цим я заявляю, що написав цю семінарську роботу самостійно та без сторонньої допомоги, і що я не використовував жодних джерел чи допоміжних матеріалів, крім зазначених. Дата, підпис 27