А. А. Платонов, доцент кафедры прикладной математики и вычислительной техники Волгоградского государственного архитектурностроительного университета
 Скачать 3.99 Mb.
|
|
2.3. Итеративная и инкрементальная модель — эволюционный подход Итеративная модель предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает «мини-проект», включая все фазы жизненного цикла в применении к созданию меньших фраг- ментов функциональности (по сравнению с проектом в целом). Цель каждой итерации — получение работающей версии программной системы, включающей функциональность, определенную интегрированным содержанием всех предыдущих и текущей итерации. Результата финальной итерации содержит всю требуемую функциональность продукта. Таким об- разом, с завершением каждой итерации, продукт развивается инкремен- тально. С точки зрения структуры жизненного цикла такую модель называют итеративной (iterative). С точки зрения развития продукта — инкремен- тальной (incremental). Опыт индустрии показывает, что невозможно рас- сматривать каждый из этих взглядов изолировано. Чаще всего такую сме- шанную эволюционную модель называют просто итеративной (говоря о про- цессе) и/или инкрементальной (говоря о наращивании функциональности продукта). Эволюционная модель подразумевает не только сборку работающей (с точки зрения результатов тестирования) версии системы, но и ее разверты- вание в реальных операционных условиях с анализом откликов пользователей для определения содержания и планирования следующей итерации. «Чистая» инкрементальная модель не предполагает развертывания промежуточных сборок (релизов) системы и все итерации проводятся по заранее определен- ному плану наращивания функциональности, а пользователи (заказчик) полу- чает только результат финальной итерации как полную версию системы. Таким образом, значимость эволюционного подхода на основе организа- ции итераций особо проявляется в снижении неопределенности с заверше- нием каждой итерации. В свою очередь, снижение неопределенности позво- ляет уменьшить риски. Рис. 3 иллюстрирует некоторые идеи эволюционного подхода, предполагая, что итеративному разбиению может быть подвержен не только жизненный цикл в целом, включающий перекрывающиеся фазы — формирование требований, проектирование, конструирование и т. п., но и каждая фаза может, в свою очередь, разбиваться на уточняющие итерации, связанные, например, с детализацией структуры декомпозиции проекта — например, архитектуры модулей системы. 11 Рис. 3. Снижение неопределенности и инкрементальное расширение функциональности при итеративной организации жизненного цикла 2.4. Спиральная модель Наиболее известным и распространенным вариантом эволюционной мо- дели является спиральная модель, ставшая уже фактически самостоятельной моделью, имеющей различные сценарии развития и детализации. Спиральная модель (рис. 4) была впервые сформулирована Барри Боэмом в 1988 г. Отличительной особенностью этой модели является специальное внимание рискам, влияющим на организацию жизненного цикла. Главное достижение спиральной модели состоит в том, что она предлага- ет спектр возможностей адаптации удачных аспектов существующих моде- лей процессов жизненного цикла. Спиральная модель обладает рядом преимуществ: 1. Уделяет специальное внимание раннему анализу возможностей по- вторного использования. Это обеспечивается, в первую очередь, в процессе идентификации и оценки альтернатив. 2. Предполагает возможность эволюции жизненного цикла, развитие и изменение программного продукта. Главные источники изменений заклю- чены в целях, для достижения которых создается продукт. Подход, преду- сматривающий скрытие информации о деталях на определенном уровне ди- зайна, позволяет рассматривать различные архитектурные альтернативы так, как если бы мы говорили о единственном проектном решении, что уменьша- ет риск невозможности согласования функционала продукта и изменяющих- ся целей (требований). 12 3. Предоставляет механизмы достижения необходимых параметров ка- чества как составную часть процесса разработки программного продукта. Эти механизмы строятся на основе идентификации всех типов целей (требо- ваний) и ограничений на всех циклах спирали разработки. Например, огра- ничения по безопасности могут рассматриваться как риски на этапе специ- фицирования требований. 4. Уделяет специальное внимание предотвращению ошибок и отбрасы- ванию ненужных, необоснованных или неудовлетворительных альтернатив на ранних этапах проекта. Это достигается явно определенными работами по анализу рисков, проверкой различных характеристик создаваемого про- дукта (включая архитектуру, соответствие требованиям и т. п.) и подтвер- ждением возможности двигаться дальше на каждом цикле процесса разра- ботки. 5. Позволяет контролировать источники проектных работ и соответ- ствующих затрат. По сути, речь идет об ответе на вопрос — как много уси- лий необходимо затратить на анализ требований, планирование, конфигура- ционное управление, обеспечение качества, тестирование, формальную ве- рификацию и т. д.? Модель, ориентированная на риски, позволяет в контексте конкретного проекта решить задачу приложения адекватного уровня усилий, определяемого уровнем рисков, связанных с недостаточным выполнением тех или иных работ. 6. Не проводит различий между разработкой нового продукта и расши- рением (или сопровождением) существующего. Этот аспект позволяет избе- жать часто встречающегося отношения к поддержке и сопровождению как ко второсортной деятельности. Такой подход предупреждает большое коли- чество проблем, возникающих в результате одинакового уделения внимания как обычному сопровождению, так и принципиально важным вопросам рас- ширения функциональности продукта, всегда связанным с повышенными рисками. 7. Позволяет решать интегрированные задачи системной разработки, охватывающие и программную, и аппаратную составляющие создаваемого продукта. Подход, основанный на управлении рисками и возможности свое- временного отбрасывания непривлекательных альтернатив (на ранних ста- диях проекта), сокращает расходы, и одинаково применим и к аппаратной части, и к программному обеспечению. Так как взглядов на детализацию описания жизненного цикла может быть много, то существуют различные методики, среди которых наибольшее распространение получили: Rational Unified Process (RUP); Enterprise Unified Process (EUP); Microsoft Solutions Framework (MSF) в обоих представлениях: MSF for Agile и MSF for CMMI (анонсированная изначально как MSF Formal); Agile-практики (eXtreme Programming (XP), Feature Driven Development (FDD), Dynamic Systems Development Method (DSDM), SCRUM и др.). 13 Рис. 4. Оригинальная спиральная модель жизненного цикла разработки по Боэму Контрольные вопросы 1. Назовите основные модели жизненного цикла разработки программного обеспече- ния информационной системы. 2. Дайте характеристику каскадной модели. 3. Дайте характеристику эволюционной модели. 4. Дайте характеристику спиральной модели. 5. Назовите основные методики разработки, детализирующие описание жизненного цикла. 14 3. ЦЕЛЕОРИЕНТИРОВАННОЕ ПРОЕКТИРОВАНИЕ И ЕГО ИНТЕГРАЦИЯ В ЖИЗНЕННЫЙ ЦИКЛ РАЗРАБОТКИ ПРОДУКТА 3.1. Ошибки проектирования Во втором издании своей книги «Алан Купер об интерфейсе. Основы проектирования взаимодействия» Алан Купер сотоварищи так описывают главную проблему, возникающую при создании систем программного обес- печения: «В большинстве своем цифровые продукты возникают в процессе разработки — как монстр из булькающей протоплазмы в резервуаре. Разра- ботчики, вместо того чтобы планировать и действовать исходя из нужд тех пользователей, которые приобретут и будут использовать созданные продук- ты, сплошь и рядом сосредотачиваются на технологии и в результате порож- дают решения, слабоуправляемые и неудобные в применении. Словно бе- зумные ученые они терпят поражение, потому что не наделяют свои созда- ния человечностью… Так в чем же реальная проблема? Почему индустрия технологий оказы- вается в целом недееспособной, когда требуется продумать интерактивную составляющую цифровых продуктов? Тому есть три основных причины: от- сутствие представления о пользователях, конфликт между потребностями людей и приоритетами разработки, а также отсутствие процесса, позволяю- щего понимать потребности человека и помогающего в разработке удобной формы и качественного поведения продукта» [4]. Сложившаяся практика проектирования такова, что мы получаем четкое представление о бизнес-процессах предприятия, для которого создается про- граммное обеспечение. Соответственно, мы имеем смутное представление о работе, которую делают будущие пользователи системы, и некоторых ос- новных часто выполняемых задачах, но практически не получаем сведений о том, как они в действительности будут применять продукт, который мы создаем, почему они занимаются той деятельностью, в которой им может помочь наш продукт, почему они могут отдать предпочтение именно наше- му продукту, а не продукту конкурента, и как нам добиться этого. 15 Продукты, при проектировании и создании которых преследовались только цели бизнеса, ожидает провал, так как личные цели пользователей требуют своей доли внимания. Учет личных целей пользователей при проек- тировании продукта позволяет гораздо более эффективно достигать целей бизнеса. Цели — не то же самое, что задачи или деятельность. Цель — это предвосхищение конечного состояния, тогда как задачи и деятельность яв- ляются лишь промежуточными этапами (на различных уровнях организа- ции), необходимыми для достижения целей. Программы, дающие пользователям возможность решать стоящие перед ними задачи, но не обращающие внимания на цели, редко позволяют выпол- нять работу действительно эффективно. Если перед пользователем постав- лена задача ввести в базу данных 5000 имен и адресов, самое идеальное при- ложение для ввода данных не даст ему ничего близко похожего на то удов- летворение, которое принесет инструмент, автоматически извлекающий имена из системы хранения счетов. Строя проектирование исключительно на основе анализа деятельности и задач, мы рискуем попасть в ловушку устаревших технологий или приме- нить модель, соответствующую целям корпорации, но не отвечающую целям пользователей. Взгляд через призму целей позволяет пользоваться преиму- ществами современной технологии для исключения лишних задач и ради- кального упорядочения структуры деятельности. Понимание целей пользо- вателя помогает проектировщикам избавляться от деятельности и задач, ко- торые технология способна выполнять за человека. Необходимо использовать такие методы проектирования, которые соче- тают: понимание желаний, потребностей, мотивации пользователей и контек- ста, в котором эти пользователи находятся; понимание возможностей, требований и ограничений бизнеса, техноло- гии и предметной области; использование этих знаний в качестве основы всех планов по созданию продуктов, форма, содержание и поведение которых делают их полезными, удобными и желанными, а также экономически жизнеспособными и техни- чески осуществимыми. Если проектирование осуществляется подходящими методами, оно спо- собно восстановить отсутствующую связь человека с технологическими продуктами. Очевидно, что большинство существующих подходов к проек- тированию цифровых продуктов не дают обещанного эффекта. Создание качественных продуктов требует исследований пользователь- ской аудитории, в то время как суть этих исследований для многих органи- заций по-прежнему остается загадкой. Проблема возникает непосредственно после анализа результатов: большинство традиционных подходов ничего не говорят о том, как преобразовать результаты исследований в проектные ре- шения. Сотню страниц с результатами анкетирования пользователей не так- то легко превратить в набор требований к продукту, а извлечь из них пони- 16 мание того, как эти требования должны быть выражены в терминах ясной и осмысленной инфраструктуры интерфейса, еще сложнее. Проектирование остается «черным ящиком»: «А вот здесь происходит чудо». Эта пропасть между результатами исследований и конечными проектными решениями есть порождение процесса, неспособного протянуть связи от запросов поль- зователя к тому, чем продукт становится в финале. Эта проблема преодоле- вается при помощи целеориентированного подхода. 3.2. Целеориентированное проектирование Одна из проблем существующего процесса разработки состоит в том, что роли участников чрезмерно узки: аналитики исследуют, а проектировщики проектируют. В этой модели не хватает системных средств для перевода и синтеза результатов исследований в интерфейсные решения. Один из спо- собов решения проблемы для проектировщиков — научиться быть исследо- вателями. Прямые и обширные контакты с пользователями, без которых не обхо- дится ни одно серьезное исследование, погружают проектировщиков в мир пользователей и заставляют думать о них задолго до того, как речь пойдет о выработке решений. Одна из наиболее опасных практик при создании про- дукта — изоляция проектировщиков от пользователей. Кроме того, обычно- му исследователю часто сложно понять, какая информация о пользователях существенна с точки зрения проектирования. Вовлечение проектировщиков в исследование снимает оба этих вопроса. Весьма немногие из распространенных методов проектирования включа- ют в себя средства эффективного и систематического преобразования знаний, собранных в ходе исследований, в детальную спецификацию интерфейса. Другая же причина состоит в том, что очень немногие подходы фикси- руют поведение пользователей в форме, пригодной для формирования опре- деления продукта. Вместо информации о целях пользователей, большинство методов описывают задачи. Информация такого типа хорошо подходит для создания компоновочных схем, моделирования рабочего процесса и преоб- разования функций в элементы пользовательского интерфейса, но далеко не столь полезна для определения общей инфраструктуры, отражающей то, чем продукт является, что он делает и как это соответствует различным потреб- ностям пользователей. Для преодоления разрыва нам требуется строгий систематический про- цесс создания моделей пользователей, определения требований к пользова- тельскому интерфейсу и преобразования их в общую концепцию взаимодей- ствия. Задача целеориентированного проектирования — устранить сущест- вующий в процессе разработки цифровых продуктов разрыв между исследованиями пользовательской аудитории и проектированием, эффек- тивно сочетая новые и уже известные подходы. 17 Целеориентированное проектирование позволяет создавать решения, со- ответствующие потребностям и целям пользователей с одной стороны, а также бизнес-требованиям и технологическим ограничениям — с другой. Процесс можно грубо разделить на шесть стадий: исследования, моделиро- вание, выработка требований, определение общей инфраструктуры, детали- зация и сопровождение (рис. 5). Рис. 5. Процесс целеориентированного проектирования Рассмотрим содержание каждого из этапов. 3.2.1. Исследования На стадии исследований для сбора качественных данных о существую- щих и/или потенциальных пользователях продукта применяются такие ме- тоды, как наблюдения за потенциальными пользователями системы и их ин- тервьюирование. Помимо этого, если того требует предметная область, мо- жет проводиться конкурентный анализ, обзор маркетинговых исследований, обзор статей о технологиях, а также индивидуальное интервьюирование лиц, принимающих решения, разработчиков, специалистов в предметной области и экспертов по технологии. Одним из основных результатов исследований и интервью с пользовате- лями является набор поведенческих шаблонов — характерных поведенче- ских моделей, помогающих классифицировать варианты использования бу- дущего или существующего продукта. Анализ этих поведенческих шаблонов позволяет определять цели и мотивы (частные и общие желаемые результа- ты применения продукта). В деловой и технической областях такие поведенческие шаблоны часто совпадают с бизнес-ролями пользователей; в случае потребительской про- дукции — соответствуют стилю жизни пользователей. Поведенческие моде- ли и связанные с ними цели пользователей являются основой персонажей, которые создаются на стадии моделирования. 18 Маркетинговые исследования помогают находить и проводить отбор пер- сонажей, укладывающихся в бизнес-модели. Интервью с лицами, принимаю- щими решения, обзоры литературы и аудит пользовательского интерфейса продуктов дают проектировщикам возможность глубже вникнуть в предмет- ную область и проливают свет на цели бизнеса, атрибуты бренда и техниче- ские ограничения, которые следует учесть при проектировании. В главе чет- вертой приводится более подробная информация о методах сбора требований. 3.2.2. Моделирование На стадии моделирования поведенческие шаблоны и шаблоны рабочих процессов, выявленные путем анализа результатов полевых исследований и интервью, собираются вместе в виде моделей предметной области и моде- лей пользователей. Модели предметной области могут включать информа- ционные потоки и диаграммы рабочих процессов. Пользовательские модели, или персонажи, — это подробные и структурированные архетипы пользова- телей, которые представляют собой различные устойчивые комбинации по- веденческих моделей, склонностей, взглядов, целей, мотивов, обнаруженных на стадии исследований. Персонажи становятся главными действующими лицами описательной методики проектирования, основанной на сценариях. На стадии определения инфраструктуры персонажи способствуют генерации концепций взаимодей- ствия, на стадии детализации — обеспечивают обратную связь, позволяющую улучшить внутреннюю согласованность дизайна и его соответствие целям, а также служат мощным инструментом коммуникации, помогающим разра- ботчикам и руководителям видеть, на чем основывается дизайн, и ранжиро- вать функции продукта, исходя из потребностей пользователей. На стадии моделирования проектировщики применяют разнообразные методологиче- ские инструменты для синтеза, дифференциации и ранжирования персонажей. Проектировщики выявляют различные типы целей и связывают типы возможных моделей поведения с персонажами таким образом, чтобы не ос- тавалось белых пятен и не возникало повторений. Конкретное направление проектирования выбирается путем сопоставле- ния целей персонажей и создания иерархии приоритетов, основанной на том, насколько широко цели того или иного персонажа покрывают цели других персонажей. Процесс присвоения персонажам типов определяет, насколько серьезное влияние каждый персонаж окажет на окончательную форму и по- ведение продукта. Подробнее моделирование персонажей описано в шестой главе. |