Для належного виконання типового циклу роботи з BUG-групою може знадобитися кілька днів (мал. 6.3).
" При роботі з користувачами, орієнтованими на ділові проблеми, уникайте абстракцій. Варто бути точним і конкретної, надавати користувачам реальний проект (махати руками і показувати на пальцях неприпустимо) і спиратися на реальний сценарій демонстрації проектних рішень.
" Концентруйтеся на речах, що виходять за межі проектованих компонентів. Викладайте матеріал із системної точки зору (показуйте відображення, вікна і сценарії), у полях повинні бути присутнім реалістичні дані, дайте представлення про те, яка допомога і навчання передбачені для користувачів.
" Не занадто тримаєтеся за проектні рішення в процесі їхнього перегляду.
Проводите перегляд, орієнтований на сценарій/потік задач, пропонуючи безліч альтернатив. Для цього використовуйте питання типу: "Що ви думаєте про цей проект?", "Що вам подобається/не подобається?", слухайте і робіть зауваження, намагаючись бути об'єктивним. :
" Завжди реалізуйте те, що вимагають користувачі. Іноді бригада, що рабо-тает над продуктом, не може зрозуміти, чого бажають користувачі і що вони вважають вірним рішенням. Коли користувачі вступають на невірний шлях, покажіть їм наслідку їхнього запиту, вкажіть альтернативний шлях досягнення бажаного результату, і якщо компроміс правильно зрозумілий і прийнятний, дайте користувачам те, що вони бажають.
" Обережно вводите зміни. Революційні зміни труднодости-жимы. Замість цього по можливості зберігайте те, що вже знайомо поль-зователям і вводите поліпшення еволюційним шляхом, для більш радикальних і революційних змін повинний бути передбачений шлях переходу. Щоб полегшити користувачам прийняття нововведень, повинна бути продумана схема керування змінами.
" Не приймайте проектних рішень сходу. Необхідно ретельно продумувати проектні рішення і розуміти їхнього наслідку. Варто повертатися до проектних рішень, маючи спектр альтернатив, показувати враження і відчуття від ПІ, зауважувати, що жадає пояснень, надавати користувачам практичну інтерактивну чи модель прототип, а іноді давати користувачам можливість "порулить".
" Не зневажайте зворотним зв'язком з користувачами. Виділяйте досить часу для аналізу кожного питання; документально фіксуйте інформацію, отриманий по зворотному зв'язку, і припущення користувачів незалежно від того, що говорять/роблять користувачі і як вони це говорять/роблять; швидко виправляйте положення (усунення чи помилок відповіді на питання).
" Не переоцінюйте ваші ідеї. Допоможіть користувачам зрозуміти значення існуючих методів, сутність компромісів (наприклад, вимоги до великих обсягів чи інформації заповнення простору екрана) і говорите з ними з одного голосу (тобто всі члени орієнтованої на користувача проектної бригади відправляють користувачам загальні повідомлення).
" Не зловживайте часом користувачів. Відповідально відноситеся до використання часу користувачів, додавайте цінність їх ПО, основы-ваясь на їхній вихідній інформації, прагнете планувати колективну роботу з користувачами.
Ніхто з членів бригади не має досвіду у використанні якого-небудь методу со-вместной розробки, однак трохи фахівців із проектної бригади і лабораторії розробок відвідували великі конференції - причому регулярно - у плані підтримки маркетингової діяльності лабораторії. З погляду обговорюваного нами проекту потрібно прийняти рішення про те, який з методів спільної розробки використовувати, а також вирішити, коли застосувати той чи інший конкретний метод.
Варто визначити підрозділу, що можуть служити джерелом привле-чения користувачів для участі в проекті. Потрібно оцінити ймовірні витрати і вигоди від використання подібних методів по ходу проекту.
Дотепер лідер проекту безумовно підтримував усі ваші реко-мендации, включаючи використання методів спільної розробки, і займав відкриту позицію. Під час обговорення процесу розробки з вищим керівництвом лідер проекту згадав про тім, що подібні методи плануються до застосування. Однак він не міг чи пояснити захистити використання цих методів у стилі, який би задовольнив вище керівництво.
Команда вищого керівництва відрізняється недоброзичливістю і скептицизмом. Усі вищі керівники - представники старої школи, що виступають за відповідальне відношення до роботи і твердий контроль за прийняттям рішень із приводу потреб користувачів, ґрунтуючись на інтуїції; вони схильні якомога швидше "зіпхнути" продукт, а його припасуванням займатися пізніше.
Команда вищих керівників уже знає, чого бажають і в чому бідують поль-зователи, і готова дати свої вказівки по цьому питанню. Керівники дуже стурбовані використанням деяких методів, вони думають, що це приведе до зайвого затягування проекту і непотрібній витраті засобів. Відношення вищих керівників у такому ступені негативно, що вони можуть не схвалити витрати ресурсів на цю діяльність.
Лідер проекту повернувся з наради досить розстроєним. Він попросив вас зібрати інформаційну нараду для команди вищих керівників. Питання, до яких варто звернутися, включають обґрунтування використання методів, порівняння методів із традиційними підходами залучення користувачів у проект, вигоди від використання даних методів, а також їхній вплив на терміни і вартість розробки. Ступінь і серйозність побоювань керівників вимагає провести нарада якомога швидше . Вищі керівники можуть взяти участь у брифінгу в 7.30 ранки завтра. Зараз 5 годин вечора і ви можете присвятити запиту, що надійшов, біля двох годин.
Напевно, перш ніж йти тримати відповідь, непогано провести невелике дослідження.
Питання?
Посилання
Beyer H., and Holtzblatt К. Contextual Desіgn, Morgan-Kauffman: San Francіsco, 1998. Carmel E. et al. PD and Joіnt Applіcatіon Desіgn: A Transatlantіc Comparіson, Communіcatіons
of the ACM, June 1993.
Muller M. et al. Taxonomy ofPD Practіce: A Brіef Practіtіoner's Guіde, Communіcatіons of the ACMJune 1993.
Torres R. et al. Case Study іn Partіcіpatory Desіgn, UPA Conference Proceedіngs, 1998.
Глава 7
Коротко про засоби проектування
Здійснення задач проектування і розробки з орієнтацією на користувачів вимагає великої кількості інструментальних засобів. Деякі засоби відносно прості технологічно і досить ефективні. Однак тільки наявність кращих высокотехнологичных засобів не може бути гарантією продуктивності і не обов'язково веде до успіху проекту.
У залежності від характеру бригади і задач деякі з цих засобів предпоч-тительнее інших, вони повинні бути враховані в орієнтованих на користувачів планах розробки. Бригада по розробці продукту здобуває й оцінює інструментальні засоби на самих ранніх етапах і якнайшвидше , оскільки на одержання і вивчення цих засобів потрібно визначений час.
У цій главі розглядаються наступні питання.
" Програмне забезпечення.
" Апаратне забезпечення.
" Устаткування.
" Матеріали.
" Шаблони проектування/прототипирования/оцінки.
" Засобу, необхідні для проекту. Інструментальні засоби розробки.
Програмне забезпечення
Крім вартості, придбання і часу на навчання існують і інші причини, для завчасного продумування дій у відношенні програмних засобів для всього проекту і ПО ПІ. Для рішення проблем придбання продуктів може знадобитися пророблення деяких юридичних питань, а також питань, зв'язаних з одержанням ліцензій. Іноді ці проблеми виявляються досить складними і їхнє рішення займає чимало часу.
Керування проектом. Як і у випадку ПО для керування змінами, засобу керування проектом також імовірніше всего вибираються на рівні всього проекту. Проект може також зажадати відстеження визначених типів діяльності й етапів. Однак у зв'язку з безліччю деталізованих робіт і наявністю великої кількості залежностей у рамках проекту бригада розроблювачів продукту може віддати перевагу відстеженню видів діяльності і компонентів, що поставляються, на більш високому рівні деталізації.
Корисне правило. Для бригади новачків, що не володіє великими навыка-ми і досвідом в області орієнтованого на користувачів проектування і розробки, рекомендується керування проектом на досить високому рівні деталізації. При цьому план не повинний бути занадто докладним, щоб не ус-ложнять роботу.
Операційні системи. Операційні системи, під керуванням яких буде функціонувати додаток, повинні бути отримані й інстальовані дуже швидко. На щастя, ОС не піддаються значній доробці протягом циклу створення додатків, що, можливо, привнесло б значну нестабільність у загальну розробку ПО. Проектна бригада ґрунтовно випробує ОС, щоб визначити, яким образом прикладне ПО буде інтегруватися й узгоджуватися з ОС. Будь-які необхідні набори інструментальних засобів розробки ПО (Software Development Kіt - SDK) одержують і тестируют для вивчення і розуміння обмежень.
Підтримка проектування. Існує чимало нових технологій і методів, що включають допоміжні засоби підтримки проектування. Для середовищ, що дозволяють скористатися перевагами застосування стандартних методів проектування на зразок мови UML (Unіfіed Modelіng Language - уніфікована мова моделювання), маються інструментальні засоби, що полегшують проектування. Проектна бригада повинна проаналізувати, які з наявних інструментальних засобів здатні допомогти у всіх аспектах проектування.
Мови розробки. Програмне забезпечення, що повинне використовуватися для проектування, прототипирования і реалізації, здобувається на самому початку розробки. Бажано, щоб мови використовувалися якомога раніше на цільовий ОС і апаратній платформі. Усі додаткові програмні пакети з підтримуючими елементами чи керування іншими можливостями додаються при першій необхідності. Найбільше важливо дістати базові кошти конструювання якомога раніше - коли бригада починає вивчення і тестування, щоб упевнитися в тім, що намічені цілі досяжні й оцінити обсяг робіт, необхідних для досягнення цих цілей.
Генератори користувальницького інтерфейсу. Програми, що використовуються спеціально для конструювання ПІ, називаються програмами-генераторами ПІ. У деяких випадках мова реалізації має візуальні засоби розробки ПІ. Іноді візуальна підтримка забезпечується для конструювання алгоритмів ПО, структур даних і програмної логіки.
Корисне правило. При будь-якій можливості варто одержати генератори ПІ.
Існує кілька ефективних критеріїв вибору інструментальних засобів проектування і розробки ПІ.
" Вартість.
" Адекватність у відношенні підтримуваної платформи.
" Адекватність у відношенні планованого стилю користувальницького інтерфейсу.
" Легкість у використанні (підтримувані задачі, час вивчення, про-дуктивность і т.д.) для розроблювачів.
" Необхідні ресурси (вимоги до пам'яті, необхідної під час розробки і виконання, а також до обсягу дискового простору).
" Час відгуку, надійність, якість і інші важливі для ПО критерії.
Кроссплатформенные засобу. Для того щоб реалізувати продукт на декількох апаратних і операційних системах, орієнтована на користувачів бригада розроблювачів повинна вирішити питання про єдиний кроссплатформенной реалізації, якщо, звичайно, існує така можливість. Визначені програмні засоби полегшують формування єдиного проекту, якому можна переносити на кілька платформ.
Якщо підтримується кілька платформ, може виявитися більш вигідним ис-пользовать єдиний інструментарій і упокоритися з обмеженнями, що він накладає на розробку.
Корисне правило. Якщо підтримується дві платформи, то питання про тім, ис-пользовать одне чи два програмні засоби викликає сумніву. Якщо поддер-живаются три чи більше платформи, необхідно знайти засіб, що спо-собствует крос платформному проектуванню і розробці.
Графіка. ПО для проектування, конструювання і редагування графічних зображень, використовуваних в анімації, піктограмах, растрових зображеннях і інших видах графіки, є частиною багатьох SDK. При створенні цих видів графіки деякі програмні пакети можуть виявитися краще інших, тому їх варто порівнювати.
Бібліотека зразків. У ході будь-якого проекту створюється чимало повторно використовуваних компонентів постачання. Прикладами можуть служити шаблони для програмних модулів і процедур, піктограми, растрові відображення і плани тестування. Варто проаналізувати повторно використовувані компоненти і зразки, щоб побудувати приклади і заощадити час у процесі проектування і реалізації.
Корисне правило. Створіть бібліотеку повторного використання для про-екта, щоб включити в неї найбільш придатні відправні крапки для різних типів компонентів, що поставляються, і видів діяльності. Існуючі шаблони і компоненти складають частина бібліотеки.
Копії екранів. Зафіксовані зображення ПІ використовуються в презентаціях і документації на продукт. Багато ХТО ОС забезпечують механізми для фіксації екранних зображень у реальному часі і для автоматичного приміщення їх у буфер обміну. У деяких випадках може знадобитися краще ПО для фіксації екранів і маніпулювання ними.
Керування змінами. ПО контролю за змінами використовується для керування перетвореннями, внесеними в програмний продукт, а також в артефакти в міру їхньої розробки. Рішення про відповідний програмному пакеті звичайно приймається на рівні проекту. Однак проектна бригада повинна визначити, які саме елементи будуть контролюватися.
Потенційно контроль за змінами може здійснюватися у відношенні всіх орієнтованих на користувачів компонентів постачання: планів, вимог, специфікацій, посібників зі стилю, прототипів, програмного коду, графіки, тест-планів, сценаріїв і т.д. Аналогічно іншим проектним рішенням бригада повинна знайти вірне обґрунтування тому, що саме є істотним з погляду встановлення контролю за змінами, а також вирішити, коли здійснювати цей контроль.
Процесор документування. Крім інструментальних засобів для розробки ПО наступне найбільш важливий засіб розробки для проектної бригади - це вірно обраний процесор документування. Засобу документування використовуються для вироблення вимог, специфікацій, стильових посібників, тест-планів, прецедентів і тестових звітів. Для вироблення багатьох однотипних документів створюються і використовуються шаблони.
Презентаційне ПО. Існує ще один клас графічного ПО, дуже корисного для демонстрації передбачуваного поводження програмного продукту. Крім проектних рішень презентаційне ПО застосовується для наближеного прототипирования, розкадрування сценаріїв виконання програм і показу слайдів. Деякі види ПО легко використовувати також для створення графічних зображень для Web-сторінок, у цьому випадку варто здобувати високоякісні програмні пакети.
Оцінка Продуктивності. ПО для відстеження і хронометрування низкоуровневого внутрішнього поводження іншого ПО украй важливо, оскільки воно стає усе більш складним. Подібне ПО може проконтролювати виконання чи модулів команд, зафіксувати швидкість виконання і простежити, по яких галузях виповнюється ПО. Поряд з тим, що подібне ПО допомагає усувати недоліки, зв'язані згодом відгуку і "витоком" пам'яті, він допомагає справитися з функціональними проблемами.
Електронні таблиці. ПО електронних таблиць корисно при відстеженні й організації користувальницьких профілів, переліків прецедентів і т.п. При належному створенні і використанні таблиць ПО дозволяє сортувати і відображати результати в різній формі.
ПО підтримки групової роботи. Програмні пакети, що мають фундаментальне значення для організації загальної роботи бригад розроблювачів, включають електронну пошту, засоби календарного планування й інші види групового ПО для швидкого спільного використання інформації. Це особливо важливо з погляду тенденції до усе більшого поділу бригад розроблювачів у просторі і часі.
Конкуруюче і попереднє ПО. Для проектів, призначення яких полягає в тому, щоб надати користувачам кращі продукти в порівнянні з конкуруючими, модельними чи успадкованими продуктами, варто забезпечити наявність останніх для практичної чи оцінки порівняльного тестування. Непогано мати під рукою як еталон і інше ПО (наприклад, ПО, що щонайкраще зарекомендувало себе на практиці), навіть якщо воно не виступає прямим конкурентом розроблювального ПО. Постарайтеся довідатися, як інші бригади справляються з аналогічними проблемами.
Інше ПО, що представляє інтерес. Існують і інші типи про-граммных пакетів, що можуть становити інтерес, наприклад, ПО автоматизи-рованного проектування і створення програм (Computer-Aіded Software Engіneerіng- CASE), систем підтримки прийняття рішень (Decіsіon Support System- DSS) чи систем керування користувальницьким інтерфейсом (User Іnterface Management System- UІMS). Перераховані вище продукти не можна вважати загальновживаними, однак в інших випадках ці засоби можуть виявитися корисними.
Апаратне забезпечення
Ще одним найважливішим набором ресурсів для проекту є апаратне забезпечення, для якого розробляється ПО. Бригаді потрібно апаратне забезпечення для розробки, тестування, а також для використання членами бригади як кінцевими користувачами.
Цільове устаткування. Кожен розроблювач повинний володіти вільним і легким доступом щонайменше до одного екземпляра кожної цільової платформи для тестування функцій ПО і ПІ. На кожній апаратній платформі повинні бути встановлені цільова ОС і необхідні програмні засоби. Розгортанню продукту в замовника повинне передувати тестування, щоб переконатися у відсутності проблем, зв'язаних з тимчасовими характеристиками ПО.
Машини ДЛЯ розробки. Для прискорення процесу розробки кожен розроблювач повинний мати у своєму розпорядженні по можливості саму могутню платформу розробки. Однак звичайно це устаткування високої потужності може не бути доступно кінцевим користувачам. Швидкість розробки- одна з цілей! розроблювачів. Для Web-орієнтованої розробки також потрібно Web-сервер.
Машини для тестування. Бригаді тестировщиков необхідно не скільки екземплярів апаратних засобів і комбінацій операційних систем. Діапазон цих пристроїв змінюється від молодших моделей до високопродуктивних машин. Бригада по тестуванню здійснює верифікацію функціональних можливостей, ПІ, практичності, цілісності, несуперечності, продуктивності і надійності. Конкуруючі й успадковані системи можуть зажадати установки спеціального ПО. Це сприяє частому тестуванню апаратної забезпечення, що приводить до мінімальних протиріч з календарними планами.
Апаратне забезпечення для власних нестатків. Кожен член орієнтованої на користувачів бригади розроблювачів повинний мати у своєму розпорядженні машину, використовувану винятково для обміну електронною поштою, проведення робіт адміністративного характеру і т.д. Машина для власних нестатків- це не машина для розробки, тому що інсталяція цілого ряду програмних продуктів може привести до порушення стабільності середовища через характер установленого на них ПО. Такі машини для розробки іноді відмовляють.
Дисковий простір локальної мережі. Користувальницький інтерфейс передає великі обсяги інформації. Існує маса документів, що містять величезні обсяги графіки, зображень, коду і версій ПО, документації. Варто подбати про резервування достатнього обсягу дискового простору на локальній мережі.
Принтери И плоттеры. Поряд з електронним поширенням ПО і документації існує багато можливостей поширення друкованих копій версій документації для перегляду. Для цього вимагаються високошвидкісні принтери з високим дозволом печатки. Для проведення презентацій необхідне відображення кольорових версій ключових фрагментів ПІ на високошвидкісних пристроях високого дозволу.
Проекційні пристрої. Звичайно для кожного продукту потрібно проведення численних презентацій з демонстрацією його ПІ і наданням іншої стосовної до нього інформації. Аудиторію подібних презентацій складають вище керівництво, потенційні замовники й інші групи розроблювачів, що зацікавлені даним проектом. При цьому зовсім не зайвим буде проектор для зображень на прозорій підкладці, що також буде корисний для запису заміток під час нарад бригади розроблювачів ПІ і процедур наскрізного контролю. Проекційні пристрої високого дозволу на основі жидкокристаллических екранів (Lіquіd Crystal Dіsplay - LCD) також відіграють істотну роль при відображенні ПІ продукту з використанням безпосередньо чи прототипу продукту.
Камери. Для лабораторних іспитів практичності потрібно устаткування відеозапису і редагування відеозображенні. Миттєвий запис інформації, що може бути представлена на дошці для фломастерів, здійснюється за допомогою камери типу "Полароид". Для створення графічних зображень може знадобитися й інше фотоустаткування.
Аудио- і відеоапаратура. Для іспитів практичності і створення відео кліпів, що можуть увійти до складу продукту, може знадобитися устаткування відеозапису і редагування відеозображенні.
"Біла дошка". Стосовні до проекту ідеї і плани найчастіше записуються на так називаній "білій дошці" (тип проекційного устаткування для компьютеризованных презентацій, звичайно являє собою дошку білого кольору зі спеціальним покриттям, на якій можна писати фломастерами з чорнил, що стираються. Крім того, на таку дошку можна проектувати зображення за допомогою різного роду проекторів). За допомогою камери типу "Полароид" також можна зафіксувати цю інформацію, однак "біла дошка" з можливістю печатки переважніше.
Приміщення
Хоча бригада розроблювачів продукту може обійтися конференц-залом, більш ефективно використовувати постійні приміщення для проектування і тестування. Конструкція цих кімнат має важливе значення для ефективної підтримки орієнтованої на користувачів бригади розроблювачів продукту.
Проектна лабораторія. Проектна лабораторія - це кімната, у якій бригада виконує свої першочергові задачі. Проектна лабораторія призначена для орієнтованої на користувачів бригади розроблювачів продукту. Це досить містка кімната, на стінах якої можуть розміщатися копії екранів, "білі дошки" чи плакати для запису ідей, що виникають у ході обговорення схеми; тут досить місця для устаткування, на якому розгорнуті конкуруючі й успадковані системи, прототипи і засоби проектування. Добре спланована й обладнана проектна лабораторія використовується для проведення спільних нарад з користувачами. Проектна лабораторія не заміняє офісні приміщення для членів проектної бригади.
Лабораторія іспитів практичності. Лабораторія іспитів практичності - це приміщення, де співробітники проводять іспити практичності й оцінку результатів. Тут знаходиться устаткування спостереження за іспитами і тестове устаткування для користувачів, на стінах цієї досить місткої кімнати розміщені "білі дошки". Площадка для користувачів, що оцінюють продукт, зручна, простора і нагадує звичне офісне робоче приміщення.
Центр підтримки прийняття рішень. Один з методів одержання і реєстрації інформації одночасно від декількох користувачів одержав назву центра підтримки прийняття рішень (Decіsіon Support Center - DSC). Центр організований у виді декількох робочих станцій, з'єднаних мережним устаткуванням і ПО. Програмне забезпечення підтримки прийняття рішень одержує і поєднує вхідну інформацію від користувачів; Звичайно DSC застосовують для збору вимог, однак його можна використовувати в рамках методів залучення користувачів до розробки на етапах планування, проектування, реалізації й оцінки.
Матеріали
Хоча серед інших типів ресурсів найбільш важливі час і витрати, проте приступати до проекту краще все-таки маючи в наявності деякі з перерахованих нижче матеріалів, щоб у потрібний момент вони завжди були під рукою.
Плакати і стенди. Завжди корисні для того, щоб запам'ятати проектні ідеї під час нарад бригади. Плакатні аркуші можна приклеїти скотчем чи прикріпити до стін, а при необхідності перенести в інші кімнати.
"Біла дошка". У кожній чи кімнаті робочому приміщенні повинна бути "біла дошка" для фіксації ідей і дій, що відносяться до проекту. При цьому необхідно подбати про достатню кількість різнобарвних чи маркерів фломастерів.
Письмового Приладдя. Необхідно мати в наявності достатня кількість папера, рейок, рулонів прозорої плівки, кнопок, ручок, олівців і маркерів.
Блоки самоклеющейся папера. Важливий інструмент для проектування - блоки самоклеющейся папера, що добре зарекомендували себе на всіх етапах циклу проектування. Можуть придатися всі розміри - від невеликих листиків до аркушів розміром із плакат
.
Робочі зошити. Необхідна наявність великої кількості письмових принадлежностей. Зокрема , у проектній лабораторії завжди повинний бути запас проектних робочих зошитів для обліку проектних рішень. Кожна нарада бригади розроблювачів продукту повинне бути зафіксовано, постачено списком присутніх, а ключові рішення і робочі моменти варто оформляти документально.
Корисне правило. Рекомендується використовувати в оформленні проектної ра-бочей зошита найбільш цікаві екранні чи умовно-схематичні изо-бражения проектних методів, що можуть служити як частину буклету по користувальницькому інтерфейсі для проекту.
Бажано також одержати нормативно-технічну інформацію з пользова-тельскому інтерфейсу, людським факторам у проектуванні ПО, інструментальним засобам і по галузі в цілому. Нижче приводяться деякі загальні розділи первинної інформації, що можуть знадобитися практично для будь-якого проекту ПІ. Безперечно, усе більше і більше інформації можна знайти в Іnternet, однак не слід забувати про журнали і книги, що також надають неоціненну допомогу в розумінні сутності проектів, зв'язаних з ПІ і практичністю ПО.
" Загальні питання ПІ.
" Загальні питання людських факторів у проектуванні.
" Графічний інтерфейс користувача (GUІ).
" Web-орієнтований користувальницький інтерфейс (WUІ).
" Інтерфейс кишенькових пристроїв (HUІ).
" Графічне і візуальне проектування.
" Проектування систем допомоги користувачу.
" Підтримка продуктивності.
" Web-вузли.
" Основні книги.
" Основні статті.
Обсяг інформації в кожній з цих областей величезний і продовжує рости згодом экспоненциально.
Корисне правило. Завжди майте під рукою від трьох до п'яти посилань на Источ-Ники з кожної категорії відповідно до характеру розроблювального продукту.
Відшукайте роботи авторів, що розробили практичні продукти, що мають практичний і теоретичний зміст.
Продовження обговорення проекту: засобу, необхідні для проекту
Коли проект зрушився з місця, приходить час подумати про бюджет. Лідер проекту попросив вас позначити необхідні ресурси для розробки, щоб запити на капітальні й інші види витрат можна було зробити швидко, не упустивши джерела фінансування.
Хоча деталізоване планування ще не почалося, прикиньте вимоги до необхідних інструментальних засобів, приміщенням і матеріалам. Обновите ваші записи за проектним планом, щоб врахувати час, необхідне для гарантованого одержання необхідних програмних засобів. Відіб'єте у ваших пропозиціях порядок, у якому можна придбати і застосувати ці засоби (не забувайте, що на одержання одних засобів буде потрібно більше часу, чим інших).