Студопедия
Случайная страница | ТОМ-1 | ТОМ-2 | ТОМ-3
АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатика
ИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханика
ОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторика
СоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансы
ХимияЧерчениеЭкологияЭкономикаЭлектроника

Мозковий штурм (МШ)

Читайте также:
  1. А на "ТБ-1" и "ТБ-3" Вы как штурман летали один? Или Вас там, в фюзеляж набивали как сельдь в бочку, и вы прокладывали маршруты?
  2. А почему штурмовики не задействовали?
  3. Были ли случаи, что бы штурман сажал "ДБ"?
  4. Было такое при сопровождении групп самолетов или штурмовиков, что если были потери от истребительной авиации, то боевой вылет не засчитывался?
  5. В мемуарах отмечается, что ваш 73-й ГИАП начиная с 1944 года, почти все время использовался только на сопровождении штурмовиков и бомбардировщиков. Насколько это верно?
  6. Вы фиксировали результаты ударов штурмовиков? Я имею в виду – они вам запросы на подтверждение присылали?
  7. Г.В.: То есть, вы не только осуществляли прикрытие, но и сами штурмовали, и вас снаряжали бомбами. Расскажите, как вы тогда штурмовали Котлы.

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

МШ є дуже корисним методом при проведенні нарад і в тих випадках, коли потрібні нові ідеї або творчі рішення проблем.

МШ представляє собою набір прийомів, корисних в тих випадках, коли учасники збираються разом.

Даний процес має ряд переваг:

- Підтримує участь всіх присутніх;

- Дозволяє учасникам розвивати ідеї один одного;

- Ведучий або секретар веде запис всього ходу обговорення;

- Його можна застосовувати при різних обставинах;

- Як правило, в результат - множина можливих рішень для будь-якої поставленої проблеми;

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

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

Виділяють:

«Живий» мозковий штурм.

«Веб» мозковий штурм

Всі учасники збираються в одній кімнаті і їм роздаються матеріали для заміток. Це може бути звичайна стопка паперу і чорний товстий маркер. Кожному учаснику потрібно видати не менше 25 листків паперу на кожний сеанс МШ. Далі пояснюються правила проведення мозкового штурму і визначається мета засідання.

Правила проведення:

1. Не допускається критика або дебати.

2. Необхідно дати волю фантазії.

3. Необхідно генерувати якомога більше ідей.

4. Можна переробляти і комбінувати ідеї.

Ведучий пояснює мету процесу. Наприклад наступні питання представляють собою декілька варіантів постановки мети:

1. Якими властивостями, по Вашому, має бути наділений продукт?

2. Які послуги, по Вашому, має надавати продукт?

3. Які параметри, по Вашому, має відслідковувати продукт?

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

Кожний учасник записує свої ідеї на листочки. Це важливо по наступним причинам:

- Щоб вони було сформульовані саме словами автора.

- Щоб гарантувати, що вони не будуть втрачені

- Щоб їх можна було розвивати далі (в подальшому).

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

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

Інколи під час генерації ідей виникає період затишшя. Це не значить, що пора зупиняти процес. Таке затишшя закінчується, як тільки з’являється нова ідея. Більш тривалі періоди затишшя можуть бути приводом для того, щоб ведучий знову повторив мету або задав аналогічне питання. Більшість нарад по генерації ідей триває близько години (інколи 2-3 години). Не при яких умовах ведучий не повинен закінчувати засідання, що активно йде. Для учасників це буде означати «Ваші ідеї не такі важливі, як мій графік». Число ідей, що виникли залежить від того, наскільки плідний предмет, що обговорюється (зазвичай їх 100-200).

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

Відбір ідей

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

Відсічення (відтинання)

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

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

Групування ідей

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

Нові функції;

Питання продуктивності;

Пропозиції по покращенню існуючих функцій;

Інтерфейс користувача і питання простоти користування.

Групи можуть бути спеціально орієнтовані на можливості системи і способи підтримки різноманітних типів користувачів.

Визначення функцій

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

Розстановка пріоритетів

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

1. Накопичувальне голосування: стодоларовий тест. Кожному учаснику видається 100$ «ідейних грошей», які можна потратити на купівлю ідеї. Кожному учаснику пропонується записати на листку паперу, скільки грошей він виділяє на кожну ідею. Потім, коли учасники проголосують, ведучий підраховує результати і пропонує порядок класифікації. Можна зобразити гістограму, щоб наглядно представити результат учасникам.

Наприклад:

Ідея 1 - 380$

Ідея 2 - 200$

Ідея 3 - 180$

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

2. Розбиття на категорії «критична, важлива, корисна»

Кожному учаснику дається кількість голосів, що рівне кількості ідей, кожний голос має відноситися до однієї із трьох категорій «критична, важлива, корисна». Суть метода в тому, що голоси, що належать кожному учаснику, розподілені по категоріям рівномірно (одна третина «критична», одна третина «важлива» і одна третина «корисна»); відповідно, тільки одну третину ідей учасник може віднести до критичних.

- Критична – обов’язкова. При відсутності даної функції учасник не зможе користуватися системою. Без неї система не буде виконувати свою основну місію. Тому немає сенсу робити систему без цієї функції.

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

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

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

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

Мозковий штурм з використанням Веб

Якщо всіх зацікавлених осіб можна зібрати разом і вони являються відносно активними і не дуже сором’язливими, ведучий – досвідчений, то ефективно використовувати «живий» МШ.

Але інколи «живий» МШ неможливий. В цих ситуаціях альтернативою є використання Інтернет або локальної мережі для організації МШ шляхом створення дискусійної групи. Цей метод особливо підходить для розробки перспективних додатків, коли необхідні дослідження або довготривалі прогнози, концепція спочатку неясна і вимагається широкий діапазон поглядів (думок) велика кількість користувачів і зацікавлених осіб.

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

Створення прототипів

Прототипування (prototyping) - це найбільш часто використовуваний сучасний метод виявлення вимог. Програмні прототипи конструюються для візуалізації системи або її частини для замовників з метою отримання їхніх відгуків.

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

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

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

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

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

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

 

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

Класифікація прототипів:

В даний час усі види прототипів прийнято класифікувати наступним чином:

- За призначенням: горизонтальні і вертикальні;

- За глибиною опрацювання: одноразові і еволюційні

- В залежності від використовуваних інструментальних засобів: розкадровки і електронні прототипи

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

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

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

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

 

Вертикальні прототипи

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

"Одноразовий" прототип (досліджуваний прототип) (ОП), який після того, як виявлення вимог завершено, просто відкидається. Розробка "одноразового"прототипу націлена лише на етап встановлення вимог ЖЦ ПЗ. Як правило, цей прототип дозволяє вирішити незрозумілості і покращити вимоги до ПЗ.

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

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

Еволюційний прототип (evolutionary prototype), який зберігається після виявлення вимог і використовується для створення кінцевого програмного продукту. Еволюційний прототип націлений на прискорення поставки продукту.

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

На відміну від одноразових прототипів, що створюються «швидко та начорно», для побудови еволюційного прототипу необхідно з самого початку використовувати відмінний і якісний код. Тому на конструювання еволюційного прототипу потрібно більше часу.

Остаточний продукт – кульмінація серії еволюційного. Такі прототипи дозволяють користувачам швидко отримати діючі зразки. Еволюційний прототип добре підходять для застосувань, які з часом будуть розширятися. (Інтернет застосування).

Паперові і електронні прототипи

Не завжди для вирішення невизначеностей в вимогах потрібний прототип у вигляді виконуваного коду. Паперовий прототип (низькоякісний) – дешевий і низько технологічний спосіб з’ясувати, як може виглядати деякий фрагмент системи. Паперові п допомагають встановити, чи дійсно користувачі і розробники однаково розуміють вимоги. Схожий метод «раскадровка» показує пропонує мий інтерфейс користувача, без залучення користувачів до роботи. (Тут людина грає роль комп’ютера. Вона ініціює дії, промовляючи в слух, що збирається робити в конкретному екрані (наприклад, при виборі меню).

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

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

Електронний прототип (electronic prototype) заснований на використанні мов програмування високого рівня абстракції, таких як Java, Perl, Python, Haskell і т.п.

Розкадровка

Розкадровка (storyboard) - це логічний та концептуальний опис функціональних можливостей системи для певного сценарію, включаючи необхідну взаємодію між системою та її
користувачами. В якості інструментальних засобів розкадровки вимог використовуються Microsoft Word, Microsoft Visio, Microsoft PowerPoint, IBM Rational Requirements Composer, Expression
Blend SketchFlow.

Розкадровки ділять на три типи:

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

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

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

 

 

07.03.2012 Стандарти SADT та діаграма потоків даних

 

Методологія САДТ – одна з найвідоміших методологій аналізу проектування систем. Більше 10 років САДТ була «перервою» та технологією, до середини 80х років, поки не з»явилися ПК з графічними можливостями.

Одним із перших програмних компонентів структурно-функціонального аналізу на основі САДТ був пакет AUTOIDEF, розроблений в межах програми ВПС США.

 

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

Моделі, що орієнтовані на функції називають функціональними, а на предмети системи – моделями даних.

 

За допомогою САДТ методології вирішуються наступні основні задачі:

· Аналіз функцій, що виконується системою;

· Опис специфікацій вимог і функцій системи, що проектується

· Проектування системи.

 

Метод САДТ представляє собою сукупність правил і процедур, призначених для побудови функціональної моделі об’єкта будь-якої предметної області.

Функціональна модель САДТ відображає функціональну структуру об’єкта. Тобто вироблені ним дії і зв’язки між цими діями.

 

Основні елементи методу САДТ ґрунтуються на наступних концепціях:

1. Графічне представлення блокового моделювання

2. Строгість і точність

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

 

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

 

Правила САДТ:

1. Обмеження кількості блоків на кожному рівні (3-6)

2. Зв’язність діаграм (номери блоків)

3. Унікальність міток та найменувань (відсутність імен, що повторюються)

4. Синтаксичні правила для графіки (блоків і дуг)

5. Розділ входів і управлінь (як правило визначення ролі даних).

 

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

 

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

 

13.03.2012 Лекція 10

 

Діаграма потоків даних (DFD) являються основним засобом моделювання функціонування вимог до системи, що проектується. З їх допомогою ці вимоги представляються у вигляді ієрархії функціональних компонентів (процесів), зв’язаних потоками даних.

Головна мета такого представлення – продемонструвати, як кожний процес перетворює свої вхідні дані у вихідні, а також виявити відношення між цими процесами.

 

Для побудови ДФД традиційно використовуються дві нотації, що відповідають методам Йордана і Гейна-Сарсона. Ці нотації дещо відрізняються один від одного графічним зображенням символів.

 

Основними компонентами ДФД є:

1. Зовнішні сутності

2. Процеси

3. Накопичувачі даних

4. Потоки даних

 

Тема: Специфікація вимог до ПЗ (модуль 2)


Дата добавления: 2015-09-06; просмотров: 194 | Нарушение авторских прав


Читайте в этой же книге: Лекция 3. Процеси призначення системи | Визначення та розробка вимог до ПЗ | Лабораторна робота | Контроль статусу вимог | Процеси ДА |
<== предыдущая страница | следующая страница ==>
Методи встановлення та виявлення вимог| Способи представлення вимог

mybiblioteka.su - 2015-2024 год. (0.024 сек.)