Ис. Конспект лекций Маглинец Ю. А. Красноярск сфу 2007 Введение. Понятие и классификация требований
 Скачать 0.88 Mb.
|
|
Литература к лекции 39. Калянов Г. Н. Консалтинг при автоматизации предприятий: Научно- практическое издание. Серия «Информатизация России на пороге XXI века». — М.: СИН-ТЕГ, 1997. 40. Леффингуелл Д., Уидриг Д. Принципы работы с требованиями к программному обеспечению. М.: ИД “Вильямс”, 2002. 41. Вигерс Карл Разработка требований к программному обеспечению/Пер, с англ. — М.:Издательско-торговый дом «Русская Редакция», 2004. —576с.: ил. 42. Руководство по применению стандарта ИСО 9001:2000 при разработке программного обеспечения/ Пер. с англ. А.Л. Раскина. – М.: РИА “Стандарты и качество”, 2002. – 104 с. – (“Дом качества”, вып. 9 (18)). 43. Коберн А. Быстрая разработка программного обеспечения. – М.: Лори, 2002. 314 с. 9. Требования в управлении проектом. Заключение План лекции От рамок проекта к экспресс-планированию Планирование проекта на основе требований, путь RUP Требования в гибких методологиях Артефакты для работы с требованиями в гибких методологиях Планирование версий и итераций Анализ требований и управление рисками Современные тенденции в развитии АИС и технологий их создания Покупное или заказное ПО - критерии выбора Стратегии выбора решения Анализ требований Анализ несоответствия Подход на основе лучших практик Процесс выбора решения Чтобы определить сметную стоимость и продолжительность работ по проекту автоматизации без грубых ошибок, необходимо выявить и проанализировать требования, а также сформировать архитектурную основу, крайне желательно создать прототипы. И это – как минимум. Иными словами, для того, чтобы создать АИС, сначала нужно проанализировать возможность создания. Такая постановка вопроса вполне логична и обоснована, это подтвердит любой Разработчик. Однако, она вызывает много вопросов, например: Где найти Заказчика, который согласится ждать 2-3 месяца, пока Разработчик составит для него коммерческое предложение? Кто оплатит работы по анализу требований? (очевидно, Заказчик) Как быть, если цена вопроса окажется непомерной и от проекта придётся отказаться – кто возместит Заказчику убытки на проведение исследований? Разумный Заказчик сможет найти выход из этого непростого положения, например: подыскав Разработчика, обладающего богатым опытом выполнения подобных проектов, который сможет дать требуемую оценку значительно быстрее (но риск ошибки при этом остаётся); взяв на себя риски возможного прекращения проекта на ранних стадиях, в случае, если выявится его несоответствие бюджетным ограничениям (в сложных рискованных проектах лучше потерять 5% или 10% от закладываемого бюджета, чем все 100%, как это было в «каскадных» схемах разработки) – путь прогнозирующих методологий разделив с Разработчикам ответственность за конечный продукт, приготовившись день за днём работать с ним рука об руку вплоть до появления результата – путь гибких (agile) методологий. От рамок проекта к экспресс-планированию Начальную, самую грубую оценку проекта можно сделать на основании документа «Видение». Так, шаблон Vision/Scope MSF содержит список ключевых характеристик/функций, критерии приемлемости и (что очень важно) перечень характеристик/функций, которые лежат «вне рамок» проекта. Параллельно с проработкой концепции, первая фаза MSF содержит работы по анализу рисков: выявляются и оцениваются главные риски проекта. Чтобы сделать первое приближение плана и сметы проекта на ранних этапах анализа, в [22] предлагается следующий подход: Выделить 25 – 99 функций, характеризующих систему (совместно, Заказчик и Разработчик); Установить приоритеты для каждой из функций (Заказчик); Оценить трудозатраты (Разработчик); Оценить риски (Разработчик, возможно привлечение Заказчика); Все оценки делаются по 3-балльной шкале (высокий, низкий, средний; критический, важный, полезный и т.п.) и сводятся в таблицу: № пп. Функция Приоритет Трудоёмкость Риск Затем, в процессе консультаций Заказчика и Разработчика на основе полученной информации определяется набор функций, который войдут в базовую версию проекта. Результаты планирования на концептуальном уровне, проделанные, например, на основе вышеуказанного шаблона, позволяют дать первую оценку размерам проекта. Такая оценка не отличается особой точностью, но при определённых условиях (опыт решения Разработчиком аналогичных задач; доверительные отношения между Заказчиком и Разработчиком) может служить отправной точкой для заключения контракта на всю систему. Планирование проекта на основе требований, путь RUP RUP поддерживает двухуровневую схему планирования работ над проектом, разделяя план проекта и план итерации. Исходя из базовой концепции планирования итерационных проектов, план проекта разбивается на фазы: Начало, Уточнение, Конструирование, Переход. Исходя из рекомендаций методологии по декомпозиции работ проекта в зависимости от степени сложности проекта и квалификации команды, в каждой фазе выделяется одна или более итераций. Назначаются даты главных вех (окончания фаз): целей жизненного цикла (конец фазы начала, рамки проекта и его бюджет); архитектуры жизненного цикла (конец фазы уточнения, законченная архитектура); начальной работоспособности (конец фазы конструирования, бета-версия продукта); выпуска изделия (конец фазы перехода и полного цикла разработки). Назначаются даты малых вех, приуроченные к окончанию итераций и их главные цели. Основные цели итераций – выпуск релизов, демонстрируемых, либо передаваемых Заказчику, однако не всякая итерация приводит к выпуску релиза. План проекта создаётся как можно раньше в начальной фазе и модифицируется по мере необходимости. Что это означает на практике: 1) укрупнённый план работ составляется «как можно раньше», например – через месяц после начала работ; 2) бюджет появляется лишь к окончанию первой фазы (а она, в зависимости от сложности проекта может длиться месяц, а может и полгода); 3) как план, так и бюджет проекта представляют собой лишь прогноз, который может корректироваться на протяжении работ над проектом; 4) на момент появления плана и бюджета должно появиться подробное описание лишь 20% ключевой функциональности системы и «широкое, но неглубокое» [2] описание 80% функциональности. Таким образом, концепция укрупнённого планирования в RUP, как типопредставителе класса прогнозирующих методологий, предполагает базировать отношения между Заказчиком и Разработчиком на прогнозах, степень достоверности которых зависит от таких факторов, как качество проработки требований, квалификация команды Разработчика, сложность и новизна проекта. Более конкретная информация представлена в плане итерации. Основные его особенности: 1) План итерации базируется на функциональных требованиях. К моменту начала итерации совершенно точно известно, какие требования должны быть обработаны (детализированы, спроектированы, запрограммированы) в данной итерации. План итерации составляется, исходя из сформулированных выше оценок требований – приоритетности, степени риска, трудоёмкости. 2) План итерации имеет жёсткие сроки. В случае проявления незапланированных рисков удовлетворительным вариантом является достижение договорённости о реализации требований данной итерации не в полном объёме, либо переносе требований в следующую итерацию; переносить сроки текущей итерации не рекомендуется; 3) Точный план составляется на одну, очередную итерацию. К моменту окончания текущей итерации должен быть свёрстан план очередной итерации. Такой подход позволяет более гибко работать с рисками. Таким образом, следует отметить, что требования являются решающим фактором в планировании итерационного проекта. Требования в гибких методологиях В противовес прогнозирующим методологиям создания программного обеспечения, относительно недавно сформировалась парадигма гибких (agile) методологий. В феврале 2001 г. инициативная группа из 17 специалистов объединилась в Альянс гибкой разработки программного обеспечения. Эта группа разработала и приняла Манифест гибкой разработки: Индивидуальности и взаимодействия ВЫШЕ процессов и инструментов Работающее программное обеспечение ВЫШЕ всесторонней документации Сотрудничество с клиентами ВЫШЕ переговоров по контракту Реакция на изменения ВЫШЕ следования плану и 12 приложений (в столь же лаконичной форме) к нему 29 В определённой степени в противовес всему тому, что было сказано в предыдущих лекциях, члены Альянса ставят под сомнение необходимость всестороннего моделирования и документирования требований и даже посягают на святое святых – планы и контракты. На сегодня «быть гибким» стало модным. Апологеты методологий, заклеймённых членами Альянса, как «прогнозирующие» и даже «тяжеловесные» вступают в дискуссии – можно ли считать адаптировать ту или иную методологию на «гибкие рельсы». Так, опубликованы как минимум два варианта гибкой трансформации для RUP; MSF опубликовало нотацию agile MSF. Артефакты для работы с требованиями в гибких методологиях С позиций работы с требованиями основными средствами, которыми оперируют гибкие методологии, являются карты представления системы, истории пользователей, приёмочные тесты и CRC-карты [3-4]. Карта представления в определённой степени заменяет документ «концепция», принятый в прогнозирующих методологиях. В отличие от концепции, представление – это 29 www.agilealliance.org текст размером в 20-30 слов, умещающийся на небольшой (размером с визитную) карточке. Истории пользователей (user story)очень сильно напоминают краткие описания вариантов использования. Особенности историй пользователя – в том, что они, во-первых, должны быть действительно краткими (также умещаться на карточке), во-вторых – в том, что это – действительно истории пользователей, т.е. рассказы о том, как они планируют использовать систему. Использование историй пользователя исключает ситуацию, когда аналитик что-то придумал (домыслил) за пользователя – отнюдь, эти артефакты создают сами пользователи. Истории пользователя должны иметь осмысленные наименования и номера. Истории пользователя, помимо базового функционала, могут содержать декорации, очень напоминающие ориентиры RUP (см. лекции 5 ). Приёмочные тесты обычно пишут на обратной стороне карты с соответствующей историей пользователя. Шаблон, используемый в методологии XP, содержит 3 предложения: Установка (контекст; инициирующее событие), Операция (функция с количественными характеристиками), Подтверждение (результаты исполнения функции). CRC-карты (Класс-Ответсвенность-Кооперация), как и предыдущие 3 артефакта, представляют собой небольшие карточки, в заголовке которых представлено название класса, а ниже – таблица в две колонки. В левой колонке перечислены ответственности (т.е. высокоуровневый взгляд на его методы) класса, в правой – классы, состоящие в кооперации с рассматриваемым классом. Планирование на основе требований на примере XP Планирование включает следующие работы: оценивание, планирование версий и итераций. Оценивание представляет собой определение объёма работ в разрезе историй пользователя. Каждая история оценивается в пунктах. Один пункт равен «идеальной» (сорокачасовой) неделе, целиком посвящённой программированию. Если оценка лежит в пределах от 1 до 3 пунктов – то он ставится на карточке истории. Если оценка менее 1 – на карточке ставится 0. Это – так называемый «песок». Если оценка превышает 3 пункта – мы имеем дело с «эпопеей». В этом случае карточка помечается, как «split» и подлежит процедуре разделения. Другая стратегия работы с такой карточкой –попытаться вместить её в оптимальный срок путём исключения декораций. В случае, если история пользователя сложна для экспресс-оценки – необходимо провести исследование или «гвоздь» планирования. Планирование версий и итераций. Планирование в XP базируется на следующих основных понятиях: производительность, приоритеты, стоимость версии, составление плана версий, составление плана итераций. Производительность или быстродействие команды базируется на оценках пунктов истории. Однако необходимо учитывать, что пункты представляют идеальные оценки, кроме того существенную роль имеет опыт команды в оценивании (для начинающих команд возможна значительная погрешность). Ключевую роль в назначении приоритетов играет, безусловно, заказчик. Однако и Разработчик имеет право голоса при отборе историй, которые должны попасть в версию (вопросы архитектуры, ключевой функциональности и т.п.). Стоимость версии определяется, базируясь на производительности, приоритетах и сроках. План версий даёт Заказчику начальное понимание стоимости проекта. Эта оценка даёт ему возможность отказаться от проекта в начальной его стадии, если сроки и (или) цена являются неприемлемыми. В случае, если план версий принят – составляется план итераций, отражающий шаги (итерации), которые необходимо проделать, чтобы добиться требуемой функциональности продукта. Анализ требований и управление рисками Риск в реализации программных проектов – это потенциальная проблема, которая имеет существенную вероятность отрицательно повлиять на успешность проекта, например – на сдачу его в срок, удовлетворение бюджетных ограничений, качество продукта, эффективность работы команды. Управление риском – комплекс мероприятий по выявлению, оценке, предотвращению и контролю рисков проекта. Как пишет К.Вигерс [8], «Если что-либо нехорошее уже произошло с вашим проектом, то это – проблема, а не риск… Управление риском означает работу потенциальной опасностью до того, как она перейдет в кризисную фазу». Менеджеры проектов должны выявлять риск и управлять им, начиная с факторов, связанных с требованиями, в сотрудничестве с представителями Заказчика. Стратегии и работы по управлению риском Управление риском включает в себя действия, показанные на рис. 15-1 [8]. Управление риском Оценка Предотвращение или передача Контроль Определение Анализ Разрешение Назначение приоритетов Мониторинг Планирование управления Рис. 15-1 Работы по оцениванию риска (risk assessment) начинаются с определения потенциальных опасностей для проекта. В качестве методики выявления может быть рекомендована методика мозгового штурма. Хорошим подспорьем для этого этапа работ является имеющаяся у Разработчика классификация рисков. Так, все риски принято для делить на прямые (те, на которые Разработчик может так или иначе влиять) и косвенные (независимые от Разработчика) [15]. М. Фаулер [7] предложил разделить все риски на четыре категории: риски, связанные с требованиями, технологические риски, риски, связанные с квалификацией персонала, политические риски. Распространенные факторы риска, связанные с требованиями, включают неверное понимание требований, недостаточное вовлечение пользователей, неточности или изменения в масштабах и целях проекта, постоянно нестабильные требования. Подробный анализ этих видов рисков можно найти в [8], глава 23. Анализ риска сводится к исследованию и описанию потенциальных последствий конкретных факторов риска для проекта, а также вероятности их проявления. Определение приоритетов состоит из поиска ответов на два вопроса: насколько вероятно проявление риска в проекте; насколько разрушительны могут быть последствия его проявления. Обнаруженные риски помещаются в специальный документ – risk list. Существуют три основные стратегии поведения в отношении рисков: Предотвращение риска, передача риска, принятие риска. Предотвращение риска (risk avoidance) – это процесс реорганизации проекта таким образом, чтобы риск не мог на него воздействовать. Например – отказаться от вновь появившихся передовых инструментов в пользу испытанных, не включать в план те функции, которые требуют освоения новых технологий. Передача риска – перераспределение работ проекта таким образом, чтобы кто-то другой (Заказчик, партнёр и т.п.) отвечал за работу с ним. Принятие риска обязывает Разработчика «заботиться» о нём. Мероприятия по контролю риска (risk control) включают планирование, разрешение и мониторинг. Планирование управления риском подразумевает создание плана действий для каждого отдельного фактора, включая методы смягчения, планы на случай непредвиденных обстоятельств, ответственных лиц и сроки исполнения. Цель действий по смягчению воздействия риска — либо не позволить риску стать проблемой, либо уменьшить его вредное воздействие. Некоторые риски могут быть разрешены в процессе работы над проектом, они удаляются из списка рисков, другие – напротив, обнаружены в ходе выполнения проекта и добавлены в этот документ. Мониторинг рисков призван осуществлять наблюдение над рисками из списка, отслеживать их продвижение вплоть до разрешения, работать с их приоритетами. Современные тенденции в развитии АИС и технологий их создания Индустрия производства АИС претерпела за 2 последних десятилетия качественные изменения. Это связано с такими тенденциями компьютерного мира и мировой экономики, как: развитием и появлением новой элементной базы, наступлением эпохи персональных компьютеров, появлением и развитием интегрированных сред разработки, появлением глобальных сетей передачи данных, глобализацией бизнеса, ростом конкуренции, переходом к экономике, ориентированной на потребителя, появлением и развитием электронного бизнеса и др. АИС прошли путь от однопользовательских систем к системам масштаба рабочей группы, малого предприятия, холдинга, транснациональной корпорации. Среди современных тенденций в развитии технологий создания АИС следует отметить: быстрые методы прототипирования, ориентацию на варианты использования, переход от разработке к настройке. |