Ця статистика повинна дати розроблювачам ПО перепочинок. Відповідь на питання керівника розробки: "Чому ПО для GUІ таке важке?" почасти полягає в тім, що цього ПО так багато. Проектування і реалізація прикладного ПО з використанням GUІ чи його похідних вимагає обліку багатьох деталей, глибоких знань і завзятої праці в прикладній області, а також в області ПО і реалізації. Задача ще більше ускладнюється, якщо до продукту пред'являються строгі вимоги у відношенні практичності, погодженості, інтеграції, а також до кроссплатформенным аспектів і конкурентноздатності. Однак найбільш важка сторона роботи над ПІ звичайно зв'язана з людськими факторами - навичками і досвідом людей, груповою динамікою й організаційним поводженням.
Сьогодні існує величезна концептуальна прірва між моделями графічного і візуального ПІ, а також символьної (чи краще сказати - текстової) природою ПО, за допомогою якого втілюється задумана модель. Як приклад Можна привести таку тривіальну функцію ПІ, як розблокування і блокування можливості вибору пункту меню. Однак у кожнім випадку застосування цієї елементарної функції потрібно спроектувати, запрограмувати і протестувати реалізуюче її ПО. На мал. 8.2 показаний фрагмент програми мовою Vіsual Варі (VB), що реалізує єдину ситуацію- п'ять команд, що вимагаються, щоб розблокувати і блокувати єдиний пункт меню.
Цей фрагмент дійсно простий.
Деякі складності цього фрагмента програми полягають у його великих вимогах до проектування, специфікації, програмуванню і документуванню для тестировщиков і кінцевих користувачів, а також у тестуванні навіть для простого додатка. Коли ж приходиться враховувати безліч умов і зв'язаних між собою варіантів вибору, щоб визначити, які елементи разблокированы, а які заблоковані, складність зростає экспоненциально.
Перший крок. Що повинніо робити керівники і технічні фахівці, перед якими поставлена дуже важка (але здійсненна) задача, щоб забезпечити її успішне рішення? Як перший крок здається розумним розглянути обсяг робіт, витрати і ризик, зв'язані з розробкою продукту (ризикованого з погляду високого рівня змістовності чи ПІ високого рівня практичності), і скласти ґрунтовний план. Хоча інженерні підходи до розробки ПІ: добре відомі, орієнтована на користувача бригада розроблювачів продукту може досягти великих можливостей.
План створення продукту, спрямований на деталізацію і вимір елементів процесу розробки ПІ, допомагає в деякій мері виключити з процесу такі фактори, як натхнення, чудо і сліпу віру в удачу, а також до деякої міри обмежити ризик. Щоб досягти успіху в створенні продукту, план повинний задовольняти наступним вимогам.
" У плані створення продукту повинні бути конкретно відбиті найважливіші ключові події календарного графіка, що відносяться до кожного з етапів процесу, а компоненти, що також поставляються, ПІ і показники практичності.
" Виконання плану повинне, зокрема , базуватися на обліку і відстеженні відповідності якості компонентів постачання і показників практичності плану.
" Відстеження ходу виконання плану і звітність по поточному стані робіт повинні служити мети керування елементами ризику, зв'язаними з багатьма хитливими задачами.
" На кожнім етапі процесу здійснюється явна оцінка і формування звітності, що стосуються відповідності продукту пропонованим до нього вимогам.
Корисне правило. Ніколи не можна починати проект без плану.
Вибір моделі розробки ПО
Чимало критики було висловлено на адресу каскадної моделі розробки ПО, що звичайно зображується у виді спадного потоку робіт. Й усе-таки багатьох не залишає відчуття, що з кожним кроком виконання процесу він стає усе легше. Тут справедливо зворотне твердження. Обсяг робіт і бар'єри, які необхідно перебороти на шляху до досягнення мети, згодом збільшуються. У даному випадку дуже доречна аналогія з лососем, що прагне плисти проти плину, щоб досягти нерестовища.
Аналогія з лососем має сенс із декількох точок зору.
" Величина часу, зусиль і енергії, що затрачаються при плануванні, складанні вимог і проектуванні, менше тієї, котра витрачається на етапах конструювання і тестування. Легко відправитися в шлях, але не завжди легко успішно його завершити.
" Ранні роботи носять більш концептуальний і абстрактний характер, у той час як у міру руху "нагору по потоці" робота стає більш визначеної і конкретною. На ранніх етапах багато речей легше випустити з уваги, чим на більш пізніх. Ці зусилля повинні починатися ґрунтовно, а завершуватися ефективно.
" Поряд з конструкторськими роботами зусилля по проектуванню не припиняються аж до завершальної постачання. Процес конструювання буяє несподіванками і компромісами, що здатні погубити навіть кращі ідеї і проектні рішення.
" Продукт, що пережив "підйом нагору проти плину" (якщо тільки він не відкинутий користувачами), виразно проіснує значно довше, ніж під час його первісної розробки. Результат розробки повинний давати довгостроковий виграш підтримуючої проект організації і колективу користувачів.
" Не всім продуктам удається зробити вдалий стрибок з першої спроби. Це положення складає сутність ітеративної концепції - спроби повинні продовжуватися доти , поки не будуть задоволені вимоги (проект або припиниться, або вимоги будуть скоректовані).
Корисне правило. З погляду проектування і розробки ПО і ПІ найкраще на практиці зарекомендував себе вибір деякої форми ітеративної чи еволюційної моделі. Ще один ефективний практичний метод - ітеративна модель розробки при участі користувачів. Існує багато різновидів ітеративних процесів і процесів спільної розробки - виберіть один з них, що спрацьовує стосовно до вашої організації і проекту, і дотримуйте його.
Ітеративний підхід із залученням користувачів найкраще зарекомендував себе на практиці, оскільки ні в кого немає готових відповідей на масу питань і проблем, що виникають при проектуванні програмного ПІ, що спрямований на задоволення потреб організацій і користувачів. Експерти рекомендую ітеративний підхід також по наступним причинах.
" ПІ програмних засобів складні. Може знадобитися чимало ітерацій щоб проробити деталі конкретного підходу для задоволення потреб з погляду ергономіки, користувачів і бізнес - процесів.
" Варто вивчати користувачів, способи їхньої взаємодії з комп'ютерами програмними додатками. Ітерації за участю користувачів допомагаю пристосувати визначений підхід до конкретної групи користувачів задачі.
Ідея підходу до розробки продукту і досягнення всіх цілей з однієї спроби виглядає авантюрою - як внесення без усякого нестатку невиправданого ризику у вже і без того дуже ризиковане підприємство. Якщо загальна модель розробки, прийнята для проекту, відрізняється від однієї з форм ітеративної чи еволюційної модель то варто наполегливо рекомендувати використовувати ітеративну модель хоча б для користувальницького інтерфейсу.
Проектувальники і розроблювачі програмного ПІ повинні підходити до задача осмислено, залучати користувачів і звертатися до них якнайчастіше . "Закриті" ітерації, здійснювані до випуску програмного продукту, дають бригад розроблювачів шанс заздалегідь довести свою правоту. У противному випадку іноді виникає необхідність у "відкритих" ітераціях, що ускладнюють роботу проект проектувальників.
Навіть незважаючи на те, що багато Web-орієнтованих проектів випливають еволюційної моделі на практиці, більшість з них не витримує цього підходу Однак не всі проекти, що використовують ітеративний підхід, неодмінно успішні занадто багато перемінних потрібно брати до уваги.
Мети. З погляду орієнтації на користувача найбільш важливий крок для керівництва полягає в тому, щоб переконатися, що мети у відношенні продукту і критерії у відношенні ПІ, практичності, погодженості, інтеграції й інших peлевантных факторів установлені. Знання технології, кваліфікація бригади розроблювачів продукту і конкуруючі продукти мають істотне значення для встановлення "планки" на вірній висоті.
Керівництво встановлює мети на рівні звичайної задоволеності користувачів (фактичний результат - це в деякому роді усереднений результат), коту рій можна досягти за допомогою традиційних методів. Установлення великих цілей вимагає відхилення від добре відомих і зручних способів розробки (щоб так битися відмінного ПІ, варто відмовитися від традиційних методів і моделей).
Деталі, деталі, деталі. Наступна велика область ризику зв'язана з навичками і знаннями, необхідними для проектування і реалізації додатків використанням існуючих стилів ПІ. Крім функцій ПО, зв'язаних із прикладною областю, існує незліченне число можливостей і методів, що стосуються ПІ. Короткий перелік функціональних можливостей включає операцій "перетягнути і помістити" (drag and drop), роботу з буфером обміну (clіpboard), віконну пам'ять (утримуючу параметри про розміри, розташування і стан вікна), множинні представлення і печатка.
Іноді просто дивно, як багато розроблювачів не мають поняття про усіх необхідних тонкостях. План і календарний графік проекту повинні враховувати вивчення деталей технології, неявні і явні вимоги до ПІ, а також інструментальні засоби, що підтримують реалізацію вимог.
Вимоги. Ще одна область високого проектного ризику зв'язана з недоліками в розумінні проектних вимог. План передбачає відповідне час і методи, щоб зібрати і вивчити основні вимоги до продукту, а також призначити їм пріоритети. В особливій увазі бідують вимоги до ПІ, практичності, погодженості, навчанню й інтеграції.
Під час збору вимог багато деталей, що відносяться до ПІ, ніколи не згадуються в явному виді. Про їхнє існування багато користувачів навіть не підозрюють. Наприклад, така вимога, як відповідність стандартам користувальницького інтерфейсу для визначеної чи платформи рівня погодженості й інтеграції набору програм впливає на роботу бригади розроблювачів продукту.
Вимоги у відношенні практичності й узгодженості повинні бути вимірними і піддаватися перевірці на відповідність. Наприклад, виконання задачі за час, що на 25% менше, ніж для успадкованої системи, є дуже реальною і вимірною вимогою. Більш докладно вимоги для ПІ, практичності, навчання й узгодженості розглядаються нижче. Установлені вимоги повинні узгоджуватися керівництвом і технічними фахівцями. Для вимог варто також установити методи виміру, відстеження і формування звітності.
Управлінський підхід. Керування проектуванням і розробкою ПІ повинне носити активний характер. Передача повноважень - непогана річ, однак керівництво не повинне ні відмовлятися від відповідальності й обов'язків, ні самоусуватися, коли мова йде про досягнення чи успіху невдачі. Поряд з іншими задачами керування украй важливо сформувати належну бригаду, що володіє необхідними навичками.
Варто чітко розподілити відповідальність, призначити технічних лідерів і відповідальних керівників, скласти і відслідковувати необхідні плани, виконання яких піддається виміру, стежити за дотриманням вимог, установити обов'язки і винагороди. Крім того, керівництво повинне підтримувати, захищати і постійно тримати в центрі уваги питання постачання і якості.
Технічний підхід. Технічний підхід до проекту визначається технічним персоналом. Технічні фахівці приймають рішення про кількість користувачів, приваблюваних до участі в проекті, а також формі їхньої участі, технології ПІ, стилях, стандартах, розглядають такі питання, як технологія і засоби реалізації, взаємозв'язок з роботами, що не відносяться до ПІ, їхня черговість, підхід до створення прототипів, підхід до оцінки й ітерацій.
Корисне правило. З погляду розробки ПІ, так само як і інших складових програмного продукту, варто починати планувати з малого - проектувати продукт початкового рівня, швидко створювати прототип, проводити тестування на тлі змагання з кінцевими користувачами і поступово нарощувати проект і прототип до рівня повноцінного програмного продукту.
Рішення технічних задач також полягає в тім, щоб, оцінити альтернати ви розробки ПІ з наступних позицій.
o Технологія (объектно-ориентированная чи процедурна) і засобу (4GL чи 5GL).
o Взаємозв'язок ПІ й інших складових ПО (інтегрований чи ПІ окремий ПІ).
o Оцінка (порівняльна чи автономна).
Календарне планування. План створення продукту не Може вважатися завершеним, поки його виконання не піддається виміру, чи поки в ньому документально не зафіксовані календарні терміни основних етапів і постачання компонентів. Основними етапами (mіlestones) називають події, передбачені план - графіком, результат яких можна вимірити. Компоненти, що поставляються - це відчутні робочі продукти, зв'язані з чи діяльністю етапом, стосовно до яких установлюються критерії якості.
Корисне правило. Роботи, у результаті яких не створюються необхідні компоненти продукту, що поставляються, повинні бути критично оцінені до того, як найбільш коштовні проектні ресурси будуть покладені на твердий план-графік. Її чи вони не сприяють удосконаленню продукту, їх не слід виконувати!
Для кожного етапу розробки оцінюється, компоненти, що наскільки поставляються, відповідають критеріям якості; також потрібно складати звіти про досягнуту продуктивність у порівнянні з планом. Відхилення в термінах від внутрішніх ключових подій, що позначають етапи розробки, не обов'язково приводять до негативного результату, оскільки корекцією деяких відхилень можна керувати. Постійні і значні відхилення від очікуваного плану корисні для прогнозування плану-графіка створення продукту і критеріїв якості, в інших випадках необхідні альтернативні рішення, включаючи корекцію плану-графіка, додавання чи ресурсів зменшення обсягу функціональних можливостей.
Корисне правило. Проектний план схожий на план спортивної гри - для досягнення цілей іноді потрібно внесення коректив і виразні вказівки.
До основних проектних подій відносяться завершення етапів формулювання вимог, проектування, конструювання і тестування. Складові для кожного з цих основних етапів включаються в план-графік таким чином, щоб їхній результат піддавався виміру. Наприклад, формування вимог для продукту не завершується без формулювання вимог для ПІ, побудови профілів користувачів, аналізу середовища, аналізу задач і встановлення критеріїв практичності й узгодженості. Крім того, що вимоги розглядаються зі змістовної ' точки зору, вони підлягають перегляду і схваленню відповідно до плану. Аналогічно, етапи проектування і конструювання не завершуються без оцінки "фактичності, що повинна продемонструвати її відповідність вимогам.
Корисне правило. Після етапу традиційного проектування 50% часу розробки для первісної версії програмного продукту приходиться на конструювання, а також на модульне, системне й інтеграційне тестування. Це означає, що як можна більш раннє планування, проектування, прототипирование й оцінка повинні приносити відчутний ефект. Крім того, план повинний передбачати визначену частку гнучкості в уточненні проектних рішень після його інтегрування в систему.
Орієнтований на користувачів план створення продукту.
Що таке план створення продукту, орієнтований на користувачів? Розглянемо наступні передбачені графіком пункти вимірного плану.
o Формування міждисциплінарної бригади для втілення на практиці досвіду користувачів.
o Складання орієнтованого на користувачів плану, що включає
дії по створенню продукту.
o Участь користувачів протягом усього процесу розробки (включаючи
установлення вимог, проектування і тестування).
o Завчасне і швидке здійснення етапів проектування і
прототипирования (починаючи з ранньої візуалізації вимог).
o Завчасна і швидка оцінка практичності (оперативне і эффек-тивное
тестування внутрішніх проектних рішень і продукту стосовно
вимог).
o Плановані проектні ітерації (виправлення помилкових і
удосконалення вірних рішень до повного задоволення вимог).
Заплановано як мінімум три ітерації за участю користувачів.
o Відстеження і формування звітності по внутрішній продуктивності
стосовно до плану-графіка і вимог.
Приклад плану-графіка для ітеративного підходу до ПІ показаний на мал. 8.3. Кожен крок процесу представлений як проміжний етап створення ПІ з вимірними результатами для ключових елементів постачання кожного кроку. До елементів постачання відносяться такі оформлені результати, як мети створення ПІ, специфікація, дослідження ринку, бізнес - прецеденти, розробка (для таких проектних рушіїв як імітатори, прототипи і власне продукт), а також звіти про тестування. Приклад описує три запланованих проектних ітерації (І1, І2, І3), що охоплює задачі проектування, прототипирования, формування специфікації й оцінки для середніх і великих проектів. Невеликі проекти випливають аналогічної моделі з деякими відхиленнями.
Плани визначаються на ранній стадії розробки. Для проміжних етапів удалих проектів характерно те, що вони чітко відділені друг від друга, ретельно відслідковуються, а звіти по їхньому стані формуються з високою частотою. Успішні зусилля по розробці зв'язані з визначенням вимог наступним керуванням і контролем їхнього виконання. Рішення по ПІ і вибір варіантів здійснюються протягом усього циклу розробки, а не тільки в період вироблення специфікації.
Корисне правило. План - графік створення ПІ варто розглядати в трьох; різних тимчасових перспективах.
1. Загальної тривалості проекту (узагальнені етапи).
2. Планування на дев'яносто днів уперед.
3. Деталізації плану-графіка в межах двох тижнів (особливо під час проектування, програмування і модульного тестування (Desіgn, Code, Unіt Test - DCUT)).
Рис. 8.3. Приклад орієнтованого на користувачів плану створення продукту
Погляд з погляду загальної тривалості проекту дає повну картину, односторінкову установку у відношенні ЖЦ проекту і найважливіших етапів. Оскільки проект із більшою тривалістю відрізняється значним ризиком і його хід сутужніше прогнозувати, доцільно сформувати 90-денні відрізки робіт і більш деталізовані проміжні етапи. Незалежно від тривалості проекту двотижневі плани легко осмислювати, прогнозувати, деталізувати, виконувати і відслідковувати.
Для етапів проектування, прототипирования, розробки і тестування визначається кілька проміжних етапів. Кожна ітерація забезпечує додаткове уточнення і нарощування можливостей. На основі результатів чи тестування безпосередніх відкликань користувачів проектні рішення, чи прототип продукт піддаються модифікації. Ітерації продовжуються доти , поки вимоги не будуть задоволені. При цьому потрібно відслідковувати і формувати звіти по продуктивності розробки в порівнянні з планом.
Деталізація плану. Так само, як у випадку фактичного проектування і розробки, з будь-яким планом створення ПІ зв'язана безліч невизначеностей, тому починайте з малого і просувайтеся розважливо. Плануйте невеликі вивірені кроки, чітко визначайте компоненти, що поставляються, відповідальність і якість, розширюйте план і план-графік у міру дозволу невизначеностей.
Приклади подібних вивірених покрокових проектних рішень включають моделі початкового рівня і більш складні компоненти системи, одержувані посредст-вом багатьох проектних рушіїв, чи систему в цілому, одержувану поетапно у виді проектних рушіїв. Рушії (внутрішні чи випуски зборки) для специфікацій, імітаційних моделей, прототипів і ПО продукту корисні з багатьох крапок зору.
Корисне правило. Уміст створюваних у ході проектування функцій варто розділяти на "порції" ПО, що включають діалогові вікна, чи сторінки екрани, а також підтримуючі їхні компоненти і методи.
Нарощування проектних рішень. Один з підходів до розбивки плану полягає в поетапному постачанні вмісту проекту з використанням планованих ітерацій, як показано на мал. 8.4. Ітеративний орієнтований на користувачів план визначає щонайменше три основних ітерації, уміст яких приведене нижче.
" І1 = концептуальні проектні рішення. Проектні рішення для головних, найбільше часто використовуваних і елементів, що відрізняються підвищеним ризиком; дослідження альтернативних рішень, компромісів і обмежень; оцінка інструментальних засобів. Ці рішення базуються на наближеному підході до прототипированию й оцінки.
" І2 20%-ный обсяг проектування. Виправлення і/чи поліпшення рішень, вироблених у ході ітерації І,; додавання 20% функціональних можливостей, використання яких займає 80% часу; аналіз інших областей, що стосується проектування. Ці рішення базуються на точному підході до прототипированию й оцінки.
" І3 = наступні 20%. Виправлення і/чи поліпшення рішень, вироблених у ході ітерації 1^ додавання наступних 20% функціональних можливостей і рішення інших питань, що стосується проектування (проблемні задачі користувачів).
" 14+ = завершення проектування. Виправлення і/чи поліпшення рішень, вироблених у ході ітерації 13; додавання функціональних можливостей, що залишилися, що мають менше значення і які, імовірніше всього можна втілити протягом короткого періоду, що залишився, проектування До прикладів подібних можливостей продукту відносяться повідомлення, малаі використовувані функції і т.д. Для цих елементів розробляються специфікації, вони піддаються перегляду і реалізуються.
Удосконалювання проектних рішень означає внесення змін у проектні сфери для поліпшення характеристик ПО відносно ПІ, практичності й інших критеріїв. Удосконалення носить, як правило, пристосувальний характер (нові ідеї у відношенні кількісного і якісного поліпшення можливостей ПО розвиваються згодом , і рушійною силою в цьому випадку не обов'язково виступають чи користувачі тестування).
Виправлення проектних рішень означає корекцію тих сфер проектування, що приводять до порушення критеріїв, виникненню проблем чи ПІ практичності, а також інших проблем, з якими зіштовхуються реальні користувачі. З завершенням ітерації І3 критерії задоволені і велика частина проблем знаходить свій дозвіл. Наступні ітерації використовуються для уточнення проектних рішень, шліфування і коректування раніше виявлених чи упущених проблем, що є не настільки важливими.
З кожною наступною успішною ітерацією обсяг виправлень, внесених у проект, зменшується. При необхідності плануються додаткові ітерації. При дуже твердих критеріях планують більша кількість ітерацій.
Ітерації І1 - І3 визначають основні ітерації, зв'язані з матеріалізацією можливостей продукту. Кожна основна ітерація може включати кілька дрібних ітерацій, що носять більш деталізований характер.
Корисне правило. Ітерації мають важливе значення тільки тоді, коли мова йде про задоволення критеріїв. У противному випадку про неї не коштує і го-ворить.
o Для традиційного процесу плануйте щонайменше три ітерації.
o Кращим варіантом є 7 ± 2 ітерації.
o Ще краще 100 додаткових ітерацій (жарт).
| Ітеративні процеси і план - графіки
Головний висновок у відношенні ПІ полягає в тім, що сильні критерії рідко вдається задовольнити за одну ітерацію- звичайно для задоволення твердих критеріїв і при припустимому рівні помилок, що залишилися, для практичності і ПІ потрібно кілька ітерацій. Скільки ж ітерацій буде потрібно, щоб досягти перевищуючого шість балів рівня задоволеності користувача, якщо календарний термін проекту складає місяць?
Множинні ітерації дозволяють удосконалювати ПІ за рахунок використання належного процесу, вимірів, тестів і навичок. Що більш важливо - планування чи ітерацій керування ними? Бажане здійснення, як мінімум, o трьох ґрунтовних орієнтованих на користувача ітерацій. Якщо критерії не задоволені, варто повернутися до проектувального "креслярській дошці".
Корисне правило. Ітерації - це метод проб і помилок.
Вплив ітерацій на план-графік. Ітерації не обов'язково напря-мую впливають на збільшення календарного плану (мал. 8.4). Єдина частина проекту, що вимагає змін, це частина, що приводить до відхилення від заданих чи критеріїв до численних проблем практичності. У цих випадках в ефективному проекті спостерігається відставання, яке варто надолужити.
Вартість зміни графіка на даному етапі відносно невелика в порівнянні з традиційними процесами, у яких виявлення подібних проблем затримується аж до стадії пізнього проектування або вони виявляються дуже пізно на етапі конструювання, а іноді і набагато пізніше під час розгортання. У багатьох випадках раннє виявлення подібних дефектів легко компенсується в рамках звичайного плану-графіка розробки. Згодом вартість внесення змін росте экспоненциально.
Вимоги. Основна область проектного ризику- вимоги, що повинні бути сформульовані відразу після початкового періоду їхнього збору. Надалі й у міру того, як інші користувачі, персонал проекту і ситуації змінюються, вимогами необхідно керувати.
Корисне правило. Зосередьте свою увагу на декількох критичних показниках - оптимальних факторах успіху для Проекту.
Вимоги для ПІ звичайно являють собою слабкого місця проекту. Виправити положення, імовірно, може знайомство персоналу, зайнятого розробкою ПІ, з реальними користувачами і їхньою робочою обстановкою. Неофіційні зустрічі й упорядковані спостереження за персоналом, що займається, розробкою ПІ, дозволяють проектній бригаді перейнятися розумінням нестатків реальних користувачів, зрозуміти їхнє соціальне оточення і задачі, а також конкуренцію усередині користувальницького середовища. Для проведення дослідження реального ринку на предмет виявлення нестатків і потреб користувачів застосовуються більш формальні методи.
Бізнес - прецеденти. Коли продукт порівнюють з аналогами на основі переліку можливостей, новий продукт звичайно погано піддається порівнянню з пізніми визнаними продуктами. Однак якщо новий ПІ і продукт виразно зменшують час навчання і підвищують продуктивність (тобто зменшують час виконання задачі), орієнтована на користувачів ділова сторона продукту, демонструє цінність нового ПІ і продукту у відношенні існуючої технології. Результати іспитів практичності показують цінність продукту.
Корисне правило. Критичні проектні рішення повинні базуватися і вимірних і порівнянних ділових критеріях, а також на користувальницьких повагах.
Проектування. При проектуванні ПО і ПІ застосовуйте такі підходи, що щонайкраще зарекомендували себе на практиці. Програму завжди можна поліпшити, але варто знати, коли і на чому зупинитися в реалізації,
Корисне правило. Уникайте прагнення до найкращого можливого проектного рішення. Багато в чому пошук найкращого проектного рішення подібний пошукам священного Грааля. Усе, що потрібно - це проект, що задовольняє вимогам до продукту і ділових потреб користувачів, такий проект знаходиться в межах плану-графіка й обмежень по ресурсах. Невідомо, чи можна взагалі досягти найкращого.
Прототипирование. Ніколи не випустіть з уваги призначення прототипу. Це засіб досягнення кінцевої мети, що складається в найбільш швидкому, ефективному і продуктивному задоволенні Вимог. Варто планувати повсюдне використання прототипу для оцінки проектних альтернатив, що виявляються під час реалізації і наступних випусків ПО.
Корисне правило. Переходити від наближеного до високоточного проектування, прототипированию і методам оцінки випливає якомога раніше .
Специфікація. Опис проекту у виді специфікації справедливо вважається ще однією формою втілення проектних рішень. Різні рівні деталізації розглядаються далі; концептуальний (архітектурний), высокоуровневый ; (усі вікна/сторінки ідентифіковані, а основні- спроектовані) і низкоуровневый (практично всі деталі описані і/чи обговорені).
Програмування/модульне тестування. Результатом напи-сания реального ПО і виконання модульного тестування є програми, що пройшли достатню перевірку для того, щоб тепер розроблювачі уве-ренно могли перейти до системних тестів. Критерієм завершення модульного тестування виступає сертифікація ПІ. Ціль даного етапу- упевнитися, що представлений на деталізованому рівні вид і поводження ПІ коректні. При цьому деталі виступає на рівні, що може бути не включений у специфікацію (наприклад, розташування покажчика миші і початкове виділення елементів при відкритті вікна). Велика частина стандартного поводження платформи не вимагає докладного опису.
Системний і інший види тестування. Основна критика тестиро-вания практичності зводиться до того, що тестування дозволяє оцінити тільки короткостроковий початковий період використання продукту. Це справедливо, якщо тестові прецеденти і тестові моделі не враховують особливостей долговремен-ного використання. Вирішити дану проблему можна, якщо забезпечити виконання заздалегідь запланованих і довільних тестів користувачами на етапі тестування системи в цілому. Для збору довгострокових оцінок практичності продукту протягом усього періоду тестування здійснюється опитування користувачів і застосовуються різні сценарії тестування практичності. Деякі проблеми можна вирішити пізніше під час циклу тестування, однак їхній необхідно враховувати при наступному випуску ПО.
Користувальницькі елементи керування. Стандартних елементів керування ПІ часто буває досить для досягнення необхідних результатів у відношенні практичності. Однак якщо чи бажано необхідна наявність спеціалізованих чи користувальницьких елементів керування, вони спеціально і явно відображаються в плані розробці ПІ. Звичайно розроблювачі недооцінюють обсяг роботи, необхідної для проектування і реалізації користувальницьких елементів керування, що повинні забезпечувати стандартний вид і поводження, зв'язані зі стандартними елементами керування.
Інші роботи, про які звичайно забувають. Під час розробки відбувається багато явно незапланованих речей. У кожної організації свій унікальний набір сюрпризів. До прикладів такого роду відносяться презентації і демонстрації продукту замовникам і керівництву, участь у торгових виставках, зміна версії чи розробки інструментальних засобів на середині шляху, більшість мережних проблем, відпустки і свята.
Переконаєтеся в тім, що відомі і невідомі несподіванки передбачені і враховані. Прикладами подібних сюрпризів можуть служити, наприклад, аварія орієнтованої на ЛВС середовища розробки протягом ЖЦ чи проекту ситуація, коли ключовий учасник проекту хворіє тривалий час протягом ЖЦ проекту. Проектні плани-графіки і призначення повинні мати запас міцності з погляду виникнення різного роду ризиків.
Оцінка. У табл. 8.1 показані фактори, що впливають на GUі-ориентированное ПО, який варто враховувати при розробці. Для Web-орієнтованого і PDA- орієнтованого користувальницького інтерфейсу також характерні деякі на цих факторів.
Таблиця 8.1. Типові фактори, що класифікують, для GUі-ориентированного додатка
Таблиця 8.1. Типові фактори, що класифікують, для GUі-ориентированного додатка (закінчення)
Корисне правило. Для кожного вікна/сторінки ПІ варто передбачити докладну декомпозицію робіт з їхнього створення. Цей метод особливо корисний для чи розроблювачів бригад, що вперше займаються інтерфейсом і не мають достатній досвід їхньої структуризації.
Корисні правила календарного планування. При складанні планів-графіків великих проектів і створенні складного ПО можна використовувати приведені нижче оцінки календарної тривалості робіт.
" Концептуальне проектування - 8 тижнів.
" Початкова ітерація з використанням прототипу - 6-8 тижнів.
" Проектування, прототипирование і підготовка до тестування - 6 тижнів.
" Тестування, аналіз і планування наступної ітерації - 2 тижні.
" Высокоуровневое проектування/прототипирование/оцінка/специфікація -1-2 місяця.
" Низкоуровневое проектування/прототипирование/оцінка/специфікація -
2-3 місяця.
" Кожен користувальницький елемент керування - 2-3 місяця (для розробки елемента керування може знадобитися програміст, зайнятий повний робітник день; сюди включають проектування/прототипирование/оцінку/специфікацію).
Табл. 8.2 побудована виходячи з тривалості проекту.
Повторюваний процес. Основні етапи проектування і розробки ПІ і конструювання практичності, безумовно, повторюються при створенні кожного програмного продукту. Деякі стандартні "інгредієнти" ПІ, такі як елементи керування й інструментальних засобів, залишаються постійними. Однак розходження в необхідних навичках, компонентах і деталях реалізації приводять до деякого відхилення від загального "рецепта". Наприклад, навички в області проектування і розробки змінюються від проекту до проекту, тому що змінюється прихильність досягненню поставлених цілей у відношенні ПІ і практичності. Іноді усвідомлювана потреба заявити про подібному загальному "рецепт" і неухильно випливати його розпорядженням превалює над його якістю. Погодженості можна досягти тільки за рахунок митецького використання "інгредієнтів" і щирої прихильності результатам.
Зменшення часу циклу. Зменшення часу і вартості розробки важливо для будь-якого проекту, однак особливе значення воно здобуває для споживчих програмних продуктів і Web-середовищ. Підхід до зниження часів циклу створення ПО дуже простий і полягає в тому, щоб уникнути помилок у вимогах, проектних рішеннях і програмах. ПІ і практичність відносяться до областей, що мають потребу в значно меншому науковому обґрунтуванні, чим проектування і розробка програмних компонентів, не зв'язаних з ПІ. У довгостроковій перспективі час циклу розробки вимагає істотного зниження зусиль по створенню ПІ в міру нагромадження досвіду й удосконалювання вхідних у нього "інгредієнтів". З погляду короткочасної перспективи для ітеративної розробки ПІ за участю користувачів (поки вимоги до нього не будуть задоволені) необхідна тверда прихильність поставленим цілям. Порівнянною метою у відношенні продуктивності може служити зниження кількості перезаписів модуля для досягнення часу відгуку, що складає частки секунди, і цільових настанов по пам'яті.
Увесь час прислухатися до користувачів. Протягом усього часу виконання плану, що веде до постачання продукту, і випливаючи запропонованому "ре-цепту", не забувайте постійно прислухатися до думки користувачів. Остаточне рішення у відношенні якості ПІ, виготовленого по вашому "рецепті", завжди залишається за споживачами. Більш докладно методи ефективного обліку думки користувачів розглянуті в главі 6.
Персонал, навички й інші ресурси
Проектування і розробка ПІ, а також забезпечення практичності ПО з використанням відомих стилів ПІ вимагають твердих навичок і уміння працювати спільно. Жоден з фахівців окремо не має всі знання, необхідними для виконання різних задач. Необхідний набір навичок, якими повинна володіти орієнтована на користувачів бригада по створенню продукту, був розглянутий у главі 5. Крім того, бригаді потрібні чіткі цілі, належна підтримка з боку керівництва, інструментарій, приміщення і відповідний настрой, щоб справитися зі складною роботою.
Корисне правило. Не слід недооцінювати важливість наявності в бригаді відповідного кількості фахівців, що володіють визначеним типом навичок.
Навички, необхідні для проекту, відображаються на специфічні ролі орієнтованої на користувачів бригади по створенню продукту. Одна людина може виконувати кілька ролей, однак для гарантії успіху серед учасників бригади повинні бути встановлені тісні взаємини.
Корисне правило. Кожен учасник бригади повинний мати достатні навички для виконання декількох ролей. Якщо деякі фахівці не підходять, їхній можна задіяти в іншому проекті. План-графік розробки повинний враховувати існуючий рівень навичок і особливості формування проектної бригади.
Більш докладно технічні і загальні навички, необхідні для ефективної по-ставки продукту, що задовольняє вимогам до практичності, ПІ, согласо-ванности і т.п., розглянуті в главі 4.
Організаційні розуміння. Подібно тому, як існує вибір між різними моделями розробки, існують і різні організаційні моделі, які можна використовувати для орієнтованої на користувача розробки продукту. До розробки можна застосувати наступні характерні для виробництва підходи.
" Одна бригада формулює вимоги і передає їх бригаді, що будує архітектуру.
" Архітектурна бригада передає результати своєї роботи однієї чи декільком бригадам проектувальників.
" Кожна бригада проектувальників передає результати своєї роботи однієї чи декільком конструкторським бригадам.
" Кожна конструкторська бригада передає свої результати бригаді зборки і тестування.
Зайво говорити про те, як багато інформації губиться при кожній передачі.
Альтернативний підхід складається в створенні єдиної орієнтованої на користувачів бригаді розроблювачів продукту, що супроводжує продукт починаючи з етапу планування і формування вимог на всьому шляху аж до етапу розгортання. Єдині проектні рішення формулюються, втілюються у виді прототипу і специфікації, а потім тестируются під керівництвом однієї і тієї ж бригади.
Корисне правило. Процеси і підходи, в основі яких лежить використання невеликих бригад, найкраще зарекомендували себе у відношенні надання замовникам результатів, що відрізняються високим рівнем практичності.
Лідерство. За роботу орієнтованої на користувачів проектної бригади і постачання замовникам ПІ, що задовольняє вимогам, персонально відповідає менеджер бригади. Очолює бригаду і відповідає за постачання замовникам продукту, що задовольняє вимогам у відношенні ПІ і практичності, технічний фахівець.
Корисне правило. Успіх продукту - заслуга всіх учасників бригади. Якщо ж продукт зазнає невдачі, повинне бути ясно, хто і за що несе відповідальність.
Засобу реалізації. З проведеного раніше аналізу інструментальних засобів ясно, що для успіху проекту необхідно забезпечити наявність багатьох видів засобів і устаткування. Ніж раніш необхідні засоби будуть отримані, тим краще.
Обмеження. Орієнтованої на користувачів бригаді розроблювачів продукту приходиться працювати в умовах безлічі обмежень, зв'язаних з ис-пользованием тих чи інших інструментальних засобів розробки й ОС. Одержавши інструментарій, бригада визначає характер цих обмежень і враховує їх у подальшій роботі.
Планування стосовно до основних
факторів практичності
"Усе, що може зіпсуватися, псується". Чи йде мова про стабільність системи, чи продуктивності вічно насущній проблемі якості, непередбачені обставини в ході реалізації календарного плану розробки повинні розглядатися виходячи з того, наскільки ви упевнені у своїй здатності вирішити ту чи іншу проблему.
Корисне правило. Для кожної області проекту, представленої в план - графіці , передбачите щонайменше два тижні додаткового часу.
Завдання вимірних оцінок. Після того як робота структурована і деталізована, бригада реалізації оцінює тривалість проектування, програмування і модульного тестування для кожної функціональної можливості.
Корисне правило. Бригада програмістів повинна уміти виконувати оцінки в термінах SMOP-одиниць (Small Matter of Programmіng Unіts - невеликі програмістські питання), де
" 1SMOP = підлога клуні робочого дня програміста (4 години);
" 1 тиждень = 32 програмістських години.
Розподіл задач реалізації. При календарному плануванні етапів UDCUT необхідно врахувати деяку форму перегляду высокоуровневых проектних рішень і специфікації. Попросите бригаду розроблювачів продукту назвати реальні дати етапів UDCUT. Це змусить бригаду реалізації мислити в термінах здійснення безупинних етапів
" проектування для ПІ і реалізації (UD - User Іnterface Desіgn);
" реалізації (З - Constructіon - Code);
" модульного тестування (UT - Unіt Testіng).
Табл. 8.3 є прикладом можливого схематичного розподілу задач, зв'язаних із проектуванням і розгортанням одного екрана. Як альтернативу таблицю можна використовувати на рівні додатка, незважаючи на те, що велика частина робочих деталей при цьому може бути загублена.
Корисне правило. Перекриття задач проектування в принципі можливо, однак планувати випливають послідовні задачі реалізації.
Необхідно запланувати контрольні перевірки для підтвердження завершення концептуального, высокоуровневого і низкоуровневого проектування.
Продовження обговорення проекту:
складання плану
Йде другий тиждень проекту і робоча лихоманка продовжується. Лідер проекту дотримав обіцянки надати попередню оцінку, план-графік проекту й оцінки можливих ресурсів для проекту. На вас покладена загальна відповідальність за ПІ, практичність і колектив людей, вовлеченных у розробку. Вам доручено написати план розробки ПІ і план проекту, орієнтованого на користувача (User-Centered Desіgn - UCD), а також план-графік для проекту в цілому.
План і план-графік для ПО, що не відноситься до ПІ, складає ваш колега по бригаді; він завірив вас, що вимоги будуть підтримані без усяких питань з його боку. Припустимо, що його наміри і запевняння реальні.
Вище керівництво зажадало оцінки і план-графік для першочергового постачання деякого Web-орієнтованого фрагмента всього проекту. Згодом залишилася частину ПО проекту можна розподілити по етапах. У вашу задачу входять рекомендації у відношенні плану-графіка.
Потреба в ресурсах і план-графік повинні бути представлені вищому керівництву завтра рано ранком. У вашому розпорядженні біля двох годин на відпрацьовування запиту; як тільки він буде готів, ви повинні проінструктувати лідера проекту. Вам потрібно надати попередні оцінки по наступним пунктах.
" Необхідні ресурси і навички.
" Можливий план-графік (на наступні двох тижнів, на наступні 90 днів, на увесь час проекту).
" Потенційна послідовність етапів по реалізації можливостей, включаючи першочергове постачання Web-компонента.
" Області ризику для продукту, користувальницького інтерфейсу і практичності.
" Ймовірна кількість ітерацій і плановий час здійснення кожної з них.
Не забудьте відбити ключові задачі й етапи в деякім представленні плану-графіка (наприклад, завершення набору орієнтованої на користувачів проектної бригади, завершення підбора користувачів, що беруть участь у проекті, а також ідентифікацію основних характеристик проекту для первісного проектування і прототипирования).
Подбайте про те, щоб провести пошук інформації в Іnternet, що могла ; би виявитися потенційно корисної при плануванні і розробці проекту. ; Питання?
Посилання
Brooks F. The Mythіcal Man Month, Addіson-Wesley: New York, 1995.
Cantor M.R. Object-Orіented Project Management, Wіley & Sons: New York, 1998.
Gould J. et al. Makіng Usable, Useful, and Productіvіty Enhancіng Computer Applіcatіons, Communіcatіons of the ACM, Jan. 1991.
A Guіde to Software Usabіlіty, ІBM Corporatіon: Purchase, NY, SC26-3000. > Karat З Cost-Benefіt Analysіs of Іteratіve Usabіlіty Testіng, ACM/SІGCHІ Tutorіal, May 1991. і McConnell. Rapіd Development, Mіcrosoft Press: Redmond, WA, 1996.
MayHew D. Managіng the Desіgn of the User Іnterface, ACM/SІGCHІ Tutorіal, May 1991.
Nіelsen J. The Usabіlіty Engіneerіng Lіfe Cycle, Computer Magazіne, Mar. 1992.
Rettіg. Іnterface Desіgn When You Don't Know How, Communіcatіons of the ACM, Jan. 1992.
Torres RJ. User Іnterface Desіgn and Development, Westlake Reflectіons, 1991.
Глава 9
Вимоги
Як причини невдалої розробки програмних продуктів найчастіше називають дві, що мають пряме відношення до вимог: недолік ясних, визначених і вимірних вимог, а також обмежений контроль за вимогами під час розробки. Можливо, існує і третя, зв'язана з вимогами причина невдач проектів, що ще недостатньо добре усвідомлений - недолік ясних вимог у відношенні практичності, ПІ, погодженості, комплектації, користувальницьких і ділових потреб і чекань.
Крім збору інформації, специфічної для ПІ, практичності, погодженості, інтеграції, часу відгуку і вивчення продукту немає нічого чи унікального істотного для цього роду вимог, що не зустрічалося б у процесі збору функціональних вимог. При звертанні до цих питань корисні ті ж методи, що і при зборі функціональних вимог. Основна відмінність складається в розміщенні акцентів і точці зору при визначенні того, чи зібрані дійсно необхідні зведення.
Найбільш важку частину збору вимог складає робота з людьми для визначення їхніх реальних нестатків і запитів. Вимоги необхідно збирати при розробці будь-якого продукту. Причина цього криється в зміні потреб користувачів, їхніх ділових нестатків, а крім того, змінюється їхнє сприйняття й усвідомлення власних потреб. Основна проблема, зв'язана з розроблювальним продуктом (незалежно від етапу розробки), складається в зборі і керуванні введенням нових Вимог у процесі розробки.
При зборі вимог необхідно приймати в увагу розуміння як технічного, так і соціального порядку. У залежності від масштабів змін технічні розуміння виникають при удосконаленні ненадійного і хитливого ПО в процесі тестування. Існують і фактори соціально-психологічного характеру, що роблять вплив на утомлену і переведену бригаду розроблювачів, що намагається забезпечити стійкість "дурно" ведучого себе ПО на близьких до завершення розробки і пропасних етапів конструювання і тестування. При цьому часто виникають питання "Що ж робити?" і "Чому зараз?".
У цій главі розглядаються наступні питання.
" Ключові можливості системи.
" Підхід до збору вимог.
" Вимоги до ПІ.
" Вимоги по практичності.
" Як зробити вимоги наочними і вимірними.
" Вимоги для обговорюваного проекту.
Акцент у даній главі робиться на ключовій інформації, що стосується ПІ, практичності, користувачів, бізнесів-процесів і джерел цієї інформації; методам, застосовуваним для збору подібних вимог, приділяється значно менше уваги.
Ключові можливості системи
Практичність і якість ПІ програмних продуктів залучають усе більша увага і здобувають значення як характерна риса, що забезпечує конкурентну перевагу. У міру того як перелік функцій продуктів збільшується (він розростається до таких немислимих розмірів, що стає просто нереалізованим у рамках прийнятного часу і вартості), користувачі, що відповідають за придбання продуктів, усі частіше звертаються до інтерфейсу. Якщо ПІ продукту робить враження простого для вивчення і використання, продукт має всі шанси одержати конкурентна перевага, особливо якщо він претендує на зниження витрат при освоєнні, а з погляду продуктивності обіцяє реальні вигоди.
Тепер, коли читач одержав загальне представлення про те, які види інформації необхідні, має бути зрозуміти, де шукати вимоги для ПІ і практичності. Як правило, подібні вимоги не записуються за винятком випадків представлення вимог на дуже абстрактному рівні. Тому орієнтована на користувачів бригада розроблювачів продукту формує вимоги, користаючись багатьма джерелами, до яких відносяться поточні бізнеси-процеси, користувачі і системи (мал. 9.1).
Питання: Як ви можете усвідомити необхідність і достатність вимог, якщо ви погано інформовані про їх?
Існуюча документація. Як джерела явних і неявних вимог виступають прецеденти (Use Case), функціональні вимоги, функціональні специфікації і довідники по діловій діяльності. Приклади інших джерел інформації- презентації, проведені замовниками, стратегічні документи і документи опису бізнесів-процесів .
Вимоги до ПІ додатків звичайно представлені на дуже високому рівні й у них бракує специфіки. Звичайно вимоги до ПІ продукту включають такі формулювання.
" Варто забезпечити GUі-интерфейс.
" ПІ повинний відповідати платформі ОС і корпоративному стилю.
" Інтерфейс повинний бути простим у вивченні і легенею у використанні.
У порівнянні з вимогами до функціональних можливостей, вимоги до ПІ залишають великий простір для інтерпретації й уяви, однак існуючі документи можуть служити непоганою відправною крапкою для розуміння потреб продукту.
Рис. 9.1. Вимоги в процесі орієнтованої на користувача розробки продукту
Задачі користувачів і ділові процедури. Задачі кінцевих користувачів вимагають гарного опису разом із з'ясуванням розподілу частоти їхнього виконання. Наприклад, використання правила "80/20" допомагає зосередити увагу на класифікації і виявленні пріоритетності задач. 20% задач включають ті, котрі виконуються чи рідко які мають невелике значення для користувачів, чи організації замовників; 80% задач складають задачі, що виконуються більш часто, найбільш піддані помилкам, обходяться дорожче і\чи впливають на діяльність організації, користувачів і замовників. Володіючи подібною інформацією, можна використовувати підхід, спрямований на оптимізацію системи для досягнення найкращих результатів, а це дозволяє уникнути побудови деякої усередненої системи, націленої на усереднення результати стосовно до всіх категорій задач і користувачів.
Рис. 9.2. Вимоги з погляду бізнесу, користувачів і системи
Крім виявлення задач, що коштують перед користувачем, корисно ознайомитися з процедурами, яким випливають користувачі в процесі виконання роботи. З процедурами зв'язані протоколи роботи кінцевих користувачів, що відображають соціальну практику й угоди, що впливають на спосіб виконання роботи. Програмні ПІ і системи можуть конструюватися таким чином, щоб відповідати протоколам так само, як процедурам і задачам. Інформацію цього типу одержують, використовуючи такі методи залучення користувачів, як спостереження, інтерв'ю і фокуса-групи .
Більш докладно задачі користувачів розглядаються в главі 10.
Опис користувачів. Поряд з описом функціональних возможно-стей необхідна деталізована інформація про кінцевих користувачів. Кінцеві користувачі не складають безлику масу. Кожен користувач- це особистість з унікальними навичками, поглядами і знаннями. Орієнтована на користувачів бригада по розробці продукту описує розмаїтість навичок, поглядів і знань для цільової групи користувачів. Опис користувачів повинен бути досить повним, щоб проектувальники і розроблювачі ПІ могли зрозуміти потенційних користувачів, усвідомити розходження їхніх навичок і відносин. Вимоги повинні також включати аналогічну інформацію, що стосується користувачів країни, для якої розробляється продукт. Цю інформацію одержують за допомогою опитувань, під час спостереження і за допомогою інших методів залучення користувачів у розробку.
Більш докладно моделі користувачів розглядаються в главі 10.
Оцінка використовуваних продуктів. Використання методів реверсивної інженерії дозволяє сформулювати вимоги, ґрунтуючись на існуючій системі (reverse engіneerіng- один з напрямків дисципліни, відомої як реинжиниринг програмного забезпечення (software reengіneerіng), що займається реконструкцією існуючих систем з наступною переробкою і реалізацією нових проектних рішень. - Прим. ред.). Перелік функцій, необхідний дані, час відгуку, потік задач, що тече інформація і методи побудови ПІ виводяться (реконструюються) на основі аналізу існуючої системи. Потреби організації і користувачів додаються до вимог і піддаються перегляду з погляду їхньої повноти і пріоритетів.
Оцінка практичності існуючої системи допомагає зрозуміти загальне оточення системи. Ключову інформацію з практичності системи і бізнесів-процесів одержують для введення метрик і критеріїв успіху. Вимоги для ПІ і системи в цілому допомагають установити еталонні значення для продуктивності і рівня задоволеності користувачів, що досягаються при заданих підходах. На загальному рівні можна назвати наступні ключові критерії.
" Ефективність роботи користувачів в існуючій середовищі.
" Задоволеність користувачів системою.
" Відношення користувачів ( чиподобається не подобається) до існуючого системі.
" Що потрібно користувачам замість того, що їм доступно.
"
Для аналізу поточної середовища підходять формальні і неформальні методи, що забезпечують якісні і кількісні оцінки.
Що стосується існуючого середовища, то варто пам'ятати про те, що вона включає інше ПО, що знаходиться в розпорядженні користувачів. Інші програмні пакети, доступні в користувальницькій системі, містять офісні пакети й інші програми, що підтримують роботу користувачів.
Корисне правило. Варто проаналізувати усі ПО, що знаходяться у вживанні користувачів, а також способи взаємодії різних пакетів.
Оцінка конкуруючих продуктів. Поряд з існуючими використовуваними продуктами до інших джерел даних по можливостях, ПІ, інформаційній підтримці і практичності відносяться реальні конкуруючі й аналогічні продукти. Конкуруючі й аналогічні продукти розглядають з використанням методів, застосовуваних для оцінки існуючих продуктів.
Корисне правило. Після того як вимоги зібрані, оформите їх документально і перевірте їх на предмет повноти, важливості і необхідності стосовно існуючого й іншим систем.
Галузеві оцінки. Є чимало джерел інформації у виді галузевих публікацій. Іноді в публикуемых методах і деталях досить важко розібратися і зрозуміти, наскільки їм можна довіряти. Однак ця інформація служить ще одним важливим джерелом для перевірки важливості і практичності тих чи інших можливостей. Галузеві організації і журнали, а також організації і Web-вузли, що роблять консультаційні послуги, забезпечують величезні обсяги інформації, що може виявитися корисної при оцінці концепцій.
Користувачі і спонсори. Якщо ви сумніваєтеся, запитаєте користувача. Групи користувачів представляють важливе джерело вимог і як не можна краще підходять для перевірки того, наскільки вірно були визначені частота використання і пріоритети функціональних можливостей і характеристик. Не забувайте підтримувати постійну вовлеченность спонсорів проекту і вкладників у процес визначення вимог. Методи спільної розробки ідеально підходять для збору і перевірки вірогідності вимог.
Можливості ПІ. Щоб задовольнити потреби користувачів, організацій і замовників, вимоги до програмного ПІ повинні бути конкретними. Нижче приведені приклади можливостей ПІ, загальні для графічних і Web-орієнтованих інтерфейсів, а також інтерфейсів портативних пристроїв.
" Підтримка графіки (вікна, піктограми, графічні елементи керування і
т.д.)
" Меню (рядок меню і выпадающие меню, що спливають меню, каскадні меню, панелі інструментів).
" Представлення (компонування, схема і т.д.).
" Засобу навігації (схема web-вузла, путівники типу "хлібних крихт" у т.д). ("Хлібні крихти"- оператори, що вбудовуються спеціально в програму отладочные, що служать дороговказною ниткою для пошуку причин аномального поводження програми при налагодженні- як рятівні хлібні крихти в казці братів Гримм, де герої блукали по лісі. - Прим. ред.)
" Клавіші швидкого вибору команд ("гарячі клавіші") і клавіші, що прискорюють, (клавіша, що відповідає підкресленій букві в рядку меню мулу діалогу. - Прим. ред.).
" Засобу маніпулювання (Перемістити, Копіювати й інші команди).
" Спеціальні операції (Зберегти, Печатка, Копіювати в буфер, Скасувати/Повторити і т.д.).
" Мінімалізм (у відношенні продукту й інформації).
" Настроювання (клавіатура, миша, послідовне розкриття інформації і
т.д.).
" Альтернативні пристрої введення і висновку.
Важливо знати розподіл частоти використання цих можливостей, оскільки багато проектувальників ПІ вірять, що деякі з цих методів застосовуються нечасто. Реалізація" рідко використовуваних методів знижує здатність продуктів до забезпечення інших, більш корисних функцій.
Можливості мультимедиа. Вимоги до програмної підтримки графіки, візуальних і мультимедиа можливостей повинні бути конкретизовані з урахуванням необхідних функцій. От приклади візуальних і мультимедиа можливостей.
" Статична графіка, використовувана в піктограмах, заголовках і інших візуальних умовних знаках.
" Анімаційна графіка, що служить для повідомлень, сигналів і інших цілей.
" Чутна інформація, використовувана для повідомлень, сигналів і інших цілей.
Важливо знати розподіл частоти використання перерахованих вище воз-можностей, оскільки багато хто з цих методів сприймаються як саме собою що розуміється і не додають безпосередньої ділової цінності повсякденним задаємо кінцевих користувачів.
Можливості інформаційної підтримки. Вимоги до програмної інформаційної підтримки повинні бути більш конкретними з крапки фения необхідних функцій. Приклади інформаційних можливостей наступні.
" Друковані довідники і робоча підтримка.
" Аудиторні заняття, інтерактивні посібники.
" Допомога, "майстра-програми", картки-шпаргалки, запрошення, контекстні вікна покажчика.
Необхідно знати частоту, з яким використовуються ці можливості, оскільки багато хто з них застосовуються рідко через недоліки існуючих методів. Реалізація рідко використовуваних методів знижує здатність бригади розроблювачів Продукту до реалізації інших більш корисних і ефективних функцій.
Обмеження. Для багатьох підприємств характерна наявність ограничитель-ных чи мір обставин, що не дозволяють чи організації співробітникам Досягти визначених цілей. Надзвичайно важливо знати, на який ступінь волі і гнучкості можна розраховувати, а також бути обізнаним про існуючі межах обмежень. Прикладом "волі" може служити вимога "усунути всі перешкоди", прикладом обмеження - "п'ять фахівців, зайнятих протягом шести місяців".
Тенденції. Знати, у якому напрямку розвивається галузь більш важливо, чим розуміти її поточне стан, оскільки галузь рухається дуже швидко - розвивається технологія, інсталяційна база, розширюються знання користувачів. Значення соціальних процесів також велико, хоча вони більш трудноуловимы, чим технічні. Документація з описом вимог повинна розглядати тенденції змінам у рамках того тимчасового інтервалу, на який розраховане використання ПІ.
Підхід до збору вимог
Нижче приводиться типовий сценарій збору вимог.
" Кінцевий користувач звертається до керівника.
" Керівник звертається до представника Ит-подразделения.
" Представник Ит-подразделения звертається до менеджера Ит-подразделения.
" Менеджер Ит-подразделения звертається до фахівця з планування розвитку продуктів.
" Фахівець із планування розвитку продуктів звертається до бригади розроблювачів.
Це дуже непрямий шлях збору вимог, при якому значна частина інформації губиться в процесі передачі. Щоб у більшому ступені стежити за по-требностями ринку, орієнтованої на користувачів бригаді розроблювачів не-обходимо більш прямий спосіб збору вимог. В існуючі процеси вовлечено так багато рівнів визначення й інтерпретації, що реальні потреби губляться в накопиченні думок.
Для збору, структуризації, документування і перевірки обґрунтованості вимог корисні такі методи, як JAR (Joіnt Applіcatіon Requіrements - спільне вироблення вимог) і JAD (Joіnt Applіcatіon Development - спільна розробка додатків), засобу підтримки прийняття рішень, фокуса-групи, спостереження, контекстні інтерв'ю, конкурентні оцінки, анкетування, аналіз задач, прецеденти, сценарії, прототипирование, а також інші методи залучення користувачів у розробку. При зборі вимог варто враховувати процеси і потреби, зв'язані з існуючими і майбутніми користувачами, веденням бізнесу і замовниками. Діяльність по керуванню змінами повинна бути спрямована на прогнозування потреб, обумовлених змінами середовища діяльності користувачів у майбутньому.
Корисне правило. Аналогічно іншим проблемним областям, зв'язаним зі створенням продукту, вимоги підкоряються правилу "80/20" у відношенні значимості і повноти. 20% вимог визначають найбільш істотні риси системи і її ПІ, вони найбільш критичні для проектування і розробки. Інші 80% вимог важливі, але не настільки істотні з погляду базових потреб чи бізнесу розробки.
Найбільш важливі аспекти задачі - систематизований підхід до збору вимог, узгодження з реальними майбутніми користувачами ПО, взаємодія з Діловими спонсорами і згода по вимогах. Результатом подібних зусиль є набір вимог, що відповідає потребам користувачів, спонсорів і розроблювачів.
Корисне правило. Варто знати, що вимоги найкраще сприймаються у виді окремих команд і екранів прототипу ПІ, тоді користувачі зможуть оцінити і схвалити властивості і практичність цього прототипу.
При зборі, структуризації і призначенні пріоритетів потребам організації надзвичайно корисні таблиці. Іноді для того щоб зафіксувати й упорядкувати необхідну інформацію досить простої електронної таблиці. Кожен рядок електронної таблиці описує дуже просту і відособлену вимогу, що сприймається кінцевим користувачем і може бути відображене на ПІ. Корисно вказати джерело і дату одержання усіх вимог для наступного їхнього відстеження. Щоб упевнитися в тім, що бригада має необхідні навички розробки, що відповідають вартості і ризики враховані, а графік^-графіки-плани-графіки робіт складені, проектні вимоги повинні бути проаналізовані проектною бригадою.
Корисне правило. Таблиці вимог необхідні на всьому протязі ЖЦ проекту, оскільки до них можна додати стовпці для визначення можливостей, що уже наочно представлені в ПІ, а також відображення результатів тестування вимог.
Схвалення Вимог. Узгодження і схвалення вимог користувачами бригадою розроблювачів відіграють важливу роль у програмних проектах. Користувачі, спонсори й організації-розроблювачі повинні забезпечити стійкість вимог так, щоб планування, проектування і розробка продукту знайшли прийнятне завершення.
Корисне правило. Помнете про правило "80/20" на етапі схвалення вимог.
Для ділових користувачів схвалення вимог до системи завжди доставляє незручність - ніхто не хоче зв'язувати себе чи зобов'язаннями брати на себе відповідальність за рішення, що можуть стати причиною невдалого продукту. З одного боку, розроблювачі не хочуть створювати продукт, в основі якого лежать незатверджені вимоги, з іншого боку - усіх хочуть надати продукт саме в той час коли він здатний у достатній мері задовольнити потреби як организа-
і, так і користувачів.
Відстеження змін. Це та область, у якій орієнтована на користувачів бригади розроблювачів продукту, працюючи в тісній взаємодії з організаціями-замовниками й організаціями розроблювачами, допомагає підтримувати довіру, необхідне в сучасній швидко змінюється середовище^-середовищу-середі-бізнесі-середовищі і середовищі розробки. Після того як базисний набір вимог визначений, керування змінами стає пекучим питанням.
Корисне правило. При відстеженні змін у вимогах необхідна велика дисциплінованість, чим при первісній фіксації вимог.
Зміни самі по собі не несуть шкоди. Велика частина змін відрізняється простотою й обходиться недорого, однак некеровані вимоги, незалежно від витрат, несуть смертельну небезпеку для бізнесу і проекту. Щоб установити перераховані нижче фактори, орієнтована на користувачів бригада розроблювачів продукту працює з усіма зацікавленими в проекті сторонами.
" Зміни у вимогах до продукту, вигоди, потенційні втрати oі нездійснення змін і ділові ризики.
" Потенційні впливи змін на вартість проекту, план-графвд; ресурси і ризики.
Потім зміни, що передбачається внести в розроблювальний продую" піддаються оцінці як заявлений діловий ризик- співвідношення вигод і упрівай для зацікавлених сторін, щоб усі зважити і прийняти рішення.
Вимоги до ПІ
Крім ідентифікації основних можливостей ПІ вимагаються визначені ключові характеристики поводження і зовнішнього вигляду ПІ. Якщо евристика для ПІ відома, вона включається у вимоги - це просто служить підказкою при визначенні критерію успіху!
Корисне правило. Якщо чи функція характеристика ПІ припускає вимір, звітність, відстеження і є основою для дій, то неї варто визначати як частина вимог до продукту.
Деякі питання, зв'язані з вимогами, можуть показатися несподівані мі, інші - загальними проблемами для ПІ. Нижче приведені очевидні питання, що повинні ввійти у вимоги.
" Стиль ПІ.
" Платформа й інші стандарти ПІ для додатка.
" Сумісність з ведучим ПО, що працює на даній платформі (наприклад, додаток X чи пакет Y).
" Зміст екрана (наприклад, дані і функції, необхідні в ключові моменти виконання задач).
" Поводження екрана (наприклад, вхідний фокус на першому елементі керування при відображенні екрана).
" Характеристики зовнішнього вигляду екрана (наприклад, використання графіки для відображення даних, представлення і эстетические властивості).
" Методи взаємодії користувачів із системою (наприклад, доступ до команд, способи утворення комбінацій клавіш і т.д.).
" Можливості роботи з клавіатурою, включаючи поводження засобів табуляції і циклічну роботу клавіші табуляції.
" Зворотний зв'язок користувача у відповідь на стан системи і час відгуку.
" Користувальницький контроль над різними функціями.
" Запам'ятовування результатів операцій розташування і зміни розмірів вікна, а також даних, стану і контексту.
" Можливості навігації для додатка.
" Збереження даних користувача при навігації.
" Запам'ятовування проміжних даних користувача при навігації.
" Інтерактивне навчання, підтримка продуктивності і довідкова система.
" Запобігання помилок і відновлення системи після помилок.
" Методи прямого введення для усунення діалогу.
" Перевірка правильності значень полів, а також ідентифікація необхідних полів.
" Стандартне використання кольору, індикаторів, графіки і т.д.
" Засобу забезпечення доступу для користувачів з фізичними недоліками.
Багато хто з перерахованих вище питань ПІ найчастіше явно і конкретно не фіксуються в посібниках зі стилю ПІ, документах опису чи вимог специфікаціях продукту. Однак обґрунтованість даного підходу залежить від того, наскільки часто ви зіштовхуєтеся з подібними проблемами.
Основні вимоги по практичності
Вимоги по практичності легко встановлювати в невизначеному і важкому для виміру виді, наприклад, "забезпечити легкість використання системи" чи ,,система повинна бути зрозумілої на інтуїтивному рівні". Цілком імовірно, що не всі члени орієнтованої на користувачів бригади розроблювачів чи продукту користувачі системи погодяться зі значенням цих чи вимог з тим фактом, що вони досягнуті. Такі якості системи, як практичність, легкість використання і наочність безумовно залежать від їхнього сприйняття користувачами і діловими спонсорами проекту. Проте , можна зробити ці вимоги більш відчутними, зрозумілими і поддающимися виміром.
У табл. 9.1 перераховані стандартні чи часто використовувані метрики, що можу бути корисними при фіксації практичності ПО. І знову, ціль полягає в тому, щоб неявні вимоги перетворити в явно виражені і поддающиеся вимір. Цей список можна поповнити й іншими вимогами.
Таблиця 9.1. Приклади вимог по практичності
Можлива подальша класифікація помилок на основі аналізу їхніх наслідків для чи користувача замовника. Наприклад, деякі помилки користувачів позначаються на роботі організації, хоча і не впливають на клієнтів цієї організації, у той же час наслідку деяких прорахунків позначаються як на організації, так і на її клієнтах. Такий вплив можна вимірити в термінах серйозності помилок, що виражається у втратах від їхніх чи наслідків витратах на ліквідацію цих наслідків для чи споживача її клієнтів.
Корисне правило. Якщо характеристика практичності припускає вимір, звітність, відстеження і є основою для дій, то неї варто визначати як вимога.
Підтримка задач і потоку робіт. Очевидно, що програмний продукт повинний підтримувати задачі кожного користувача при заданих вимогах і обмеженнях. Однак типова ситуація, коли виконання користувачем однієї задачі може перериватися іншими задачами. Як правило, користувач відкладає
Перемінну задачу, виконує задачу, що викликала переривання, а потім повертається перерваній задачі і завершує її.
Важливо визначити вимоги, зв'язані із середовищами, у яких користувач повинний працювати в многозадачном режимі з тим самим додатком. Нижче приведений перелік найбільш важливих характеристик, зв'язаних з виконанням користувачем задач і потоками робіт.
" Кількість підтримуваних переривань задач.
" Функціональні можливості, підтримувані під час переривань і навігації.
" Підтримка ПІ під час переривань.
Корисне правило. Вимоги многозадачности, як правило, впливають на кількість яких мається на увазі чи реальних екземплярах того самого додатка, відкритих в окремих чи вікнах броузерах.
Погодженість. Передбачається, що програмний чи додаток пакет повинні бути внутрішньо согласованны і сумісні з ПО, що працює на тій же платформі, по декількох ключових моментах. Погодженість торкається концепції, термінологію, а також графіку і візуальний стиль і зовнішній вигляд екранів. Погодженість також стосується стилю взаємодії користувача із системою і використання елементів керування ПІ (наприклад, погодженість поводження і виду списків, що випадають, для платформи базової операційної системи і прикладного ПО). Погодженість являє собою основну область неявних і невизначених припущень, що стають вимірними і явними завдяки застосуванню наступних критеріїв.
" Відсутні які-небудь відхилення від стандартів платформи (наприклад, погодженість екранного "поводження" клавіатури і чи миші стандартних і користувальницьких елементів керування ПІ).
" Відсутні які-небудь відмінності між додатками.
" Рівень задоволеності користувачів у відношенні погодженості складає більш 90%.
Корисне правило. Необхідно прагнути до усунення яких-небудь відмінностей (тобто шукати доступне і задовільне несуперечливе рішення щодо погодженості й інших вимог по практичності).
Інтеграція. Ще одна важлива вимога - безперешкодна інтеграція з ПО. Традиційна інтеграція даних звичайно забезпечується по всьому прикладний ПО з використанням команд буфера обміну (Вирізувати, Копіювати, уставити), прямого чи маніпулювання інших команд, що здійснюють обмін чи даними спеціальний запуск інших додатків з передачею даних. Для якісних і кількісних вимог задаються конкретні і вимірні критерії, що забезпечують їхнє тестування і верифікацію.
Конкуруючі продукти. У визначених середовищах корисним методом формування вимог служить виявлення існуючих внутрішніх і зовнішній конкурентних продуктів. Потім для продукту встановлюються якісні і кількісні вимірні цілі стосовно продуктів-конкурентів. При вимірній меті час рішення задачі на 15% менше, ніж при використанні конкуруючого продукту. Приклад якісної мети- перевага, що віддається користувачами продукту в порівнянні з попередниками в співвідношенні 10:1.
Інші важливі Вимоги. Нагадаємо, що загальний рівень задоволеності і практичності представляє функцію декількох параметрів. Ціль забезпечення визначеного рівня задоволеності і практичності для користувачів зв'язана насамперед з такими характеристиками системи, як час відгуку, надійність і загальний рівень якості системи. Для організації-розроблювача ПО важливим фактором виступає пристосованість ПО до супроводу. Іноді подібні вимоги називають нефункціональними вимогами.
Як зробити вимоги вимірними і наочними
Успіх проекту істотно залежить від чіткої взаємодії між спонсорами проекту, користувачами і бригадою розроблювачів. Після аналізу й узгодження вимоги перетворяться в узагальнені і деталізовані плани і плани-графіки розробки продукту. Потім вимоги і планові питання відображаються в ПІ і підтримуюче його ПО. Навички бригади оцінюються з погляду їхньої достатності і всі підлягаючі виконанню дії плануються.
Наочні Вимоги. Функціональні вимоги легко представити в різному виді, зручному для їхнього відстеження. Щоб перелічити функціональні вимоги, досить простої електронної таблиці плану проекту. Додаткові стовпці електронної таблиці використовуються для відображення факту виконання визначених вимог на конкретну версію програмного чи продукту дату реалізації вимоги.
Характеристики ПО чи практичності також відображаються в електронну чи таблицю план проекту. Однак відслідковувати вимоги до ПІ звичайно більш складно. Наприклад, якщо для ПІ одного з додатків програмного пакета встановлена загальна вимога по запам'ятовуванню дій користувача і стани вікна, та ця вимога відображається на кожне чи вікно сторінку додатка. Процес відстеження вимог ускладнюється, коли вони чи змінюються заново відображаються на кожен чи екран вікно, яке потрібно змінити.
Більш широкі вимоги системного рівня також повинні бути наочними. Щоб перевірити виконання вимог, проектний план повинний, як мінімум, передбачати контрольні крапки для інформаційної підтримки, графіки, практичності, погодженості, ефективності, інтеграції й інших факторів.
Публікація вимог. Вимоги повинні бути завжди доступні всім зацікавленим у проекті сторонам. Приступність приймає форму друкованої чи електронної документації, прототипи і розкадрування вимог, а також презентацій. Звичайно використовується кілька типів комунікації.
Корисне правило. Для керування змінами варто надавати ин формацію, зв'язану з відстеженням вимог, по всіх аспектах вимог.
Призначення пріоритетів вимогам. Немає нічого незвичайного в тім, що обсяг вимог набагато перевершує можливості їхньої реалізації за прийнятний час. Перелік вимог, орієнтованих на можливості продукту, має тенденцію дуже сильно розростатися. У цих випадках важливо установити пріоритети для нарощуваної і поступової реалізації.
Корисне правило. При встановленні пріоритетів корисний наступний прийом: спробуйте задатися питанням: "Якщо я можу зробити тільки що-небудь одне, те що саме?" Ціль полягає в тому, щоб визначити, які можливості можна чи відкласти взагалі не реалізовувати. " чиБуде нанесений збиток проекту, якщо я не зроблю цього?"
Твердження вимог. Аналогічно проектним планам і іншим компонентам продукту, що поставляються, вимоги до продукту схвалюються, і зацікавлені сторони приймають на себе зобов'язання. Ключовими фігурами процесу схвалення виступають спонсори проекту і розроблювачі. Однак за одержання затверджених вимог, що відповідають визначеному рівню якості, відповідають усі зацікавлені в проекті сторони. Обличчя, відповідальні за твердження вимог, вникають у проектні плани і твердження приймає наочну і вимірну форму. Після твердження вимоги стають предметом процедур керування змінами в міру виникнення потреби в реинжиниринге бізнес - процесів.
Корисне правило. Після того як схвалені чи вимоги узяті зобов'язання, які-небудь виверти неприпустимі.
Вимір і відстеження. Коли вимоги визначені, схвалені і прийняті до реалізації, вони відображаються на план-графік розробки разом з беруть участь у їхнє реалізації ресурсами. Кожен пункт роботи план-графіка розробки відображається в пункт документації, що містить вимоги. Кожна робота, виконувана розроблювачем, відображається у вимогу і план-графік розробки. Проектування, конструювання і тестування формуються відповідно до прийнятих вимог. По ходу розробки легко зрозуміти, коли вимоги досягнуті.
Продовження обговорення проекту:
формулювання вимог
Ваша нарада з вищим посібником з перегляду узагальненого плану пройшло надзвичайно вдало. План був схвалений, ви одержали кілька завдань: забезпечити оцінку кількості вікон, Web-сторінок і екранів; представити наближену оцінку кількості годин, необхідних для розробки вікна, Web-сторінки й екрана пояснити, на які компроміси прийдеться піти в зв'язку з застосуванням объектно-ориентированного підходу і методів на зразок мови UML. Відлік проектного часу почався.
Проект відрізняється масштабністю і, видимо, буде продовжувати розширюватися в змісті функціональності, складності й абстрактних питань. Перелік можливостей був отриманий усно, а також за допомогою електронної пошти від потенційних покупців продукту і вищого керівництва. У число потенційних покупців увійшли дуже престижні і великі професійні організації, що проводять регулярні конференції по усьому світі.
Одна з першочергових задач проектного плану полягає у формулюванні вимог. Вам необхідно з'ясувати, скільки вимог має бути зібрати і перевірити, а також визначити ймовірний" порядок постачання компонент. Вище керівництво продовжує випробувати натиск фінансових проблем і шукає шляху як можна більш швидкого випуску продукту. Лідер проекту відзначив, що вище керівництво також висловило побажання здійснити основне постачання функціональних можливостей і забезпечити відповідний останнім досягненням рівень практичності стосовно до додаткових платформ у рамках першого випуску.
План-графік також дуже напружен. Контакти з потенційними покупцями ПО показали, що трохи клієнтів могли б використовувати продукт уже через дев'ять місяців починаючи із сьогоднішнього дня.
До потенційних нових технологій, застосування яких можливо в продуйте, відносяться беспроводные книги в електронному форматі, а також електронні пристрою, здатні завантажувати і зберігати великі обсяги інформації і взаємодії, що володіють виразними можливостями, з користувачами.
Лідер проекту прийшов до вас з такими завданнями.
1. Підготувати коротка інформаційна нарада для вищого посібника з наступного питанням: яким образом зібрати, зафіксувати в документації і затвердити проектні вимоги, призначити їм пріоритети, скласти календарний план їхньої реалізації і включити його в робочий план проекту. Як звичайно, нарада повинна відбутися завтра ранком і на підготовку у вас близько 30 хвилин. Менеджер проекту підкреслив важливість плану-графіка й обґрунтованість пропозицій.
2. Підготувати й оформити документально найбільш важливі можливості про-дукта в тім виді, у якому вони представляються вам на сучасний момент. Для цілей реалізації установити пріоритети і послідовність реалізації можливостей. На це приділяється не більш однієї години.
3. Підготувати й оформити документально вимоги до ПІ продукту, интегра-ции, інформаційній підтримці, графіці, практичності, часу відгуку і надійності. Описати, як ви забезпечите конкурентноздатність розроблювального продукту, а також перевага над існуючими і перспективними методами його розгортання. На це приділяється не більш напівгодини.
4. ґрунтуючись на вже зібраних вимогах, переробити зміст і план - графік первісного випуску продукту. Це необхідно зробити як і раніше в припущенні постачання Web - орієнтованого компонента не пізніше, ніж через дев'ять місяців, починаючи із сьогоднішнього дня. Розглянути, які навички вимагаються для постановки продукту і коли саме вони знадобляться.
5. підготувати відповіді на завдання, дані вищим керівництвом для підготовки цієї інформації у вашому розпорядженні мається друга година.
Вимоги являють собою основу для майбутньої роботи над проектом. Подбайте про те, щоб провести пошук інформації в Іnternet, зв'язаної з методами збору вимог, а також вимог, що відносяться до вашого проекту. Для відпрацьовування запиту у вас біля чотирьох годин.
Питання?
Посилання
Schneіder G., and Wіnters J. Applyіng Use Cases: A practіcal Guіde, Addіson - Wesley: New York, 2001.
Torres R.J. User Іnterface Desіgn and Development, Westlake reflectіons, Apr.1992.
Wіegers K. Software Requіrements, Mіcrosoft Press; Redmond, WA,1999.