Экспертные системы

Содержание

Введение………………………………………………………………3

1. Кто создаёт прототипы?..................................................................5

2. Как далеко заходить при создании прототипа?............................6

3. Определение сферы охвата прототипа…………………………..7

4. Инструменты и технологии……....................................................8

Введение 
 
     Разработка прототипа — средство, позволяющее проанализировать идеи, прежде чем потратить на них время и деньги. Все опытные мастера и инженеры создают образцы своих изделий до того, как начинают что-либо строить. Архитектор создаёт модель из бумаги или картона, либо с помощью виртуальных инструментов. Авиаинженеры используют аэродинамическую трубу. Строители мостов разрабатывают модели для исследования нагрузки. Разработчики ПО и веб-дизайнеры создают модели, имитирующие взаимодействие пользователя с их разработками. 
 
     Самая веская причина для создания прототипа — экономия времени и ресурсов. Ценность прототипа заключается в том, что он является внешней оболочкой — как декорации на съёмочной площадке в Голливуде, где построены только фасады зданий. По сравнению с реальным продуктом прототипы просты и недороги в разработке. Таким образом, при минимальном вложении средств можно обнаружить ошибки создателей и юзабилити проблемы, и улучшить пользовательский интерфейс до того, как сделаны значительные инвестиции в окончательную разработку и технологии. 
 
     Рассматривая потребности конкретного проекта, можно найти и иные причины для создания прототипа, нежели экономия денег. Может, его цель заключается в изучении новой модели интерфейса? В изменении одной из частей существующей разработки? В исследовании новой технологии? Необходимо с самого начала чётко представлять, что и зачем вы делаете. Если вы приступаете к выполнению задачи с чётко определёнными целями, ваши усилия будут более целенаправленными и эффективными. 

 
     Причины создания прототипов подразделяются на три основные категории:

1. Проверка идеи. В некоторых командах существуют разногласия, в каком направлении следует развиваться проекту. При помощи прототипа можно показать, что та или иная идея имеет практическую ценность. Прототип может доказать, что концепция работает, продемонстрировать её свойства визуально или интерактивно, и/или подтолкнуть участников команды обдумать проблему с иной точки зрения.
2. Изучение дизайна. При разработке интерактивных продуктов единственным способом изучить, как что-либо будет использоваться, является создание экспериментальной модели и взаимодействие с ней. Иногда такая модель нацелена на изучение удобства использования продукта, позволяющее последовательно оценить элементы прототипа. Иногда это просто способ чётко и ясно разъяснить разработчику, как что-то должно работать или выглядеть. Часто разработчик просто экспериментирует в поисках предпочтительного подхода. Любой член команды может использовать прототипы для изучения вопросов дизайна, хотя обычно лучше всего для этого подготовлены разработчики. Изучение дизайна должно быть направлено на решение конкретных проблем, которые были обнаружены в продукте.
3. Изучение технологии. Разработчики, исследующие пути решения проблемы, часто пробуют различные приёмы написания кода, чтобы выяснить, который из них подходит лучше всего. Использование COM+, DHTML, Win32 или каких-либо определённых методов кодирования в рамках каждой технологии связано с определенными компромиссами. Иногда прототип позволяет провести зондирование и выяснить, какая технология лучше подходит для поддержки определённой функции пользовательского интерфейса.

      
Кто создаёт прототипы? 
 
     Неофициальные прототипы может создавать кто угодно, вне зависимости от его образования или роли в проекте. Создать простой, но эффективный прототип нетрудно. Например, взять растровое изображение из Adobe Photoshop, импортировать его в Microsoft® FrontPage®, программный пакет для создания и управления веб-сайтами, добавить активные кнопки и ссылки. Подобные простейшие прототипы годятся только на определённом этапе и непригодны для моделирования более сложного взаимодействия. 
 
     В зависимости от области применения и степени проработки деталей, прототипы можно создавать на любой стадии выполнения проекта. Чаще всего это бывает на ранних этапах, на этапах планирования или постановки технического задания, до того как разработчики приступят к написанию кода. Именно тогда необходимость всестороннего исследования возможных проблем велика, а инвестирование времени наиболее оправданно. Если прототип создаётся разработчиками, а не менеджером проекта или проектировщиками, планирование времени приобретает ещё большее значение, так как в этом случае необходимо предусмотреть время на создание прототипа в графике разработки. При создании любого пользовательского интерфейса нужно оставлять некоторый запас времени на разработку прототипов. 
 
      

Как далеко заходить при создании прототипа? 
 
     Не акцентируйте внимание на дизайне при создании прототипа. Делайте ровно столько, сколько необходимо для его функционирования. Не беда, если некоторые кнопки не работают, а текст никогда не обновляется. Главное — возможность реализовать взаимодействия, которые необходимо исследовать. 
 
     Вот несколько причин, почему следует внимательно распределять усилия:

1. Стоимость создания прототипа. Все хотят минимизировать расходы, связанные с построением прототипа. Поэтому очень важно определить минимальный объём средств, которые можно потратить, не нанеся ущерба эффективности. Поэтому так важно тестирование юзабилити, так как оно может точно определить части пользовательского интерфейса, которые потребуют больших усилий. Даже без проведения такого тестирования надо чётко определить, какие пользовательские проблемы должны быть решены, какие параметры должны быть улучшены.
2. Ограниченный жизненный цикл. Прототипы должны иметь чётко определённый жизненный цикл. Надо определить какова конечная цель. Устроить презентацию на командной пятиминутке? Провести совещание по поводу окончательного анализа проекта? Сделать разбор технического задания? Провести юзабилити тестирование продукта? Убедиться, что разработка решит проблему пользователя? Как только достигнуты конкретные цели, прототип следует отложить в сторону. Код прототипа или его растровое изображение должны быть на время забыты. В исключительных случаях часть кода или наглядные элементы позднее используются в продукте, но рассчитывать на это не стоит.
3. Риск увлечься. Показ прототипов разработчикам и другим членам команды не всегда идет на пользу. Слишком сложный и детально разработанный прототип, захватывающие воображение интерфейсы и анимация, могут чрезмерно увлечь людей. Всегда следует отдавать отчёт, насколько далеко можно зайти и насколько серьёзно должно восприниматься то, что включено в прототип.

Определение сферы охвата прототипа 
 
     Как только оговорены основные моменты, на которых следует сосредоточиться при создании прототипа, надо задуматься о следующем:

1. Нужды потребителя. Если вы начинаете с осмысления ключевых вопросов или нужд вашего пользователя (возможно, юзабилити инженер может подкинуть пару хороших идей), значит, вы имеете представление, какие детали требуют наибольшего исследования.
2. Задачи тестирования на удобство использования. Если прототип создаётся для проведения юзабилити тестирования продукта, следует обсудить с юзабилити инженером, какие конкретные задачи должны быть решены во время тестирования, и отталкиваться от этих задач при создании прототипа.
3. Командный вклад. Беседуйте с ключевыми разработчиками по мере того, как идеи относительно создания прототипа начинают обретать контуры. Совместными усилиями надо определить, что представляется разумным, что является возможным, а что вовсе неприемлемо для будущего релиза. В некоторых случаях можно выйти немного за рамки того, что разработчики считают возможным относительно какого-либо аспекта разработки. Но только если этот аспект является ключевым моментом, и выход за рамки будет мотивировать команду. Однако не следует делать этого по отношению ко всем аспектам разработки. Пытаясь расширить границы возможного, очень легко деморализовать команду. Если требуется вдохновить коллектив наглядным показом возможных вариантов, можно пойти на этот шаг. Однако если необходимо определить конкретные изменения для следующего релиза, усилия следует сосредоточить на этих изменениях. Необходимо убедиться, что они вносятся модульно, чтобы разработчики видели путь построения разработки.
4. Ширина или глубина? При создании больших прототипов следует определиться что предпочесть — ширину или глубину. Прорабатывать поверхностно все функции, либо выбрать одну и разрабатывать прототип, реализовывая все её возможности? Если по неразумению сделать это одновременно, получится громоздкий прототип, который сложно модифицировать и жалко выкинуть.

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

• Microsoft Visual Basic. Это самая быстрая технология для создания прототипов пользовательских интерфейсов под Windows. Объект веб-браузера упрощает интегрирование пользовательского интерфейса, написанного на HTML, в стандартные компоненты Windows. Но верно и то, что разработчик, имеющий опыт работы с Microsoft Visual Studio, может создать пользовательский интерфейс на C/C++ быстрее, что создаёт соблазн повторно использовать код прототипа пользовательского интерфейса в коде конечного продукта. Нужно ясно понимать, что черновой прототип пользовательского интерфейса сильно отличается от конечного кода. Менеджер проекта должен удостовериться, какого рода код создаётся на конкретном этапе, и понимать, что именно может быть отброшено.
• Macromedia Director или Flash. Это один из самых популярных среди проектировщиков инструментов для создания прототипов пользовательских интерфейсов. Он наиболее ценен при разработке прототипов мультимедийных приложений или нестандартных графических интерфейсов, а также очень хорош при создании прототипов, которые требуют значительного использования анимации. Но недостаточная гибкость делает его неуклюжим по сравнению с Visual Basic при создании пользовательских интерфейсов под Windows. Однако искусный пользователь Director?а может генерировать интерфейсы под Windows или для веб-страниц без всяких проблем.
• HTML. Microsoft® FrontPage® и прочие HTML-редакторы позволяют создавать несложные прототипы. Для выражения своей идеи часто приходится создавать изображения, чтобы проиллюстрировать последовательность действий пользователя, и импортировать их во FrontPage®. Затем можно соединить страницы ссылками и сымитировать взаимодействие с программой. JScript и DHTML обеспечивают новый уровень возможностей, позволяя использовать очень сложную программную логику и механизмы взаимодействия. При использовании HTML для создания прототипа сайтов (так же, как и в вышеуказанном примере с кодом на C/C++) не следует попадаться в ловушку и считать сделанный на скорую руку код прототипа окончательным.