Методология экстремального программирования (XP)

Модель жизненного цикла XPявляется итерационно-инкрементной моделью быстрого создания имодификации протопопов программного продукта, которые должныудовлетворять очередному требованию (user story). Модель XP представлена на рисунке 4.1.

Рисунок 4.1. Модель жизненного цикла XP.

Модель XP включает в себя выполнение следующихосновных фаз.

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

2. Истории использования (User Story) – этап сбора требований, записываемых на специальных карточках в виде сценариев выполнения отдельных функций. Истории использования являются требованиями для планирования очередной версии и разработки приемочных тестов (Acceptance tests) для ее проверки.

3. Планирование версии (релиза). Проводится на собрании сучастием заказчика путем выбора User Stories, которые войдут в следующую версию. Одновременно принимаются решения, связанныес реализацией версии. Цель планирования – получение оценок того, что и как можно сделать за 1 – 3 недели создания следующей версиипродукта.

4. Разработка версии (релиза) проводится в соответствии с планоми включает только те функции, которые были отобраны на этапепланирования.

5. Тестирование версии (релиза) проводится с участием заказчика, который ранее участвовал в составлении тестов.

6. Выпуск релиза – разработанная версия передается заказчикудля использования или бета-тестирования.

По завершении цикла делается переход на следующую итерациюразработки

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

Основные правила модели XP также характеризуют ее особенности и основные техники применения:

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

- частая смена версий (small releases): первая работающая версия должна появиться как можно быстрее и тут же должна использоваться, следующие версии подготавливаются через достаточно короткие промежутки времени;

- простые проектные решения (simple design): в каждый момент времени система конструируется так просто, насколько это возможно, новые функции добавляются только после ясной и обоснованной просьбы, вся лишняя сложность удаляется, как только обнаруживается;

- разработка на основе тестирования (test-driven development) означает, что сначала пишутся тесты, демонстрирующие основные возможности системы, чтобы можно было увидеть, что система действительно заработала, а потом уже реализуются модули системы и таким образом, чтобы тесты срабатывали; при этом тесты пишутся заказчиками (заранее);

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

- программирование парами (pair programming): весь код пишется двумя программистами на одном компьютере, что повышает его качество (отсутствие ошибок, понятность, читаемость);

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

Методология Scrum

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

Следует отметить, что Scrum используют не только для разработки ПО, он отлично подходит для многих процессов по созданию продукта: от венчурных до маркетинговых продуктов. Разработчики ПО считают, что Scrum вовсе не методология, а это гибкий управленческий фреймворк (рисунок 4.2), поэтому Scrum обычно дополняют инженерными практиками из других гибких методологий (например, практики разработки из экстремального программирования, или практики анализа и сбора требований из ICONIX). Так что в дальнейшем, если не оговорено иное, под Agile подразумевают семейство гибких методологий, а Scrum рассматривают в качестве управленческого фреймворка, дополненного практиками из других гибких методологий.

Рисунок 4.2. Структура Scrumframework.

Классический Scrum состоит из следующих элементов (рисунок 4.3).

Рисунок 4.3. Элементы Scrum.

1. Роли.

В Scrum принято выделять три основных роли: владелец продукта, скрам-мастер икоманда:

- владелец продукта(Продукт оунер, Product owner, Менеджер продукта) – это человек, ответственный за приоритезацию требований и часто за их создание;

- скрам-мастер– член команды, который дополнительно отвечает за процессы, координацию работы команды и поддержание социальной атмосферы в команде;

- команда– 7±2 человек, которые реализуют требования владельца продукта.

2. Обязанности скрам-мастера.

Скрам-мастер должен ежедневно следить за тем, чтобы скрам-митинг начинался изаканчивался вовремя. Рекомендуется выделять определенное время каждому участнику,чтобы общая протяженность скрама-митинга не превышала заранее оговоренноговремени (например, 15 минут).

Скрам-мастер в начале спринта помогает команде проводить планирование спринта изапуск спринта.

В конце спринта скрам-мастер организует демонстрацию результатов спринта при участиивсех заинтересованных лиц и проводит ретроспективу при участии всех членов проектнойкоманды.

Также в обязанности скрам-мастера входит мониторинг социальных аспектов команды иподдержание командного духа.

3. Артефакты:

- беклог продукта (Product Backlog)– приоритезированный список требований соценкой трудозатрат. Обычно он состоит из бизнес-требований, которые приносятконкретную бизнес-ценность и называются элементы беклога;

- беклог спринта (Sprint Backlog)– часть беклога продукта, с самой высокойважностью и суммарной оценкой, не превышающей скорость команды,отобранная для спринта;

- инкремент продукта – новая функциональность продукта, созданная во времяспринта спринта.

4. Процессы.

Большинство процессов Scrum носят характер встреч, так как данная методологияоснована на качественных коммуникациях.

5. Скрам-митинг.

Скрам-митинг (Scrum meeting, скрам, ежедневный скрам, планерка) – собрание членовкоманды (с возможностью приглашения владельца продукта) для синхронизациидеятельности команды и обозначения проблем. Каждый член команды отвечает на тривопроса:

1. Что было сделано с предыдущего скрам-митинга?

2. Какие есть проблемы?

3. Что будет сделано к следующему скрам митингу?

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

6. Планирование спринта.

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

- все элементы бэклога должны иметь уникальную числовую важность;

- самые важные элементы бэклога должны быть уточнены и понятны всей командеи владельцу продукта;

- владелец продукта должен четко представлять, что будет реализовано в рамкахкаждого элемента бэклога.

Основным результатом планирования спринта является беклог спринта – список задач,которые команда планирует реализовать в рамках спринта. Поскольку длина спринта вScrum жестко фиксирована, то команда определяет количество элементов беклога (объемработ), которые она может реализовать. Можно данную ситуацию отобразить наклассическом «треугольнике управления проектами» (рисунок 4.4):

Рисунок 4.4.Проектный треугольник в Scrum.

7. Обзор спринта.

Обзор спринта (также часто используется термин «демонстрация» или сокращенно«демо») – показ владельцу продукта (и заинтересованным лицам) работающегофункционала продукта, сделанного за спринт. Основная задача проведения обзораспринта заключается в получении обратной связи, а общий цикл ее получения выглядитследующим образом (рисунок 4.5).

Рисунок 4.5. Получение обратной связи в рамках Scrum.

Демонстрация результатов работы не только мотивирует команду, но и подталкиваетреализовывать задачи полностью.

Если взглянуть еще раз на манифест Agile, то там есть пункт, который непосредственнокасается демонстраций: «Готовый продукт важнее документации по нему». Идействительно основной мерой прогресса является функционал нашего продукта,поэтому показывать на демонстрации надо именно программу. Если ваш заказчикнаходится не в одном помещении с вами, используйте специальные средствадемонстрации. Гораздо хуже будет отправить заказчику презентацию или отчет посделанному функционалу, ведь мы хотим получить качественную обратную связь.

В обзоре спринта обязательно должна принимать участие вся команда, при этомвозможны разные стратегии показа. Антипаттерном можно назвать демонстрациюфункционала одним человеком, например, скрам-мастером.

К паттернам можно отнести демонстрацию «чужих» реализованных элементов беклога ипривлечение к демонстрации аналитиков, тестировщиков, верстальщиков, UI-специалистов и так далее. Такой подход позволяет выработать команднуюответственность за результат.

8. Ретроспектива.

В долгосрочном плане ретроспективы (или сокращенно «ретро») являются самой важнойпрактикой Scrum: ведь именно они позволяют адаптировать и кастомизировать Scrum,делая из него по-настоящему гибкий фреймворк для управления проектами.

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

Структура ретроспективы. Обычно ретроспектива занимает от 30 минут до 4 часов и ее продолжительность зависитот следующих факторов:

- длина спринта: чем длиннее спринт, тем больше команда успевает сделать и тембольше материала для обсуждения;

- размер команды: чем команда больше, тем больше надо времени, чтобы укаждого ее члена была возможность высказаться и тем больше функционалакоманда успевает сделать;

- наличие проблем: со временем команда решает проблемы и ретроспективысокращаются по времени.

В процентном соотношении принято выделять такую структуру (рисунок 4.6):

Рисунок 4.6. Структура ретроспективы.

Также традиционным является формат по сбору данных, который заключается в ответахкаждого участника на три вопроса:

1. Что было сделано хорошо?

2. Что можно улучшить?

3. Какие улучшения будем делать?

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

Для максимальной открытости и прозрачности обсуждения необходимо использоватьосновное правило ретроспективы, которое можно озвучивать в начале:«В независимости от того, что удастся выяснить в результате ретроспективы, каждыйчлен команды сделал всё, чтобы добиться успеха».

Если у команды отсутствуют яркие проблемы, то желательно следующие темы обсудитьна ретроспективе:

- скорость команды и ее изменение по сравнению с предыдущими спринтами;

- нереализованные истории пользователей и причины опоздания;

- дефекты и их причины;

- качество процессов (нарушения, отступления).

К паттернам можно отнести анализ сделанных улучшений за несколько прошлыхспринтов. Такая «ретроспектива ретроспектив» может проводить раз в 4 спринта ипозволяет контролировать уровень сделанных улучшений.

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

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

Scrum делает упор на самоорганизующуюся, многофункциональную команду, способную решить необходимые задачи с минимальной координацией. Это особенно привлекательно для малых компаний и стартапов, так как избавляет от необходимости от найма или обучения специализированного персонала руководителей.

Конечно, у Scrum есть и важные недостатки. Ввиду простоты и минималистичности, Scrum задает небольшое количество довольно жестких правил. Однако это вступает в конфликт с идеей клиентоориентированности в принципе, т. к. клиенту не важны внутренние правила команды разработки, особено если они ограничивают клиента. К примеру, в случае необходимости, по решению клиента Sprint backlog может быть изменен, не смотря на явное противоречие с правилами Scrum.

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

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

Тема 5. Определение требований к программному обеспечению

План лекции

1. Проблемы определения программных требований

2. Классификация программных требований

1. Проблемы определения программных требований

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

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

Рисунок 5.1. Изменение требований в процессе разработки

программного продукта.

Ф. Брукс в книге «Мифический человеко-месяц или как создаются программные системы» так охарактеризовал роль требований в разработке программного обеспечения: «Строжайшее и единственное правило построения систем программного обеспечения (ПО) – решить точно, что же строить. Никакая другая часть концептуальной работы не является такой трудной, как выяснение деталей технических требований, в том числе и взаимодействие с людьми, с механизмами и с иными системами ПО. Никакая другая часть работы так не портит результат, если она выполнена плохо. Ошибки никакого другого этапа работы не исправляются так трудно».

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

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

Рисунок 5.2. Группы требований, предъявляемых к ПП.

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

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

Рисунок 5.3. Основные разделы разработки требований.

Структура обсуждаемой области знаний в большой степени совместима со стандартами IEEE 12207.x, ISO/IEC, ГОСТ Р ИСО/МЭК 12207.

2. Классификация программных требований

Некоторые проблемы, возникающие в процессе разработки требований, порожденыотсутствием четкого понимания различия между разными уровнямитребований. Чтобы различить требования разных уровней, используют термины: пользовательские требования (user requirements) дляобозначения высокоуровневых обобщенных требований и системныетребования (system requirements) для детализированного описаниявыполняемых системой функций. Кроме требований этих двух уровней, на практике обычно применяется еще более детализированноеописание программной системы – проектная системная спецификация (software design specification), которая может служить мостоммежду этапом разработки требований и этапом проектированиясистемы. Три перечисленных вида требований можно определитьследующим образом.

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

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

Проектная системная спецификация– обобщенное описаниеструктуры программной системы, которое будет основой для болеедетализированного проектирования системы и ее последующей реализации. Эта спецификация дополняет и детализирует спецификацию системных требований.

Кроме того, требования к программной системе часто классифицируются как функциональные, нефункциональные и требованияпредметной области.

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

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

Требования предметной области характеризуют ту предметнуюобласть, где будет эксплуатироваться система. Эти требования могутбыть функциональными и нефункциональными.

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

Рассмотрим перечисленные категории требований более подробно.

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

Функциональные требования для программных систем могут бытьописаны разными способами

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

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

Вместе с тем, нефункциональные требования могут относитьсяне только к самой программной системе, например, одни из нихмогут накладываться на технологический процесс создания ПО, другие – содержать перечень стандартов качества, используемых впроцессе разработки. Кроме того, в спецификации нефункциональных требований может быть указано, что проектирование системыдолжно выполняться только определенными CASE-средствами, иприведено описание процесса проектирования, которому необходимо следовать.

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

Все нефункциональные требования могут быть разбиты на тригруппы.

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

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

Рисунок 5.4. Нефункциональные требования.

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

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

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

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

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

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

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

Таблица5.1. Методы описания требований

Система записи	Описание
Структурированный естественный язык	Использование стандартных форм и шаблонов для написания спецификаций
Языки описания требований	Специальные структурированные языки(подобно языкам программирования), где спецификация требований строитсяна основе выбранной операционноймодели системы
Графические нотации	Использование диаграмм и блок-схемы, дополненных текстовыми пояснениями. Наиболее известные примеры такогоописания: диаграммы структурного анализа и проектирования, метод описаниявариантов использования
Математические нотации	Системы нотаций на основе математических концепций, такихкак теорияконечных автоматов или теория множеств. Формализованная однозначнаязапись системных требований. Однакомногие заказчики не понимают формальных спецификаций, вследствие чеговозникают определенные проблемы призаключении контрактов на разработкуПП

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

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

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

Тема 6. Разработка требований к программным системам

План лекции

1. Разработка требований

2. Работа с требованиями

1. Разработка требований

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

1) анализ технической осуществимости создания системы;

2) формирование и анализ требований;

3) специфицирование требований и создание соответствующейдокументации;

4) аттестация требований.

На рисунке 6.1 показаны взаимосвязи между этими этапами и документы, сопровождающие каждый этап процесса разработки системных требований.

Рисунок 6.1. Процесс разработки требований.

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

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

Анализ осуществимости требований. Для новых программныхсистем процесс разработки требований должен начинаться с анализа их осуществимости. Началом такого анализа является общее описание системы и ее назначения, а результатом анализа – отчет, вкотором должна быть четкая рекомендация, продолжать или нетпроцесс разработки требований проектируемой системы. Другимисловами, анализ осуществимости должен дать ответы на следующиевопросы: отвечает ли система общим бизнес-целям организациизаказчика и организации-разработчика; можно ли реализовать систему, используя существующие на данный момент технологии и невыходя за пределы заданной стоимости; можно ли объединить систему с другими системами, которые уже эксплуатируются организацией.

Критическим является вопрос, будет ли система соответствоватьцелям бизнеса. Если система не соответствует этим целям, она непредставляет никакой ценности для бизнеса. В то же время многиеорганизации разрабатывают системы, не соответствующие их целям, либо не совсем ясно понимая эти цели, либо под влиянием политических и/или общественных факторов.

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

Как только будут сформулированы подобные вопросы, необходимо определить источники информации. Это могут быть менеджерыотделов, где система будет использоваться, разработчики ПО, знакомые с типом будущей системы, технологи, конечные пользователии т. д. После обработки собранной информации готовится отчет поанализу осуществимости создания системы. В нем должны быть данырекомендации относительно продолжения разработки системы. Могут быть предложены изменения бюджета и графика работ по созданию системы или предъявлены более высокие требования к системе.

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

Один из ключевых принципов программной инженерии заключается в