Жизненный цикл программного продукта

ПРОЕКТИРОВАНИЕ ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА

2.1. ЖИЗНЕННЫЙ ЦИКЛ ПРОГРАММНОГО ПРОДУКТА

По истечении почти двух десятков лет активного использования компьютерных технологий Министерство обороны США пришло к выводу, что основной причиной неудач крупных информационных проектов является методология их реализации (точ­нее, ее отсутствие). От неприятных сюрпризов не могли спасти ни опытные менеджеры, ни исчерпывающее тестирование, ни применение CASE-средств. Каждая новая обнаруженная ошибка заставляла почти полностью пересматривать проект. И даже, если в конце концов удавалось получить приемлемый результат, при поступлении следующе­го заказа картина повторялась. Осознание указанного обстоятельства заставило Мини­стерство обороны США сделать шаг в направлении стандартизации процессов разра­ботки программных систем. Первый стандарт был утвержден в 1985 году, а в 1994-1996 годах был разработан и принят новый, значительно более детальный и глубокий стан­дарт — MIL-STD-498. Он представляет собой комплект из трех документов общим объемом около 600 страниц и устанавливает терминологию, процессы, задачи и объек­ты, используемые при разработке и сопровождении проектов программных систем. Основные положения этого военного стандарта согласованы с международным стан­дартом ISO/IEC 12207:1995 («Процессы жизненного цикла программных средств»), но вместе с тем являются более конкретными и приближенными к практике.

В нашей стране попытка стандартизации процессов создания программных сис­тем вылилась в создание комплекта документов под общим названием «Единая система программной документации», который увидел свет еще в 1977 году (да, были времена, когда мы оказывались впереди планеты всей не только в области балета) и периодически корректировался вплоть до последнего времени.

При весьма заметном различии в деталях все известные стандарты используют в качестве исходного положения понятие жизненного цикла программного продук­та (или системы).

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

 Практически все стандарты (даже военные) предусматривают возможность их адаптации к особенностям конкретного проекта при условии соблюдения основных требований к технологии и показателям качества продукта. Например, на этапе формирования требований к системе должны учитываться:

•      область применения системы;

•      требования пользователя (заказчика) к функциональным возможностям сис­темы, к уровню ее безопасности и защищенности;

Рекомендуемые материалы

•      эргономические требования и требования к уровню квалификации пользователей;

•      степень документированности системы;

•      организация сопровождения и т.д.

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

ПРОЕКТИРОВАНИЕ

Начальный этап в разработке программного продукта (приложения) является наиболее критичным, поскольку на этой фазе определяется общая концепция со­здаваемого продукта. Если проект в своей основе неудовлетворителен, впослед­ствии трудно будет что-либо кардинально изменить в лучшую сторону.

Эта часть процесса разработки включает не только определение цели и характе­ристик приложения, но и понимание того, кто является его потенциальными пользо­вателями — их задачи, намерения, цели. Это предполагает учет таких показателей, как например, возраст пользователей, их пол, экспертные знания, уровень опыта, физические ограничения, специальные потребности и т.д. Продумайте структуру приложения и метафоры, которые могут быть применены при ее реализации. Реше­нию указанной проблемы способствует наблюдение за работой пользователей при выполнении ими задач в данной предметной области.

Представьте проект разработки в письменной форме; это не только обеспечива­ет важную контрольную точку в процессе создания приложения и средство взаимо­действия с пользователями, но часто помогает сделать проект более конкретным и выявить нерешенные вопросы.

ПРОТОТИПИРОВАНИЕ

После того, как определены основные концепции проекта, разрабатывается прототип создаваемого приложения, отражающий некоторые основные аспек­ты его функционирования. Это может быть сделано с помощью ручки и бума­ги; в зависимости от уровня вашей подготовки и сложности приложения его прототип может быть представлен либо в виде иллюстраций интерфейса (внеш­не они могут напоминать картинки из комиксов), либо в виде специальных схем (в частности, в виде сетей Петри). На последующей стадии может быть создана модель (или макет) проектируемого приложения — действующее программное обеспечение, использующее либо специальные средства макетирования (напри­мер, какую-либо CASE-систему), либо обычные инструментальные средства про­граммирования.

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

Форма представления прототипа зависит от цели разработки. Действующие про­тотипы обычно наиболее полно позволяют оценить качество механизма взаимо­действия пользователя с разрабатываемым приложением, т.е. качество интерфейса.

ИСПЫТАНИЕ ПРОГРАММНОГО ПРОДУКТА

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

Первое и наиболее важное отличие обусловлено различными целями этих двух процессов: отладка имеет целью выявление дефектов (ошибок) программирова­ния, в то время как в ходе испытаний вы оцениваете, насколько полно разработан­ное приложения (в частности, его интерфейс) отвечает потребностям и ожиданиям пользователя. Конечно, имеющиеся программные ошибки могут иногда повлиять на качество интерфейса, но это скорее исключение, чем правило.

Второе принципиальное отличие состоит в том, что отладку выполняет непос­редственно его разработчик, а основным действующим лицом при проведении ис­пытаний является потенциальный пользователь (заказчик). Благодаря этому в ходе испытаний могут быть выявлены не только технические погрешности, но и концеп­туальные проблемы в предлагаемом продукте.

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

В качестве результатов испытаний большое значение имеют не только количе­ственные (объективные) данные о работе приложения в тех или иных ситуациях, но и «качественная» информация, отражающая субъективное восприятие пользовате­лем предлагаемого варианта приложения, его удовлетворенность, а также перечень проблем, которые на его взгляд могут иметь место при реальной эксплуатации про­граммного продукта.

ПОВТОРНОЕ ВЫПОЛНЕНИЕ ЭТАПОВ РАЗРАБОТКИ

Поскольку испытания часто обнаруживают те или иные слабости проекта, или, по крайней мере, обеспечивают получение дополнительной информации, которую вы за­хотите использовать, почти всегда оказывается необходимым возврат к одному из пре­дыдущих этапов разработки (а иногда и в начальную точку) и проведение повторных испытаний. Так может продолжаться до тех пор, пока и разработчик, и потенциальные пользователи не будут полностью удовлетворены полученными результатами.

ОЦЕНКА ПОТРЕБИТЕЛЬСКИХ СВОЙСТВ ПРИЛОЖЕНИЯ В ПРОЦЕССЕ РАЗРАБОТКИ

Как было указано выше, основная цель испытаний — определить, насколько пол­но разработанное приложение (в первую очередь, его интерфейс) отвечает потреб­ностям и ожиданиям пользователя. В связи с этим основным направлением испы­таний приложения является оценка его «потребительских свойств» (Usability). Такая оценка должна проводиться, начиная с самых ранних этапов разработки. Ос­новой для проведения оценки должны служить данные о том, как пользователи обычно выполняют ту работу, которую призвано автоматизировать создаваемое приложение. По мере того, как разработка продвигается, оценка потребительских свойств приложения должна постоянно уточняться. Чем чаще и корректнее будет проводиться оценка, тем выше будет качество разработки.

ТЕХНИКА ПРОВЕДЕНИЯ ИСПЫТАНИЙ ПОТРЕБИТЕЛЬСКИХ СВОЙСТВ ПРИЛОЖЕНИЯ

Проведение испытаний потребительских свойств приложения требует привле­чения значительных дополнительных сил и средств, в том числе специалистов тес­товых лабораторий, имеющих в своем распоряжении соответствующее оборудование для регистрации результатов испытаний. Тем не менее, даже обычные «офис­ные инструменты» (магнитофон, секундомер и записная книжка) могут принести существенную пользу. Используемые тесты не должны быть «всеохватывающими». Значительно более полезны быстрые итеративные тесты, ориентированные на ис­следование конкретных проблем; практика показывает, что при таком подходе 6-10 участников испытаний могут идентифицировать 80 — 90 процентов основных про­блем разработки.

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

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

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

АЛЬТЕРНАТИВНЫЙ ПОДХОД К ПРОВЕДЕНИЮ ИСПЫТАНИЙ ПРИЛОЖЕНИЯ

Наряду с рассмотренным выше подходом, ряд проблем, возникающих в процессе создания программного продукта, может быть решен на основе методики «коллек­тивной генерации идей» Как правило, для ее реализации формируется специальная группа из числа разработчиков (focus group — группа концентрации). Она бывает особенно полезна для генерации начальных идей или для предварительной оценки идей, возникающих в процессе разработки. Для работы такой группы требуется пред­седатель, который направлял бы дискуссию об аспектах выполнения того или иного шага разработки, позволяя вместе с тем участникам свободно выражать их мнения.

Рекомендуем посмотреть лекцию "3 - Понятие о минералах".

Можно также использовать технику «сквозного контроля» (walkthroughs), при которой вы «проводите» пользователя по определенному, заранее продуманному сценарию работы с приложением и запрашиваете его впечатления по мере продви­жения к конечной цели.

На разработку продукта оказывают влияние многие дополнительные факторы. Например, маркетинговые соображения могут потребовать сокращения сроков раз­работки, или сравнительные оценки с аналогичными продуктами могут заставить реализовать в создаваемом ПО дополнительные характеристики. При этом следует помнить, что сокращение сроков и внесение дополнительных функциональных воз­можностей могут повлиять на качество продукта. Нет простого уравнения, позво­ляющего определить, каким образом вносимые изменения повлияют на первона­чальный проект приложения. Однако важную роль в такой оценке могут сыграть следующие соображения:

• Каждая дополнительная характеристика потенциально влияет на поведение, сложность, устойчивость, эксплуатацию и издержки по сопровождению создаваемого ПО.

• После выхода в свет официальной версии продукта труднее устранить пробле­мы, оставшиеся нерешенными на стадии разработки, поскольку пользователи могут приспособиться, или даже «подчиниться» имеющимся недостаткам вашего ПО.

• Простота пользовательского интерфейса — это далеко не то же самое, что его упрощенчество. Чтобы сделать нечто простым в использовании, часто требуется приложить много сил и создать весьма сложное изделие с точки зрения его внут­ренней организации.

• Доработки программного кода с целью расширения функциональных воз­можностей ПО совсем не обязательно будут иметь пропорциональный положи­тельный эффект сточки зрения интерфейса пользователя. Например, если основ­ная задача пользователя состоит в выборе единственного объекта, то предоставляя ему возможность одновременного выбора нескольких объектов, вы только ус­ложняете ему работу.