Ис. Конспект лекций Маглинец Ю. А. Красноярск сфу 2007 Введение. Понятие и классификация требований
 Скачать 0.88 Mb.
|
|
Прототипирование Прототипирование – ключевая стратегия выявления требований в большинстве современных методологий (подробнее см. в лекции 5 ). Программный прототип – «зеркало», в котором видно отражение того, как понял Исполнитель требования Заказчика. Процесс выявления требований путём прототипирования тем более интенсивен, чем это зеркало кривее. Документальный способ выявления требований всегда уступает живому общению. Анализ того, что сделано в виде интерфейсов пользователя даёт ещё больший эффект. Подключается правополушарный канал восприятия, который, как известно, работает у большинства людей на порядок эффективнее, чем вербальный. Метод RAD – один из наиболее известных способов быстро создавать прототипы 10 RAD базируется на следующих базовых принципах: Эволюционное прототипирование; CASE-средства, как основной инструмент, включая возможности прямого и обратного проектирования и автоматической генерации кода; Высококвалифицированные специалисты, хорошо владеющие развитыми инструментальными средствами; Интерактивный JAD-метод, в котором общение совмещается с разработкой в режиме online; Жёсткие временные рамки, как противоядие от «расползания границ» проекта: если команда не укладывается в срок – функционал сужается. Литература к лекции 1. Унифицированный процесс разработки программного обеспечения/ А. Якобсон, Г. Буч, Дж. Рамбо – СПб.: Питер , 2002. – 496 с. 2. Искусственный интеллект: в 3 книгах, кн. 2. Модели и методы / Справочник под ред. Э.В.Попова. - М.: Радио и связь. - 1990. 3. Марка Д.А. Методология структурного анализа и проектирования. – С.- Пб.: Питер, 1995. – 235 с. 4. Коберн А. Быстрая разработка программного обеспечения. – М.: Лори, 2002. 314 с. 5. Каменова, Громов. Моделирование бизнеса. Методология ARIS. — М.: Весть-МетаТехнология, 2001. 6. Марка Д.А. Методология структурного анализа и проектирования. – С.- Пб.: Питер, 1995. – 235 с. 7. Мацяшек Лешек, А. Анализ требований и проектирование систем. Разработка информационных систем с использованием UML.: Пер. с англ. - М.: Издательский дом "Вильямс", 2002. - 432 с.: ил. - Парал. тит. Англ. 8. Орлик С., Булуй Ю. Введение в программную инженерию и управление жизненным циклом ПО Программная инженерия. Программные требования. Copyright © Сергей Орлик, 2004-2005. http://www.sorlik.ru/swebok/3-1-software_engineering_requirements.pdf 9. Вигерс Карл Разработка требований к программному обеспечению/Пер, с англ. — М.:Издательско-торговый дом «Русская Редакция», 2004. — 576с.: ил. 10 Хотя задачи RAD на этом не ограничиваются 4. Формирование видения. Специфицирование требований План лекции Видение продукта и границы проекта Концепция в ГОСТ РФ Видение в RUP Видение / рамки в MSF Видение продукта и границы проекта Акторы и варианты использования Глоссарий Спецификация варианта использования Свободный формат Шаблон полного описания варианта использования по А. Коберну Табличные представления варианта использования Шаблон варианта использования RUP Выбор формы описания варианта использования Спецификация нефункциональных требований Атрибуты требований Работы по формированию видения продукта и границ проекта обычно начинаются на самой ранней фазе проекта, до начала широкомасштабных консультаций по выявлению подробных требований, хотя в целом наличие и последовательность данных шагов зависит от выбранной методологии. На практике данные работы зачастую совмещаются. Правила извлечения требований, рассмотренные в лекции 3 , могут быть использованы и при формировании видения. Анализируя литературу по рассматриваемой тематике, можно выделить следующие широко употребимые ключевые слова: с одной стороны – концепция, видение, образ, с другой – рамки, границы, контекст. В первом случае речь идёт о видении того, какой должна быть система. Обсуждаются высокоуровневые требования (возможности, свойства) продукта и наиболее существенные ограничения. Ряд авторов, напротив, настаивает на том, что видение должно быть «ничем не ограниченным». Понятие видения широко употребимо в бизнес-анализе. Если у топ-менежмента компании имеется представление о том, какие ключевые цели, сегменты рынка, товарные позиции, прибыль должны быть достигнуты, допустим, через 5 лет – значит, компания имеет долгосрочное видение себя на рынке. Способ снятия ограничений при выработке видения позволяет выработать новый взгляд на вещи, «подняться над ситуацией», планировать будущее, отталкиваясь не от текущих ресурсов и ограничений, а от стратегических целей, применяя инновации, ноу-хау и т.п. Данный опыт формирования видения во многом переносим и на процесс разработки информационных систем: нужно «увидеть» в горизонте средне- и (или) долгосрочного планирования, как АИС впишется в организационные процессы предприятия, какие ключевые выгоды она даст, какие проблемы позволит разрешить. При поиске новых методов и средств управления предприятием на основе информационных технологий зачастую приходится «перекраивать» существующие бизнес-процессы; по сути внедрение АИС, затрагивающей существенный процент процессов предприятия, неизбежно приводит к перестройке этих процессов с целью оптимизации деятельности предприятия, достижения ключевых факторов эффективности и пр. Во втором случае (рамки, границы, контекст) обсуждаются такие вопросы, как граница системы и среды, требуемые ресурсы на создание системы, сроки. Построив «ничем не ограниченное видение», рано или поздно приходится вернуться к таким прозаическим вещам, как бюджет, календарное планирование, подбор персонала, вехи проекта. Всегда ли нужно создавать документ «Концепция»? Следует ли разделять видение и границы? Зачастую Заказчик осознаёт необходимость автоматизации, как способ решения накопившихся проблем. Сформулировав для себя проблему, Заказчик часто видит и вариант её решения, с которым приходит к Исполнителю («мне нужен сайт», «требуется CRM-система» и т.п.). Квалифицированный Исполнитель не должен, сломя голову, спешить решать задачу в формулировке Заказчика. По образному выражению Г.Калянова 11 автоматизировать процессы «как есть» – всё равно, что асфальтировать дорожки, по которым ходят коровы. В нотации RUP присутствует важная метафора: «Увидеть проблему за проблемой». Концепция как раз и служит для того, чтобы помочь Заказчику выявить именно те требования к системе, которые помогут ему оптимизировать работу своего предприятия в долгосрочной перспективе. Поэтому этап формирования концепции важен, но он предъявляет и к Заказчику и к Исполнителю достаточно высокие требования: Заказчик должен выделить ресурсы и быть готовым к трудозатратам на совместный поиск решений; Исполнитель должен обладать достаточной квалификацией как в сфере IT-, так и в сфере управления предприятиями, чтобы разрабатываемое средство автоматизации действительно принесло пользу. Всё вышесказанное ничуть не исключает возможность работы без концепции: либо речь идёт о небольшом проекте, закладывать в бюджет которого этап выработки концепции просто нерентабельно, либо Заказчик сам обладает достаточной квалификацией, чтобы сформулировать требования к АИС, имея «концепцию в голове» и время для консультирования Разработчика. Некоторые аргументы за разделение видения и границ были приведены выше. Провести чёткую границу между этими понятиями предлагает, в частности, процесс MSF. В конечном итоге, вопрос «разделять или не разделять» определяется выбранной методологией. Рассмотрим основные требования к выработке концепции, заложенные в отечественных ГОСТ, методологиях RUP и MSF. Концепция в ГОСТ РФ В соответствии с ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания» [24], после этапа формирования (выявления) требований к системе выполняется этап разработки концепции системы. Основные работы этапа: Изучение объекта; Проведение научно-исследовательских работ (НИР); Разработка вариантов концепции АС; Оформление отчёта о выполненной работе. Так как данный этап хронологически стоит на втором месте, к его началу у Разработчика на руках уже имеется документ, в котором собраны основные требования пользователей. Работы над концепцией начинаются с обследования объекта автоматизации. Выполняются НИР, направленные на исследование принципиальной реализуемости требований и возможных вариантов реализации. 1. 11 Калянов Г. Н. Консалтинг при автоматизации предприятий: Научно-практическое издание. Серия «Информатизация России на пороге XXI века». — М.: СИН-ТЕГ, 1997. ГОСТ, в отличие от большинства современных методологий, в общем случае закладывает многоальтернативность вариантов концепции системы и планов их реализации. Каждый из проработанных вариантов оценивается с позиций требуемых ресурсов и функциональности. Для вариантов должны быть представлены оценки преимуществ и недостатков. Полезность проработки нескольких вариантов концепции заключается в том, что Заказчику трудно сформулировать самостоятельно видение системы, в то время, как выбор из набора вариантов, представленных Разработчиком – вполне посильная задача. Кроме того, концепция должна отражать оценки качества, условия приёмки системы, оценку эффекта, ожидаемого от реализации. При оформлении отчёта необходимо привести обоснование предлагаемого варианта. Видение в RUP Шаги, которые необходимо пройти для формирования документа «Видение»: Формулировка проблем. Идентификация совладельцев Определение границ системы Идентификация ограничений Формулировка постановки задач Определение возможностей системы Оценка результатов Для описания проблем предлагается шаблон, показанный в табл. 7-1. Табл. 7-1. Проблема (описание проблемы) Затрагивает (совладельцы, затрагиваемые проблемой). Ее следствием является (каково влияние проблемы). Успешное решение (список некоторых ключевых преимуществ от успешного решения). Идентификация совладельцев предполагает поиск и фиксацию интересантов проекта – представителей Заказчика и Исполнителя, инвесторов, внешних экспертов и пр. Определение границ системы представляет собой нетривиальный процесс. Для этого используют контекстные диаграммы [23] (см. материалы 09-Моделирование требований ). RUP в поиске границ предлагает отталкиваться от акторов и вариантов использования. Среди источников ограничений обычно выделяют: Политические, Экономические, Среды, Технические, Выполнения, Системные. Описание возможностей системы представляет собой формулировку высокоуровневых требований. Шаблон документа «Vision» RUP содержит следующие основные разделы: 1. Введение 2. Позиционирование 3. Описания совладельцев и пользователей 4. Краткий обзор изделия 5. Возможности продукта 6. Ограничения 7. Показатели качества 8. Старшинство и приоритеты 9. Другие требования к изделию 10. Требования к документации 11. Приложение. Во введении описываются цель документа, его контекст (связь и взаимовлияние с различными проектами), определения, акронимы и сокращения, ссылки на другие документы, краткое содержание. В разделе «позиционирование» помещается определение решаемой проблемы (проблем), указывается целевой заказчик и исследуются деловые преимущества изделия перед аналогичными на рынке. В описании совладельцев и пользователей, помимо собственно описания этих двух групп, исследуется демография рынка: целевые рыночные сегменты; размер и темпы роста рынка; существующие конкурентные предложения на рынке; репутация Разработчика на рынке; Краткий обзор изделий содержит резюме изделия, описание его перспектив и ключевых возможностей, предположения и зависимости, указывается стоимость и её калькуляция, рассматриваются вопросы лицензирования и инсталляции. В разделе, посвящённом возможностям продукта, они описываются более подробно, каждая – в отдельном параграфе. В раздел «Ограничения» следует выносить существующие технические, технологические и др. обстоятельства, которые необходимо учитывать на данной стадии. Раздел «Показатели качества» содержит описание наиболее существенных нефункциональных требований к системе (эффективности, надёжности, отказоустойчивости и др.). Раздел «Старшинство и приоритеты» ранжирует сформулированные ранее требования и возможности системы по степени важности, очерёдности реализации и т.п. Раздел «Другие требования к изделию» описывает применяемые стандарты, системные требования, эксплуатационные требования, требования к окружающей среде. В требованиях к документации приводятся ключевые характеристики руководства пользователя, интерактивной справки, руководства по установке и конфигурированию, файла Read Me. В приложение выносятся атрибуты возможностей. RUP рекомендует следующий набор атрибутов: статус, выгода, объём работ, риск, стабильность, целевой выпуск, назначение, причина. Видение / рамки в MSF Согласно белой книге MSF [25], на фазе выработки концепции (envisioning phase) закладывается одна из фундаментальных основ успеха проекта – создание и сплочение проектной группы на основе выработки единого видения. Проектная группа должна четко представить себе, что она хочет сделать для заказчика и сформулировать свою цель таким образом, чтобы максимально мотивировать как заказчика, так и саму проектную команду. Выработка высокоуровневого взгляда на цели и условия проекта может рассматриваться как ранняя форма планирования; она подготавливает почву для процессов создания детальных планов, которые будут осуществлены непосредственно во время фазы планирования. Основными задачами фазы выработки концепции являются создание ядра проектной группы (см. ниже) и подготовка документа общего описания и рамок проекта (vision/scope document). Формирование видения проекта и специфицирование его рамок – не одно и тоже, хотя для успеха проекта необходимо и то, и другое. Видение (vision) – это ничем не ограничиваемое представление о том, каким должно быть решение 12 . Рамки (scope) же дают четкие границы того, что из предложенного этим видением будет реализовано в условиях существующих проектных ограничений. Управление рисками представляет собой итеративный процесс, осуществляемый на протяжении всего жизненного цикла проекта. Во время фазы выработки концепции проектная группа готовит документ оценки рисков и представляет главные риски проекта вместе с общим описанием и рамками проекта. Для получения дальнейшей информации об управлении рисками, см. “Белую книгу” дисциплины управления рисками MSF. Также во время фазы выработки концепции производится выявление и анализ бизнес-требований. Более детально эти требования рассматриваются во время фазы планирования. Ведущим ролевым кластером на фазе выработки концепции является “Управление продуктом”. Шаблон MSF содержит следующие разделы: Бизнес-преимущества, o Описание преимуществ o Формулировка видения o Анализ выгод Концепция решения o Цели, задачи, предположения и ограничения o Анализ применимости o Требования Рамки o Список характеристик/функций o Вне рамок o Стратегия подготовки релизов o Критерии применимости o Эксплуатационные критерии Стратегии проектирования решения o Стратегия проектирования архитектуры o Стратегия технического проектирования Акторы и варианты использования Результатом выявления требований, см. материалы лекции 3 является реестр требований. Требования совладельцев обычно оформляются в простой письменной форме, без какой-либо особой регламентации. Типовой пример оформления требования к программе электронной почты – «Система должна позволять набирать текст сообщения с возможностью форматирования текста и вставки смайликов». Данные требования далеко не во всём могут удовлетворять критериям, сформулированным в лекции 2 : они могут противоречить друг другу, быть неясными, неточными и т.д. Тем не менее, документ «Требования совладельцев», несмотря на невысокий уровень формализации, играет очень важную роль: в нём собраны мнения всех заинтересованных сторон и главная цель сбора начальных требований заключалась в том, чтобы получить по возможности как можно более полный набор требований, не пропустив чего-то важного. Для того, чтобы повысить уровень информативности требований, устранить взаимные противоречия и добиться выполнения их других основных характеристик, осуществляется переход от полностью неформализованных текстов к частично регламентированным (например, шаблонами MS Word) текстам, классификация, присвоение наборов атрибутов, построение моделей, прототипирование. Самым популярным и весьма эффективным способом повышения информативности требований является оформление их в виде вариантов использования (use case), предложенный И.Якобсоном (см., например, [26]). Прежде, чем приступить собственно к специфицированию требований в форме вариантов использования, RUP рекомендует выявить реестр акторов 13 (actors) и вариантов использования. Актор – это некто или нечто, обладающее активностью по отношению к программной системе. Если вы разрабатываете простой текстовый редактор, то, скорее всего, выбор актора не составит особого труда: это будет пользователь, набирающий текст. Однако не всегда всё так просто. Помимо пользователя в качестве актора может рассматриваться другая программная система, аппаратное устройство, в ряде случаев – активная компонента самой системы. Поиск акторов корпоративной информационной системы обычно сводится к анализу ролей различных пользователей. Менеджер по продажам, старший менеджер и начальник отдела продаж – один актор, два или три? Это зависит от их функциональных обязанностей, разграничения доступа, способов использования информационной системы. Поиск акторов может осуществляться, например методом мозгового штурма. В дальнейшем при необходимости найденные акторы могут обобщаться, пересматриваться и объединяться. Вариант использования в первом приближении можно рассматривать, просто, как функцию, реализуемую системой. Однако, современный взгляд на организацию бизнеса говорит о том, что всякая функция должна иметь ценность для конечного потребителя продукта или услуги. Философия варианта использования предполагает выделение среди всего функционала системы подмножества, полезного конкретному конечному пользователю (точнее говоря, типу конечного пользователя). Другая сторона – вариант использования должен не только быть полезен, а ещё и позволять получать КП конкретные законченные результаты. Так, одной из функций текстового редактора, очевидно, является создание пустого файла. Но вряд ли КП будет использовать редактор с целью изготовления пустых файлов. Следовательно, создание пустого файла – функция, но не вариант использования системы. Вариантом использования может быть, например, подготовка в текстовом редакторе служебной записки. Вариант использования реализуется через функции системы. |