3. Управління мультимедійним проектом icon

3. Управління мультимедійним проектом




Скачати 329.37 Kb.
Назва3. Управління мультимедійним проектом
Дата12.09.2012
Розмір329.37 Kb.
ТипДокументи

3. Управління мультимедійним проектом


Створення електронного мультимедійного видання має багато спільного з проектуванням програмного забезпечення, особливо в графічних операційних середовищах. Тому звичайно в цьому контексті вживається термін мультимедійний проект. Ми розглянемо лише деякі найважливіші моменти роботи над мультимедійним проектом. За окремими деталями радимо звертатися до підручника [21], на жаль, важко доступного, що і послужило причиною включення цього розділу до посібника. Мультимедійний проект розкладається на серію задач по створенню окремих медіа та програмно-технічну компоненту, що їх інтегрує. Існують хардверні проекти, метою яких я визначення, демонстрація та впровадження в організацію мультимедійного базового інструментального устаткування, наприклад класів для забезпечення відео конференцій з замовним інтерфейсом користувача. Існують софтверні проекти, які полягають в інтегруванні медійних компонент в прикладну програму, здатну виконуватися на звичайній хардверній платформі.

Мультимедійний проект може бути комерційним. В цьому випадку він полягатиме у створенні електронного видання, призначеного для роздрібної торгівлі. Мультимедіййний проект може бути замовним: створене видання передадається замовнику, який використовує його на власний розсуд. Ми зупмнимося на замовних софтверних проектах, для виконання яких доводиться збирати команду. Можна було б уявити собі такого мультимедійного професіонала, здатного виконати будь-який проект самотужки, але навіть у цьому випадку тими ж залишаються взаємини з замовником та етапи розробки.

Замовником вважатимемо будь-кого, наділеного владою управляти часом і бюджетом та правом затвердження проектних рішень. Замовник може бути як внутрішнім, наприклад, сусідній відділ або, навіть, керівний орган власного підприємства того чи іншого рівня, так і зовнішнім. Єдина відмінність між ними може полягати в оформленні контракту, якого у випадку внутрішнього замовника може не бути зовсім. Остерігайтеся внутрішніх замовників, які розраховують на результати, досягнуті поза часовими та ресурсними обмеженнями. Тому навіть у випадку відсутності контракту, корисно складати номінальний план затрат. Корисно, щоб замовник усвідомлював, що ваша робота теж споживає кошти. Це змусить його краще продумувати замовлення та зважати на вартість виправлень.

Цикл замовного проекту

Оцінка проекту: Проект починається етапом, на якому визначається його призначення і суть. Цього досягають шляхом розуміння потреб замовника, яке послужить підставою для пошуку адекватного мультимедійного вирішення. Визначення проекту звичайно робиться нашвидкоруч, а тому в ньому виходять головним чином з припущень, а не фактів. Тому етап називається оцінкою проекту.

На підставі оцінки проекту та часових обмежень на його виконання можна приступити до створення проектної пропозиції, в котрій будуть визначені об’єми робіт відповідно до виділених на них коштів і часу.

Після прийняття пропозиції замовником проект перетворюється на дійсність. Тепер роботу над ним можна планувати як мережну діаграму, що визначатиме порядок виконання окремих операцій, а також ті з них, що можуть виконуватися одночасно.

Необхідно визначитися щодо стосунків з замовником, бо саме від нього залежатимуть цінності та рішення, необхідні для продовження роботи. Визначивши спосіб діяльності та уклавши контракт, де будуть зафіксовані зміст проекту, його платформа, види медіа, технологія його виконання, інтерфейс, тощо. Ми перейдемо до проектування, або власне, виробництва проекту. Виробництво потребує персоналу, який доведеться найняти або використати наявний. Як тільки з’являється команда, виникає проблема менеджменту.

Робота складається зі створення матеріалів — текстових, графічних, аудіо, відео — та їх інтеграції в мультимедійному виробі. Одночасно розгортається діяльність по адмініструванню авторських прав, поки що зовсім туманних стосовно електронних продуктів. Одночасно розпочинається тестування відповідності компонент їх специфікаціям, далі виникають проблеми інтеграції та тестування, випробування платформи або платформ.

Пам’ятаємо, що замовник неохоче підпише акт прийому проекту, бо це позбавить його можливості подальшого впливу на виконавця. Тому треба добре визначати умови готовності проекту, за яких замовник не зможе більше зволікати з його прийомом. Але необхідно планувати і деякі надмірні з точки зору замовника дії, наприклад, архівування результатів у спосіб, придатний для майбутніх модифікацій. Замовник може звернутися до нас ще раз, окремі компоненти проекту можна використати в наступних розробках, якщо подбати про їх збережність.

Етапи розробки:

  1. Оцінка проекту

  2. Проектна пропозиція

  3. Підготовка контракту

    1. Погодження змісту

    2. Вибір техніки і платформ

    3. Погодження інтерфейсу

  4. Укладення контракту

  5. Виробництво

    1. Набір команди

    2. Підготовка та обробка оригіналів

    3. Придбання прав

    4. Виготовлення макету

    5. Інтеграція та інтерфейс

    6. Тестування

  6. Завершення

    1. Передача замовнику

    2. Архівування

В мультимедійному проекті разом працюють люди з різною підготовкою та різними досвідом і баченням процесів розробки. Кожна із індустрій змісту створила свій шлях виготовлення медій. Керівник проекту повинен розуміти кожного з них.

Головна проблема управління будь-яким проектом — це проблема балансу коштів, часу і якості, причому остання виступає як би невидимою компонентою проектної документації. Якщо ми глянемо на таблицю, то ми побачимо деякі зі способів узгодження якості з замовником, прийняті в різних виробництвах. Наприклад, в розробці програмного забезпечення — це функціональні специфікації і макетування, в видавничій справі — рецензування, тощо. Загалом же в ринковій економіці ринок дає остаточний вердикт щодо успішності продукту.

В замовному мультимедійному проекті якість будемо розуміти як відповідність змісту засобам (treatment) його відтворення, зафіксовану в договорі. Це визначення передбачає діловий, а не фаховий підхід до якості. Кожен фахівець має своє уявлення про вищу якість, але навіть за ділового підходу рамки для виготовлення якісного продукту досить значні. Ніколи не піддавайтеся спокусі внести невеличкі зміни до проекту.

Оцінка проекту

Дуже корисно заповнити анкету, яка дасть вам уявлення про замовника та його наміри. Анкети завжди корисні тим, що в них передбачені питання, які інакше можна забути.

Перш за все з’ясуємо попередній досвід замовника. Якщо можливо, зв’яжемося з виконавцями попередніх замовлень, це допоможе встановити, чому замовник віддає перевагу. Тут же записуються вимоги замовника до проекту.

Особливо важливо вірно визначити тип проекту. Інтранетівський проект ставить свої вимоги до шаблонів для сторінок підрозділів, екстранет — проблеми прав доступу і захисту. Гібридний проект передбачає підготовку двох типів матеріалів і даних для кожного з каналів розповсюдження.

Інформація про сектор ринку, до якого належить замовник, дає уявлення про потенційний розмір адміністративних накладних витрат. Складно організовані бюрократичні установи будуть довго відповідати на будь-який ваш запит.

Склад проекту дає можливість уявити собі компоненти, наприклад, бази даних, механізми розрахунків, аудиторію. Ранжирування компонент дає уявлення про першочергові задачі та можливі відстрочки. Розмір дає можливість оцінити кількість матеріалів для кожного з розділів. Кожен сайт приблизно раз в півроку підлягає переробці. Причина — розвиток компанії, розширення кола користувачів, поява нових технологій.

Супровід сайту замовником може передбачати витрати на навчання його персоналу. Крім того сайт вимагає оновлення, яке повинно виконуватися якщо не щоденно, то щотижнево. Правильно визначена відповідальність допоможе уникнути непорозумінь у майбутньому.

Визначення вигод, які очікуються від сайту, дозволить структурувати інформацію замовника так, щоб зосередити увагу користувача на найважливішому.

Інформація про співвідношення типів медіа дасть уявлення про сподівання замовника щодо змісту його сайту. Якщо замовник має власні готові матеріали, то це може здешевити і прискорити процес розробки.

Копію складеної анкети надсилають замовнику. Протягом виконання проекту можуть мінятися співробітники і їх бачення проекту. Письмове фіксування вимог до проекту служитиме підставою для віднесення затримок при перегляді проекту на рахунок замовника.

Анкета оффлайнового проекту додатково може містити інформацію про тираж та платформу.


^

Анкета замовного онлайнового проекту


Назва або номер проекту




^ Контактна інформація

Замовник




Адреса




Тел.




Факс




Email




Web-site




^ Контактні особи

Імена




Посади













Попередній досвід у мультимедіа

Онлайн

немає




незначний




певний




досвідчений




Оффлайн

немає




незначний




певний




досвідчений




Характеристика попереднього досвіду

Онлайн

Продукт

Виробник



















Оффлайн

Продукт

Виробник



















Специфікація проекту замовником




Тип онлайнового проекту

Internet




Hybrid Web/CD




Intranet




Extranet




Створення нового сайту




Побажання щодо доменного імені




Доповнення/заміна існуючого сайту







Сектор ринку

Комерційний




Корпоративний




Адміністративний




Навчальний







Склад проекту

Профіль компанії

Ранг

Об’єм (малий,середній,значний)

Збір інформації










Розповсюдження інформації










Роздрібна торгівля










Маркетинг/реклама










Переробка сайту










Інше


































^ Супровід сайту:

замовником




розробником




^ Бажані цілі (не визначаються з причини:

)




Вигоди організації полягатимуть в




1







2







3







Вигоди користувача полягатимуть в




1







2







3













Доступ та використання інформації




Інтернет




Доступ до якої інформації




Загальне коло користувачів










Інші:






















Інтранет










Власні співробітники










Керівники










Продавці










Інші:






















Екстранет










Кількість приєднаних сайтів










Хто потребує приєднання




























Співвідношення типів медіа за оцінкою замовника







Текст




%

Графіка




%

Анімація




%




Аудіо




%

Відео




%










Наявні матеріали




Тексти




Контактна особа







Бази даних




Контактна особа







Графіка




Контактна особа







Аудіо




Контактна особа







Відео




Контактна особа







Відповідальний за наповнення від змовника













Час на розробку




Припущення замовника




місяців

Дата початку










Дата закінчення







Інші фіксовані терміни (макет, демонстрація, презентація, тощо)





































Бюджет




сума







Відповідальний за фінансування







Телефон







Email







Анкету склали




Від замовника




Посада







Від підрядника




Посада







Дата









Проектна пропозиція

Проектна пропозиція готується на підставі аналізу інформації, одержаної від замовника, та виходячи з досвіду розробника. Її мета — дати замовнику чітке уявлення вашого підходу. На підставі проектної пропозиції замовник приймає рішення про доцільність проекту. Це рішення значною мірою випливає з того, наскільки переконлива проектна пропозиція з точки зору потреб замовника.

Звичайно замовник влаштовує тендер, а тому варто подумати про те, чим можна привернути до себе особливу увагу. Звичайно, рішення повинні бути гарантованими з точки зору часу та коштів, але варто запропонувати дещо, що може навіть трохи виходити за рамки можливого, але є особливо новим або привабливим.

Головна проблема очевидна. Вам доведеться планувати витрати, виходячи з неповної інформації. Повною вона стане лише після закінчення розробки. А тому необхідно мати можливість для компенсації непередбачених обставин і витрат, наприклад, сплати послуг третьої сторони або придбання авторських прав.

Зміст проектної пропозиції:
^

Вступ та резюме (general introduction and executive summary)


Крім короткого викладу проекту, достатнього для того, щоб керівні працівники могли б одразу переходити від вступу до бюджету, тут повинно бути обґрунтування доцільності мультимедійного продукту.
^

Визначення цілей замовника


Цей розділ повинен переконати замовника в тому, що ви серйозно попрацювали над його проблемами, розумієте його справу. Дуже корисно аргументувати тут позитивний вплив інтерактивних медіа на розвиток справи замовника.
^

Визначення потреб користувача


Спирається на визначені замовником потреби користувача. Їх дуже корисно доповнити аргументами з вашого власного досвіду, навести приклади подібних попередніх розробок.
^

Визначення та обґрунтування підходу


Посилаючись на цілі замовника і потреби користувача, пояснюєте, чому запропонований підхід задовольняє першому і другому. Готуючись до проекту, корисно показати замовнику декілька продуктів та уважно вислухати його думку про них, зокрема про структуру проектів та організацію інтерфейсу. Це допоможе приймати рішення, виходячи з потреб замовника, а не власних преференцій.

Найважливіша заголовна сторінка (меню). Вона повинна визначати сподівання, структуру та імідж всього видання. Вона повинна чітко визначати місію видання та давати повне уявлення про все, що в ньому пропонується. Користувачу потрібне швидке і просте розуміння змісту видання.

Замовники звичайно недооцінюють, наскільки складно правильно класифікувати видання, визначити його категорію та підготувати резюме. Все це стане вирішальним для ефективного пошуку вашого видання засобами пошукових серверів.

Непогано було б уже запропонувати макет заголовної сторінки (меню), але зовсім обов’язково логічну схему видання у вигляді діаграм, знову ж відмічаючи їх зв’язок з цілями замовника і потребами користувачів.

Кожен розділ видання характеризується з точки зору його розміру, часових оцінок на його розробку, типів мультимедійних компонент та тривалості їх перегляду. Варто попрацювати над тим, щоб складність та розміри розділів справили належне враження на замовника. Від цього залежить фінансування.

Розміри можна визначати як малий (5-10 сторінок), середній (10-20 сторінок), великий (20-30 сторінок) та дуже великий (понад 30 сторінок). Звичайно, непросто оцінювати складність розділу, тому її варто розділити на три частини: складність медіа, змісту, програмування.

Оцінюючи час, крім часу на розробку необхідно врахувати час на тестування та на переробку, а можливо також на дослідну експлуатацію пілотного проекту. Якщо замовник відмовляється від дослідної експлуатації, зафіксуйте відмову письмово, бо виготовлення пілотного проекту та організація дослідної експлуатації з можливою наступною переробкою вимагає додаткових затрат.

Оцінки затрат дадуть замовнику можливість приймати рішення про можливі скорочення або доповнення.
^

Можливі варіанти підходів


Тут можна подати додаткові можливості, що не увійшли до основного проекту з тих чи інших обмежень. Варто показати їх значимість для користувача. Це робота на перспективу.
^

Структура проекту


В цьому розділі зводяться воєдино всі діаграми, які відображають структуру проекту.

Кадрове забезпечення проекту


Тут визначається склад і ролі учасників проекту. Окремо виділяється постійний склад та додаткові кадри, необхідні на окремих етапах проекту. Звичайно цей розділ викликає особливе здивування замовників, зокрема за кількістю ролей. Ясно, що деякі з ролей вам вдасться сумістити в одній особі, але не ставте собі цих обмежень на етапі пропозиції. Нехай це залишиться можливістю для маневру на чорний день.
^

Календарний план робіт


На цьому етапі досить вказати дати початку і закінчення найважливіших робіт, а також дати ключових подій. Передбачити час і бюджет на випробування проекту.
^

Кошторис проекту


Кошторис залежить від стандартів підприємства-виконавця і замовника.

Обмеження


Оскільки проект ґрунтується на певному обмеженому уявленні про його зміст, обумовлюється можливість внесення змін до проекту. Зміни можуть бути викликані також недостатньою якістю матеріалів, що надаватимуться замовником. Нові витрати можуть бути викликані необхідністю освоєння нових технологій, що з’являться під час виконання проекту.

Особливо відмічається пряма залежність дати закінчення проекту від можливості його своєчасного початку. Остання часто затримується замовником (несвоєчасна передача матеріалів, затвердження документів, виділення ресурсів). Потім замовник наполягає на вчасному закінченні робіт, якщо ви не потурбувалися сформулювати відповідне обмеження і документувати затримки з вини замовника.
^

Підготовка контракту


Контракт — це угода, що визначає інтереси та відповідальність сторін. Мультимедійний контракт передбачає багатьох учасників і складається з багатьох документів. Головна причина полягає у різнорідності процесів, задіяних в проекті.

Замовник не схильний сплачувати значні суми за зовсім зрозумілі роботи, тому проект повинен бути по можливості максимально конкретним. Але багато рішень прийматимуться по ходу. Скажімо, рішення виготовити непередбачений раніше малюнок або, більше того, відеосюжет, може значно вплинути на кошторис. Тому виконання проекту — це взаємодія підрядника і замовника, де кожен з них має власне коло відповідальності.

Особливої уваги заслуговує домовленість про внесення змін до проекту (change requests). Розробка програмного забезпечення накопичила значний досвід в управлінні проектними змінами, оскільки безконтрольні версії можуть просто зруйнувати проект. Варто домовитися про форму заявки на внесення змін, процедуру її заповнення, затвердження та виконання.

Успішному виконанню проекту допомагає усвідомлення своїх обов’язків як підрядником (виконавцем проекту), так і його замовником.
^

Обов’язки менеджера проекту (Project manager)


  • Працювати з клієнтом задля вироблення вироблення взаємо прийнятної пропозиції, що описує зміст проекту, час виконання та бюджет.

  • Розробити детальний графік робіт (сумісний з погодженими датами старту та завершенням проекту), який описує стадії виробництва.

  • Контролювати та документувати час, витрачений на виконання проекту.

  • Інформувати клієнта про:

  • статус проекту, загальний прогрес, наприклад письмовий підсумок за місяць тощо;

  • Затримки, спади виробництва та заходи для виправлення ситуації;

  • будь-які запропоновані зміни до специфікіцій, яких вимагають технічні або дизайн фактори, щойно такі з’являються;

  • Будь-які інші фактори, що впливають на процес виконання проекту, щойно такі з’являються.

  • Забезпечувати виробництво кожного компоненту проекту згідно з відповідними технічними специфікаціями.

  • Узгодити структуру проекту та умови виробничого процесу з відповідальною особою зі сторони замовника та забезпечити підписання відповідних документів.

  • Узгодити зміст / сценарій з замовником та підписання відповідних документів.

  • Узгодити кількість днів, протягом яких замовник переглядає стадію проекту та приймає рішення.

  • Забезпечити кінцевий строк

  • Останніх змін до сценарію/змісту проекту (кількість разів, коли замовник може вносити зміни може залежати від загального часового обмеження і відповідно впливати на нього)

  • Остання дата для внесення змін до будь-яких графічних елементів

  • Остання дата зміни відео-елементів

  • Остання дата внесення будь-яких змін до текстів

  • Забезпечити підписання акту здачі робіт замовником
^

Обов’язки замовника (клієнта)


  • Готувати короткі викладки для розробника

  • Працювати разом з розробником над детальною специфікацією

  • Інформувати Менеджера Проекту про будь-які фактори, що негативно впливатимуть на проект, щойно такі матимуть місце.

  • призначити особу в своїй організації, що зможе присвячувати свій час впродовж виконання проекту, і чий підпис буде обов’язковим

  • узгоджувати будь-яку тему з експертами компанії, які будуть задіяні та забезпечити їхню співпрацю за часом, відведеним у відповідності з графіком робіт.

  • Триматися в рамках погодженого часу, відведеного на прегляд та винесення рішень, або, в іншому випадку, погоджуватися з часом на виконання внесених змін, додаткових фінансових та якісних втрат.

  • Погоджуватися з тим, що будь-які зміни, внесені після відведеного часу або відповідних підписаних документів, впливатимуть на час, витрати та якість проекту.

  • Сприяти розробнику в доступі до будь-яких матеріалів або людей в організації замовника, що допомагатимуть виконанню проекту.

Важливо чітко визначити етапи проекту, та механізми їх затвердження. Замовник може зволікати з затвердженням, підрядник повинен нагадувати про вплив затримок на кінцевий термін проекту.

Існує певна проблема з остаточною здачею проекту. У тих випадках, коли передбачено тиражування, воно дає чітке обмеження в часі. Веб-сайт можна опублікувати задовго до закінчення проекту, а потім постійно змінювати на вимогу замовника. Треба потурбуватися про процедуру передачі готового результату. Нею може бути передача еталонного диску з екземпляром сайту, або розміщення сайту на постійному місці.
^

Погодження змісту


Змісту належить головна роль у виданні. Якщо користувача не цікавить зміст, то спосіб його подачі стає несуттєвим. Певний виняток можуть складати хіба що ігри, головним компонентом яких служать дії. Ми ж розглядатимемо видання змістовні, де під змістом розуміється повідомлення або інформація, що міститься у виданні, а також її структурна організація.

Інший вимір визначається технікою видання. Це засоби і способи обробки інформації, застосовані в проекті: типи медіа, інтерактивний інтерфейс, спецефекти, засоби комунікації, тощо. Причина невдачі багатьох проектів полягає у нехтуванні змістом на користь техніки. Головна задача техніки, по суті своїй другорядна, — сприяти кращому сприйняттю змісту аудиторією, на яку його розраховано.

Складність підготовки змісту електронного видання полягає у відсутності автора. Значна частина змісту надається замовником вже готовою. Кого вважати відповідальним за зміст електронного видання? В інших галузях — це письменники, редактори, сценаристи, аналітики. Художникам, хіба що за винятком мультиплікаторів, звичайно належить другорядна роль інтерпретування чужого тексту.

Розробка програмного забезпечення не відноситься до індустрій змісту, а тому не потребує сценарію. Хоча може мати сценарії користувача. Зокрема в навчальних або розважальних програмах з’являється категорія змісту, зайняття яким виділяються у окрему роль. Цікаво, що з ростом складності програм, страшенно розростається їх довідкова служба, цілі армії докуметувальників зайняті створенням технічної документації, зокрема електронної. Розвиток Веб привів до появи Веб-редакторів, професія яких має багато спільного із звичайними редакторами.

Розробника сценарію електронного видання називатимемо інтерактивним сценаристом. Він співпрацює з експертом у предметній області, пропонуючи йому загальну інтерактивну структуру видання і далі для кожного розділу деталізований зміст узгоджується з деталізованою інтерактивністю. Видання розкладається на компоненти, кожна з яких може мати свій набір медіа і свій колектив розробників. Саме складне — забезпечити цілісність кожного розділу і сукупну цілісність всього видання. Від першого фрагменту до останнього все повинно справляти враження єдиного видання. Важлива також часова виваженість компонент. Не може одна компонента тривати секунди, а інша — години, хіба що на це є особлива причина, зрозуміла користувачеві.

Інший аспект пов’язаний з широтою та глибиною охоплення теми. Не варто змушувати користувача проглядати або прослуховувати тривалий фрагмент деталізованої інформації, наприклад, історії Києво-Могилянської академії, якщо його цікавить просто її адреса або телефон. Цим електронне видання повинне істотно відрізнятися від телепрограми, яка передбачає лише один вимір перегляду. Треба вміти передбачати потреби користувача на ранніх стадіях розробки і протестувати свої припущення на наступних етапах.

Мультимедійний сценарій вимагає багатьох умінь, стосовних

  • прийняття рішень щодо релевантності матеріалу;

  • вибору підходящих типів медіа;

  • розподілу матеріалу за рівнями структури та типами медіа;

  • забезпечення узгодженості рівнів навігаційними схемами та діаграмами;

  • розуміння користувача та його намірів при виборі структури подачі матеріалу;

  • готовності та здатності співпраці з програмістами;

  • охоплення всього виробу, розкладеного на компоненти;

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

Остаточне рішення про потреб користувача приймає замовник, але він звинуватить не себе, а розробника, якщо користувач залишиться невдоволеним. При підготовці змісту варто потурбуватися про вивчення думки потенційних користувачів.

Оцінюючи цілісність змісту, даємо відповіді на кожне з питань, наприклад, за п’ятибальною системою:

  • загальне охоплення предмету;

  • широта охоплення;

  • глибина відтворення;

  • адекватність розподілу матеріалу між розділами;

  • спрямованість на аудиторію;

  • відповідність меті видання;

  • пропорційність розділів;

  • доступ до інформації в розділі;

  • перехресний доступ до інформації між розділами.

Затвердження змісту замовником варто передбачити покроковим, окремо затвердивши структуру видання з наступним затвердженням змісту кожного з розділів.
^

Вибір платформи


Під платформою ми розумітимемо як хардвер, так і софтвер, розрізняючи платформу розробки, в якій працює розробник, і платформу доставки, через яку виріб доходить до користувача. Між ними знаходиться засіб або медіум доставки. Наприклад, Веб складає мультимедійну систему доставки, яка функціонує на багатьох платформах, що задовольняють певним стандартам. Тому медіум доставки виділяється окремо від платформи доставки.

Може статися, що замовник сам визначає платформу розробки. Проблема розробника — поставити правильні питання, щоб найкраще зрозуміти потреби замовника:

  • виробник і тип машин

  • тип і продуктивність процесора

  • об’єм основної пам’яті

  • об’єм і швидкодія жорсткого диску

  • версія операційної системи

  • характеристики CD-ROM/DVD-ROM

  • мережні характеристики

  • швидкість ліній зв’язку

  • роздільна здатність екрану

  • кількість кольорів екрану

  • відеоапаратура

  • графічна апаратура

  • звукова апаратура

Практика розробки все частіше передбачає використання крос-платформ, зокрема при використанні авторських система, здатних виготовляти версії під різні платформи. Більше того, емуляція однієї платформи іншою взагалі приводить до поняття віртуальної машини доставки. Останнє може створювати свої проблеми, оскільки характеристики доставки на різних платформах можуть бути різними. Техніка управління платформенною залежністю дістала назву поступового скорочення можливостей системи (graceful degradation). Класичний приклад можна знайти у звичайному HTML. Якщо броузер не відтворює графіку, то остання підлягає заміні пояснювальними текстами.

Обираючи доставку офф-лайн, важливо правильно вибрати стандарт для компакт-диску відповідно до так званих “фарбованих” книг (червона, зелена, жовта оранжева або біла книга; ISO 9660, CD-ROM XA).


Доставка он-лайн ставить інші питання: швидкість доступу, оновлення, безпека, оплата в поєднанні з практично необмеженою ємністю.

Швидкодія каналу практично не підлягає впливу і не може бути передбачена. Але все ж при використанні аудіо і відео метаріалів перевага надається техніці прямого відтворення (streaming), а не перепису з наступним відтворенням. Особливо ефективними є механізми використання буферизації та кеш.

Платформа доставки в он-лайн не залежить не тільки від розробника, а звичайно і від замовника теж. Тому необхідно забезпечити багатоплатформенне тестування, враховуючи:

  • моделі комп’ютерів

  • об’єми основної пам’яті

  • типи і характеристики екранів

  • розміри жорсткого диску

  • наявність та відсутність розширень броузера (plug-ins)

  • типи та версії операційних систем

  • типи мереж

Якщо врахувати, що кожен з параметрів може набувати кількох значень, наприклад, 5, а всього параметрів може бути до 10, наприклад, 8, то кількість тестових випадків вимірюватиметься числом астрономічним, скажімо, 58 = 390 625. Тому платформи тестування необхідно уважно планувати.
^

Вибір медіа і техніки видання


Перш за все зростання кількості типів медіа приводить до зростання вартості проекту. Легкість доступу до онлайнових продуктів може створити ілюзію легкості та дешевизни їх розробки. Бюджет завжди є найбільшим обмеженням при виборі типів медіа. Другим обмеженням є наявність потрібних ресурсів: техніки, програмного забезпечення та належно підготовлених кадрів.
^

Вибір матеріалів та способів їх підготовки


Уявлення про проблеми виду матеріалів дає наступна таблиця
^
Вид матеріалу

Тип (Hi/Mid/Low-Q =високо / середньо / низькоякісні)

Вартість

Часові затрати

Примітки

Відео-матеріали

Акторська гра

Інтерв’ю
Документальні матеріали

Висока
Нижча сер.

Нижча сер.

Великі
Менші за сер.

Середні

Здобуття необхідних прав та дозволів може зайняти значний час

Аудіо-матеріали

Акторська гра
Інтерв’ю

Розповідь (аудіозапис)
Музика

Середня
Низька

Низька
Нижча сер.

Великі

Малі

Малі
Можна моментально

Якісне, акторське надиктовування тексту може виявитися досить дорогим

Відеоефекти

(створені за допомогою спец-обладнання)

3-D анімація (Hi-Q)

Анімація (Hi-Q)
Складні відеоефекти (Hi-Q)

Статична катринка (Hi-Q)

Висока

Висока

Висока

Висока

Менші за сер.

Менші за сер.

Малі
Малі

Еквівалентне відеоматеріалам при переносі на комп’ютер

Комп’ютерна графіка

3-D анімація (Hi-Q)
3-D анімація (Med-Q)
3-D анімація (Low-Q)
Статична катринка (Hi-Q)
Статична катринка (Med-Q)
Статична катринка (Low-Q)

Висока
Середня
Середня
Нижча сер. Нижча сер.

Низька

Великі

Великі

Великі

Середні

Малі

Малі

Часові затрати більші аніж на відеоефекти, але при великих кількостях матеріалів себе виправдовує


Фотографії

Кадри з фільмів
Цифрові фото
Готові фото

Нижча сер.

Нижча сер.

Нижча сер.

Менші за сер.

Малі
Можна моментально

Широкий вибір готового матеріалу за різними цінами. Можна також зробити фото своїми руками.

Тексти




Низька

Маленькі

Іноді може бути “дорогою”, якщо використовує спеціальні шрифти або потребує ліцензування

Перекладені матеріали

Саундтрек (з часовою розміткою)

Аудіозапис розповіді (з часовою розміткою)
Аудіозапис розповіді (без часової розмітки)
Текст (у обмеженому просторі)

Текст

Середня
Середня

Середня

Середня

Середня

Середні
Середні

Менші за сер.


Менші за сер.

Менші за сер.

Бажано перевіряти матеріали з експертом. Треба враховувати специфіку представлення текстів різними мовами.

Відео-матеріали


Відео використовує найбільше ресурсів, ніж усі інші засоби і може значно впливати на швидкість. А тому розмір відеозображення повинен задовольняти обмеженням на ресурси та відповідати змісту засобам відтворення та доставки.

Аудіо-матеріали


Роль звукових матеріалів невиправдано недооцінюється розробниками. Звук не вимагає надвеликих витрат, може заощаджувати надмірний ужиток тексту, підвищує виразність, але звук вимагає великої обережності.
^

Комп'ютерна графіка


Надзвичайно різноманітна за характеристиками та якістю. Ділиться на растрову та векторну, поєнуючи реалістичність і умовність. Незамінима з точки зору виразності. Як і відео значно залежить від пропускної здатності каналу.

Текст


Найважливіший елемент, що найширше використовується в усіх видах продуктів. Якість тексового оформлення повинна відповідати якості інших компонентів видання., що особливо важко в оффлайнових проектах. Дуже важливо правильно вибрати розташування, розмір і чіткість тексту.

Інтерфейс


Інтерфейс визначається структурою видання. Його будують за допомогою кнопок або пуктів меню, використовуючи дерева, вікна, гіпертекст, тощо. Загальна тенденція полягає у переході від текстів до піктограм, що дають максимально зрозумілі графічні позначення. Освоєння інтерфейсу може вимагати певних навичок і навіть потребувати навчання, якщо аудиторія не звикла до графічного інтерфейсу. Звичайно, мета інтерфейсу полягає в забезпеченні легкого, вільного доступу до будь-якої частини видання за бажанням користувача. Особлива роль належить кольоровому забарвленню та звуковому оформленню кнопок.

Укладення контракту

Ціль усіх попередніх робіт головним чином полягала у визначенні вартості контракту. Але і на цьому етапі вона не може бути остаточною, оскільки залишається ще багато невідомих. Отже вартість може бути лише оціночною, тоді як реальна вартість буде підрахована по факту.

Особлива увага приділяється легітимності проекту. Юридичну відповідальність за видання несе замовник. Він повинен володіти правами на електронні версії наданих матеріалів. Розробник повинен обумовити свої авторські права на всі нові матеріали, що будуть ним створені під час роботи над проектом. Також важливо обумовити своє право на подальше використання видання в демонстраційних, рекламних і тому подібних цілях.

Крім основного контракту із замовником, можливе укладення цілої серії контрактів із субпідрядниками.




Схожі:

3. Управління мультимедійним проектом icon3. Управління мультимедійним проектом
Ми зупмнимося на замовних софтверних проектах, для виконання яких доводиться збирати команду. Можна було б уявити собі такого мультимедійного...
3. Управління мультимедійним проектом iconРефератів по ондр для студентів 3-4 курсів кафедри аівт керівник: к т. н., доцент Коцюбинський В. Ю. Розробка систем управління мультимедійним контентом
Розробка html5 додатків для мобільних платформ для роботи з мультимедійним контентом
3. Управління мультимедійним проектом iconУгода з фінансового управління проектом: 543681-tempus-1-2013-1-de-tempus-jphes
«Мережа центрів компетенції для розвитку круїзного туризму в Чорноморському регіоні» – «CruiseT»
3. Управління мультимедійним проектом iconЛекція sadt. Керування проектом Керування проектом у методології sadt не зводиться просто до створення набору діаграм. Досвід показує, що ефективне проектування в sadt для одержання результатів у
У цій лекції обговорюється досвід проектування в sadt. Особлива увага приділяється керуванню проектами й координації робіт у методології...
3. Управління мультимедійним проектом iconПояснювальна записка до навчальних планів загальноосвітніх навчальних закладів, які працюють за науково-педагогічним проектом "росток", на 2012/2013 навчальний рік
Про продовження дослідно-експериментальної роботи за науково-педагогічним проектом "Росток" на період до 2014 року", з метою впровадження...
3. Управління мультимедійним проектом iconУ статті аналізується можлива модель поділу влад в Україні за винесеним на всенародне обговорення Президентом України проектом закону “Про внесення змін до Конституції України”
Поділ влади за проектом закону “про внесення змін до конституції україни”, запропонованим президентом україни
3. Управління мультимедійним проектом iconЛитература
Бауэр Р., Коллар Э., Тан В. Управление инвестиционным проектом: опыт шм. М.: Инфра-м, 1995
3. Управління мультимедійним проектом iconЛітература
Бауэр Р., Коллар Э., Тан В. Управление инвестиционным проектом: опыт шм. М.: Инфра-м, 1995
3. Управління мультимедійним проектом iconМетодичні вказівки для самостійної роботи студентів спеціальності "Електропостачання" над проектом з курсу "Електричні системи та мережі"
Методичні вказівки для самостійної роботи студентів спеціальності “Електропостачання" над проектом з курсу "Електричні системи та...
3. Управління мультимедійним проектом iconНаказ №503 від 14 травня 2013 року Про затвердження Типових навчальних планів загальноосвітніх навчальних закладів І-ІІ ступенів, які працюють за науково-педагогічним проектом "Росток", на 2013/2014 навчальний рік
Про затвердження Типових навчальних планів загальноосвітніх навчальних закладів І-ІІ ступенів, які працюють за науково-педагогічним...
Додайте кнопку на своєму сайті:
Документи


База даних захищена авторським правом ©zavantag.com 2000-2013
При копіюванні матеріалу обов'язкове зазначення активного посилання відкритою для індексації.
звернутися до адміністрації
Документи