«Гусарова Н.Ф. МЕТОДОЛОГИЯ ОРГАНИЗАЦИИ ПРОЕКТИРОВАНИЯ И РАЗРАБОТКИ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ Учебное пособие Санкт-Петербург 2012 Предисловие Настоящее учебное пособие составлено в соответствии с рабочей программой ...»

Например, подпроект проектирования может с фиксированным сроком и бюджетом вестись итеративно, а подпроект строительства может выполняться по методике "водопада". Такой комбинированный вариант поддерживается в Turbo Project [Turbo Project] (компонент для Microsoft Project, который автоматизирует создание проектов "сверху вниз").

С другой стороны, итеративные методики могут сами использовать метод водопада. Как правило, используется детализация больших проектов сверху вниз водопадом, а на уровне подпроектов уже господствует итеративность и мобильность. Такая комбинация используется, например, в типично итеративной методике Rational Unified Processes.

Инкрементальная модель – это, по существу, модель постоянного расширения ИТ-системы (рис. 1.23).

Разработка основана на последовательно-параллельном выполнении нескольких цепочек проектирования в соответствии с заранее определенными требованиями.

Рис. 1.23. Инкрементальная модель Множество очень коротких (в Microsoft – ежедневных, в других организациях – недельных) итераций с частичными и небольшими улучшениями приводит к непрерывному внесению изменений в продукт, т.е. к переходу от пилотных прототипов к постепенному увеличению общих функциональных возможностей системы. В частности, в Microsoft этот процесс называется «синхронизация и стабилизация»: проект разбивается на части, к каждой части применяется инкрементальная модель + стабилизация всего проекта путем периодической сборки всех его частей.

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

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

Модель принято изображать в виде спирали (рис. 1.24), причем чем дальше от центра, тем лучше результаты.

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

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

оценка и разрешение рисков, определение целей, разработка и тестирование, планирование.

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

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

План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.

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

Модель сложна с точки зрения управления и в чистом виде применяется достаточно редко. Как правило, она совмещается с другими усложненными методиками управления. Происходит n-кратное (обычно три раза – альфа, бета, релиз) прохождение стадий построения ИТ-системы. Такой вариант ЖЦ показан на рис. 1.25.

Классическая спиральная модель ориентирована на большие, дорогостоящие и сложные проекты. Имеются ее модификации (например, Spiral Architecture Driven Development [SADD]), ориентированные на работу в условиях изменяющихся бизнес-целей при сохранении стабильной архитектуры, удовлетворяющей высоким требованиям по нагрузке и устойчивости.

Рис. 1.25. Спиральная (эволюционная) модель с тремя итерациями 1.3.2. Методологии проектирования ИТ-систем Методология проектирования ИТ-систем – набор стандартизованных и апробированных действий, которые позволяют достичь запланированных функциональностей ИТ-систем средствами имеющихся технологий с учетом заданных ограничений. Применение методологии гарантирует упорядоченный подход к промышленной разработке, использованию и сопровождению ИТ-систем, т.е. вносят в процесс создания ПО инженерный подход.

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

';

Как получится (code&fix) Cleanroom Software Engineering Итеративная Agile Unified Process (AUP) Essential Unified Process (EssUP) Extreme programming, XP Feature Driven Development (FDD) Open Unified Process (OpenUP) Бережливая разработка программного обеспечения (Lean 1.3.3. Методология code&fix ("Как получится") Сode&fix – это отсутствие какого-либо сознательно выбранного метода.

Разработчики, ознакомившись с задачей, практически сразу начинают писать код. Конечно, в каждой команде свой подход к разработке, тем не менее, и в них можно выявить некоторые общие черты:

процесс состоит из двух стадий: написание кода – исправление проблем.

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

итеративный подход в таких проектах не используется.

Основной недостаток такого подхода – его практически невозможно применять на уровне промышленного программирования.

Cleanroom Software Engineering (методология «чистой комнаты») (Х.

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

разработка программного обеспечения на основе на формальных методах;

инкрементальная реализации в рамках статистического контроля качества;

статистическое тестирование;

формальная верификация.

Итеративный подход (iteration – повторение) – выполнение работ параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы. Проект при этом подходе в каждой фазе развития проходит повторяющийся цикл: Планирование – Реализация – Проверка – Оценка (англ. plan-do-check-act cycle) (рис. 1.26).

Рис. 1.26. Итеративная модель разработки Преимущества итеративного подхода:

снижение воздействия серьезных рисков на ранних стадиях проекта, что ведет к минимизации затрат на их устранение;

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

акцент усилий на наиболее важные и критичные направления проекта;

непрерывное итеративное тестирование, позволяющее оценить успешность всего проекта в целом;

раннее обнаружение конфликтов между требованиями, моделями и реализацией проекта;

более равномерная загрузка участников проекта;

эффективное использование накопленного опыта;

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

В качестве примеров реализации итеративного подхода ниже рассматриваются методологии разработки программного обеспечения, созданные компанией Rational Software – Rational Unified Process (RUP) и его облегченный вариант Open Unified Process/ Rational Unified Process (RUP) базируется на унифицированном процессе разработки ПО (USDP), который был предложен создателями ООП (Якобсон, Буч, Рембо). Соответствующий стандарт принят консорциумом Object Managing Group (OMG) в 1997 г.

RUP – это методология создания программного обеспечения, оформленная в виде размещаемой на Web базы знаний, которая снабжена поисковой системой.

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

1. Начало (inception) – предварительное взаимодействие с заинтересованными лицами (заказчик, пользователи, инвесторы и др. stakeholders) (на рис.

1.27 – 1 итерация). На этом этапе формируются видение и границы проекта, создается экономическое обоснование, определяются основные требования, ограничения и ключевая функциональность продукта, создается базовая версия модели прецедентов, оцениваются риски.

2. Проектирование (elaboration) – включает в себя документирование требований (включая детальное описание для большинства прецедентов), спроектированную, реализованную и оттестированную исполняемую архитектуру, обновленное экономическое обоснование и более точные оценки сроков и стоимости, а также сниженные основные риски (на рис. 1.27 – итерации). Фаза заканчивается выбором базовой архитектуры 3. Конструирование (construction) – реализация большей части функциональности продукта. Фаза завершается первым внешним релизом системы, т.е. выпуском работоспособной версии (базового продукта) (на рис.

23 – 3 итерации).

4. Внедрение (transition)– создается финальная версия продукта и передается от разработчика к заказчику. Это включает в себя программу бетатестирования, обучение пользователей, а также определение качества продукта. Фаза заканчиваются выпуском готового продукта В случае, если качество не соответствует ожиданиям пользователей или критериям, установленным в фазе Начало, фаза Внедрение повторяется снова (на рис.

23 – 1 итерация).

В матрице RUP (рис. 1.27) итерации (время) расположены по вертикали, а по горизонтали – рабочие процессы (workflows), которые разделены на рабочие процессы процесса (core process workflows) бизнес-моделирование требования анализ и проектирование реализация (implementation – выполнение) тестирование развертывание (deployment) и рабочие процессы поддержки (core supporting workflows) управление конфигурациями управление взаимодействие с окружением.

На каждой итерации по вертикали показывается распределение усилий (content) между технологическими процессами (workflows). Например, на рис. 24 на второй итерации перехода выполняется только тестирование и развертывание.

Модельные элементы процесса RUP (рис. 1.28):

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

Задача – это единица работы, выполнение которой можно потребовать от конкретной роли.

Артефакт – объект и/или результат работы Рабочий процесс является способом описания последовательностей задач, создающих какой-либо полезный артефакт и описывающий взаимодействия между ролями.

Рис. 1.28. Примеры артефактов проекта в нотации UML: а – документ, б – модель (например, use case диаграмма), в – физический компонент (например, исходный код) RUP позволяет разрабатывать только те артефакты (объекты) и выполнять только те работы и задачи, которые необходимы в конкретном проекте.

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

OpenUP [OpenUP] – это итеративно-инкрементальный метод разработки программных продуктов. Позиционируется как легкий и гибкий вариант RUP.

Рис. 1.29. Жизненный цикл OpenUP OpenUP делит жизненный цикл проекта на четыре фазы: начальная фаза, фазы уточнения, конструирования и передачи (рис. 1.29). Внутри фаз возможны итерации – планируемые, ограниченные во времени интервалы, длительность которых обычно измеряется неделями. План итерации определяет, что именно должно быть сдано по окончании итерации, а результатом является работоспособная версия.

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

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

Для этого они сначала определяют, а затем решают хорошо детализированные задачи из списка элементов работ.

Базовый процесс OpenUP является независимым от инструментов, малорегламентированным процессом, который может быть расширен для удовлетворения потребностей широкого диапазона типов проектов.

Методология Microsoft Solutions Framework (MSF) водит в состав базовых методик корпорации Майкрософт, рассмотренных ранее, и описывает управление людьми и рабочими процессами в процессе разработки решения.

Выделим специфику методики MSF (Microsoft Solutions Framework) [MSF]. Компонентами MSF являются:

Базовые принципы – выражают основные ценности и стандарты, применимые ко всем элементам методики;

Модели MSF– карты организации проектных групп и процессов работы, включающие Модель команд и Модель процессов.

Дисциплины MSF– управление рисками (risk management), управление подготовкой (readiness management) и управление проектами (project management).

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

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

управление программой (program manager) – разработку архитектуры решения, административные службы;

разработку (developer) – разработку приложений и инфраструктуры, технологические консультации;

тестирование (QAE) – планирование, разработку тестов и отчетность по тестам;

управление выпуском (release manager) – инфраструктуру, сопровождение, бизнес-процессы, выпуск готового продукта;

удовлетворение заказчика (user experіence) – обучение, эргономику, графический дизайн, техническую поддержку;

управление продуктом (product manager) – бизнес-приоритеты, маркетинг, представительство интересов заказчика.

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

Модель процессов MSF (MSF process model) сочетает в себе свойства двух стандартных производственных моделей: каскадной (waterfall) и спиральной (spiral). Модель процессов включает основные фазы процесса разработки:

Выработка концепции (Envisioning) Планирование (Planning) Разработка (Developing) Стабилизация (Stabilizing) Внедрение (Deploying) и большое количество промежуточных вех. Разработка ведется итеративными методами. MSF рекомендует начинать разработку решения с построения, тестирования и внедрения его базовой функциональности. Затем к решению добавляются все новые и новые возможности. Такая стратегия именуется стратегией версионирования. С созданием новых версий эволюционирует функциональность решения. В рамках MSF предлагается ряд шаблонов стандартных документов, которые являются артефактами каждой стадии разработки продукта и могут быть использованы для планирования и контроля процесса разработки.

Методология MSF появилась в 1994 г. и постоянно развивается: в частности, произошло разделение методологии на два направления: MSF for Agile Software Development и MSF for CMMI Process Improvement.

RAD (rapid application development – быстрая разработка приложений) – концепция создания средств разработки программных продуктов, уделяющая особое внимание быстроте и удобству программирования, созданию технологического процесса, позволяющего программисту максимально быстро создавать компьютерные программы. Концепцию RAD также часто связывают с концепцией визуального программирования. Основателем RAD считается сотрудник IBM Джеймс Мартин, который в 1980-х годах сформулировал основные принципы RAD, основываясь на идеях Барри Бойма и Скотта Шульца.

Основные принципы RAD Инструментарий должен быть нацелен на минимизацию времени разработки.

Создание прототипа для уточнения требований заказчика.

Цикличность разработки: каждая новая версия продукта основывается на оценке результата работы предыдущей версии заказчиком.

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

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

Управление проектом должно минимизировать длительность цикла разработки.

Среды разработки, частично использующие принципы RAD C++ Builder Clarion Code::Blocks DevelStudio IBM Lotus Domino Designer IntelliJ IDEA IntraWeb Lazarus Macromedia Flash Macromedia Authorware Macromedia Director Microsoft Visual Studio Miracle MonoDevelop NetBeans IDE Omnis Studio PowerBuilder QDevelop (в связке с Qt-Designer) SharpDevelop Visual DataFlex WxDev-C++ wxFormBuilder 1.3.10. Гибкие методологии (Agile software development) Рассмотренные выше методологии – "тяжелые методологии". Они дают наибольший эффект в крупных компаниях, занятых промышленным выпуском программного продукта и готовых на многолетние инвестиции в кардинальную перестройку организационной структуры. В качестве альтернативы предложены "гибкие" методологии – для использования небольшими динамичными компаниями, работающими в сильно конкурентных условиях (очень сжатые сроки, быстро меняющиеся требования, необходимость обеспечения достаточно высокого качества).

Гибкая методология разработки (Agile software development) [Agile] – это концептуальный каркас, в рамках которого выполняется разработка программного обеспечения. Agile – семейство процессов разработки, который определяется Agile Manifesto (разработан и принят 11-13 февраля 2001 года на лыжном курорте The Lodge at Snowbird в горах Юты). Agile Manifesto cодержит 4 ценности и 12 принципов, которыми руководствуются успешные команды, и не содержит практик.

Ценности Agile Manifesto:

личности и их взаимодействия важнее, чем процессы и инструменты;

работающее программное обеспечение важнее, чем полная документация;

сотрудничество с заказчиком важнее, чем контрактные обязательства;

реакция на изменения важнее, чем следование плану.

Принципы Agile Manifesto удовлетворение клиента за счет ранней и бесперебойной поставки ценного ПО;

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

частая поставка рабочего ПО (каждый месяц или неделю или еще чаще);

тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;

проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием;

рекомендуемый метод передачи информации — личный разговор (лицом к лицу);

работающее ПО — лучший измеритель прогресса;

спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределенный срок;

постоянное внимание на улучшение технического мастерства и удобный дизайн;

простота — искусство НЕ делать лишней работы;

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

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

Спектр методологий, которые придерживаются ценностей и принципов, заявленных в Agile Manifesto, постоянно расширяется, некоторые из них:

Agile Modeling Agile Unified Process (AUP) Agile Data Method Essential Unified Process (EssUP) Экстремальное программирование (Extreme programming, XP) Feature Driven Development (FDD) Getting Real Open Unified Process (OpenUP) Бережливая разработка программного обеспечения (Lean Software Development) Большинство гибких методологий нацелены на минимизацию рисков путем сведения разработки к серии коротких циклов (итераций), которые обычно длятся одну-две недели. Детально планируется только ограниченный объем работ, связанный с выпуском очередного релиза. Каждая итерация сама по себе выглядит как программный проект в миниатюре и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, кодирование, тестирование и документирование. Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается, что гибкий программный проект готов к выпуску в конце каждой итерации. По окончании каждой итерации команда выполняет переоценку приоритетов разработки.

Agile-методы делают упор на непосредственное общение лицом к лицу.

Большинство agile-команд расположены в одном офисе, иногда называемом bullpen. Как минимум, она включает и «заказчиков» (product owner - заказчик или его полномочный представитель, определяющий требования к продукту;

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

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

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

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

1.3.11. Экстремальное программирование Методология экстремального программирования (Кент Бек, Уорд Каннингем, Мартин Фаулер) [Бек] основана на следующих принципах:

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

2. проектирование системы выполняется "на ходу"; структура продукта образуется путем последовательной "пристройки" друг к другу отдельных модулей ("историй пользователя" – рис. 1.30), которые задает клиент;

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

отсканированной единицы После сканирования упаковки количество и цена сохраняются.

вверху терминала появляется После обработки всей корзины в краткое описание товара и его нижнюю часть чека добавляется Рис. 1.30. Примеры историй пользователя для ИТ–системы документооборота в магазине 4. вся документация включается в код и представляет собой списки связанных с требованиями заказчика правил, принципов, пожеланий и уточнений;

5. программы пишутся парами – по два человека за одним компьютером (один пишет код, другой думает над архитектурой); фактически это форма непрерывного инспектирования друг друга;

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

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

Scrum [SCRUM ] – одна из самых популярных методологий гибкой разработки. В методологии Scrum всего три роли.

Scrum Master – Скрам Мастер Product Owner – Владелец процесса Team – Команда Скрам Мастер является интерфейсом между менеджментом и командой.

Как правило, эту роль в проекте играет менеджер проекта или тимлид. Важно подчеркнуть, что Скрам Мастер не раздает задачи членам команды: в Agile команда является самоорганизующейся и самоуправляемой. Скрам Мастер ведет Daily Scrum Meeting и отслеживает прогресс команды при помощи Sprint Backlog, отмечая статус всех задач в спринте. ScrumMaster может также помогать Product Owner создавать Backlog для команды Рис. 1.31. Схема коммуникаций в Scrum Владелец процесса – это человек, отвечающий за разработку продукта.

Как правило, это product manager для продуктовой разработки, менеджер проекта для внутренней разработки и представитель заказчика для заказной разработки. Product Owner – это единая точка принятия окончательных решений для команды в проекте, поэтому это всегда один человек, а не группа или комитет. Product Owner координирует и приоритизирует Product backlog, предоставляет понятные и тестируемые требования команде, отвечает за приемку кода в конце каждой итерации, но он не вправе ставить задачи конкретному члену проектной команды в течении спринта.

Команда в Scrum кроссфункциональна (рис. 1.31). В нее входят люди с различными навыками – разработчики, аналитики, тестировщики. Команда берет на себя обязательства по выполнению объема работ на спринт перед Product Owner. Работа команды оценивается как работа единой группы. Команда отвечает за оценку элементов баклога, принимает решение по дизайну и имплементации, разрабатывает софт и предоставляет его заказчику. Типичный размер команды – 72.. Для облегчения коммуникаций команда должна находиться в одном месте (colocated).

Основными артефактами проекта в Scrum являются Product Backlog, Sprint Backlog и Sprint.

Product Backlog (рис. 1.32) – это приоритезированный список имеющихся на данный момент бизнес-требований и технических требований к системе.

Product Backlog постоянно пересматривается и дополняется - в него включаются новые требования, удаляются ненужные, пересматриваются приоритеты.

Sprint Backlog (1.33) содержит функциональность, выбранную Product Owner из Product Backlog. Все функции разбиты по задачам, каждая из которых оценивается командой. Каждый день команда оценивает объем работы, который нужно проделать для завершения задач. Сумма оценок оставшейся работы может быть построена как график зависимости от времени (Sprint Burndown chart) (рис. 1.34). Он демонстрирует прогресс команды по ходу спринта. Sprint Backlog не может быть изменен никем, кроме команды.

Рис. 1.32. Пример Product Backlog Рис. 1.33. Пример Spint Backlog Рис. 1.34. Пример Sprint Burndown chart В Scrum итерация называется Sprint. Ее длительность составляет 1 месяц (30 дней). Результатом Sprint является готовый продукт (build), который можно передавать (deliver) заказчику. Короткие спринты обеспечивают быструю обратную связь от заказчика к проектной команде. Каждый спринт представляет собой маленький "водопад". В течение спринта делаются все работы по сбору требований, дизайну, кодированию и тестированию продукта. Ежедневно в ходе спринта проходят короткие информационные собрания (meetings) команды, а к конце спринта проводится собрание длительностью 4 часа, когда команда демонстрирует инкремент продукта, созданный за последний спринт.

Методология Канбан [сводка] была разработана на фирме Тойота как реализация принципа бережливого производства и описывается тремя основными принципами:

Визуализируйте производство Разделите работу на задачи, каждую задачу напишите на карточке и поместите на стену или доску.

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

Ограничивайте WIP (work in progress или работу, выполняемую одновременно) на каждом этапе производства Измеряйте время цикла (среднее время на выполнение одной задачи) и оптимизируйте постоянно процесс, чтобы уменьшить это время.

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

Команда для работы использует Канбан-доску (рис. 1.35). Столбцы доски имеют следующее содержание.

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

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

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

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

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

Если найдены ошибки, задача возвращается в Разработку, если нет – передвигается дальше.

Деплоймент – как предусмотрено в проекте (выложить новую версию продукта на сервер, сохранить код в репозитории и т.д.) Закончено – все работы по задаче закончены полностью.

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

Задачи на доске Канбан имеют размер Minimal Narketing Feature (ММФ), т.е. имеют маркетинговый смысл для клиентов – например, Добавить русскую локализацию в продукт, Изменить внешний вид интерфейса под новые стандарты – и рассчитаны на выполнение в течение 1–2 недель.

Использование методологии Канбан дает следующие преимущества:

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

сразу видны узкие места, которые "расшиваются" силами всей команды;

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

однако Канбан подходит не для всех команд.

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

Все существующие методологии можно расположить на шкале "формальное планирование и контроль" – "командная работа и чистое доверие", причем Agile-методологии расположены на "правой" стороне этой шкалы.

Тем не менее, проверить, принадлежит ли конкретная методология семейству Agile, невозможно. Манифест Agile не может служить таким определением, так как, во-первых, слишком размыт, во-вторых, направлен против Waterfall.

Принципам манифеста соответствует практически любой Code&Fix проект.

RUP также нигде не противоречит принципам agile. В то же время некорректно сравнивать Agile и RUP из-за полной неопределенности первого.

Методологии Scrum и XP являются более или менее определенными. Так, например, существует тест на соответствие Scrum (так называемый Nokia Test) или XP. Если применить Scrum и XP или другую определенную методологию в чистом виде невозможно по тем или иным причинам, то внедряется некоторый процесс, заимствующий практики и принципы из других методологий Agile семейства, плюс какие-то практики из других методов.

Зона применения "чистого" Scrum и XP формируется следующими характеристиками проекта:

относительно небольшие команды (до 10 человек);

проекты, не являющиеся life-critical и из нерегулируемого бизнес-домена;

не строго фиксированная цена проекта;

не требуется длительный цикл тестирования;

нераспределенная разработка.

Зона применения Канбан описывается такими характеристиками:

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

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

Практически все отдельные элементы agile-методик применялись и раньше, но Agile за счет системных эффектов выводит их на новый уровень:

их взаимное воздействие и активное применение действует на команду сильнее, чем просто отдельное использование практик. Например, тотальное использование Unit Tests сильно облегчается в TDD и просто необходимо для эффективного рефакторинга. В этом случае возможна Emerging Acrhitecture.

Совместное планирование в Scrum обеспечивает общую ответственность за результат, что работает только в случае полной прозрачности работы внутри итерации (Daily Scrum и Demo) и коррекции процесса по ходу работы (Ретроспектива).

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

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

ЧАСТЬ 2. ПОДХОДЫ И ТЕХНОЛОГИИ ПОДДЕРЖКИ

ПРОЕКТИРОВАНИЯ И РАЗРАБОТКИ

НА РАЗЛИЧНЫХ ЭТАПАХ ЖЦ ПО

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

2.1.1. Единая система программной документации Единая система программной документации (ЕСПД) – отечественный комплекс стандартов на программную документацию (в профессиональном просторечии – «девятнадцатый гост»). Стандарты ЕСПД были приняты в конце 1970-х годов. В них отражена практика работы ведомственных вычислительных центров, где эксплуатировались большие ЭВМ. В основном стандарты ЕСПД содержат требования к составу, содержанию и оформлению документов, описывающих программу на разных стадиях ее жизненного цикла.

Кроме того, несколько документов посвящено порядку хранения и обновления документации.

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

Состав нормативно-технических документов ЕСПД приведен в табл. 2.1.

Таблица 2. Обозначение Наименование Единая система программной документации.

ГОСТ 19.001- Единая система программной документации.

ГОСТ 19.002- Схемы алгоритмов и программ. Правила выполнения Единая система программной документации.

ГОСТ 19.004- Единая система программной документации.

ГОСТ 19.005-85 Р-схемы алгоритмов и программ. Обозначения условные графические и ГОСТ 19.101-77 Единая система программной документации.

Виды программ и программных документов Единая система программной документации.

ГОСТ 19.102- Единая система программной документации.

ГОСТ 19.103- Обозначение программ и программных документов Единая система программной документации.

ГОСТ 19.104- Единая система программной документации.

ГОСТ 19 105- Общие требования к программным документам Единая система программной документации.

ГОСТ 19.106-78 Требования к программным документам, выполненным печатным способом Единая система программной документации.

ГОСТ 19.201- Техническое задание. Требования к содержанию и оформлению Единая система программной документации.

ГОСТ 19.202- Спецификация. Требования к содержанию и оформлению Единая система программной документации.

ГОСТ 19.301-79 Программа и методика испытаний. Требования к содержанию и оформлению Единая система программной документации.

ГОСТ 19.401- Текст программы. Требования к содержанию и оформлению Единая система программной документации.

ГОСТ 19.402- Единая система программной документации.

ГОСТ 19 403- Ведомость держателей подлинников Единая система программной документации.

ГОСТ 19.404- Пояснительная записка. Требования к содержанию и оформлению Единая система программной документации.

ГОСТ 19.501- Формуляр. Требования к содержанию и оформлению Единая система программной документации.

ГОСТ 19.502- Описание применения. Требования к содержанию и оформлению Единая система программной документации.

ГОСТ 19.503-79 Руководство системного программиста. Требования к содержанию и Единая система программной документации.

ГОСТ 19.504- Руководство программиста. Требования к содержанию и оформлению Единая система программной документации.

ГОСТ 19.505- Руководство оператора. Требования к содержанию и оформлению Единая система программной документации.

ГОСТ 19.506- Описание языка. Требования к содержанию и оформлению Единая система программной документации.

ГОСТ 19.507- Ведомость эксплуатационных документов Единая система программной документации.

ГОСТ 19.508-79 Руководство по техническому обслуживанию. Требования к содержанию Единая система программной документации.

ГОСТ 19.601- Общие правила дублирования, учета и хранения Единая система программной документации.

ГОСТ 19.602-78 Правила дублирования, учета и хранения программных документов, выполненных печатным способом Единая система программной документации.

ГОСТ 19.603- Единая система программной документации.

ГОСТ 19.604-78 Правила внесения изменений в программные документы, выполненные 2.1.2. Комплекс стандартов на автоматизированные системы Комплекс стандартов на автоматизированные системы (КСАС, ГОСТ 34.*) – основополагающий набор нормативно-технических документов для всех отечественных системных интеграторов, особенно – участвующих в выполнении государственных заказов. Практически все работы по созданию автоматизированных систем для государственного и крупного коммерческого заказчика в нашей стране сопровождаются выпуском технической документации в соответствии с этими стандартами.

КСАС невозможно рассматривать в качестве учебника по проектированию, реализации или документированию автоматизированных систем, но он определяет наиболее важные аспекты ее существования, в том числе:

понятие автоматизированной системы;

классификация автоматизированных систем;

терминология, описывающая различные части системы и взаимосвязи между ними;

стадии создания автоматизированной системы и их основные результаты;

требования к составу и содержанию системной технической документации.

Стандарты КСАС касаются только документации на автоматизированные системы как таковые. В отношении документации на программные компоненты систем разработчикам предлагается соблюдать требования ЕСПД, а в отношении документации на технические средства — ЕСКД.

Состав нормативно-технических документов КСАС приведен в табл. 2.2.

Таблица 2.2.

Обозначение Наименование ГОСТ 34.003-90 Комплекс стандартов на автоматизированные системы.

Автоматизированные системы. Термины и определения Комплекс стандартов на автоматизированные системы.

ГОСТ 34.201- Виды, комплектность и обозначение документов при создании автоматизированных систем ГОСТ 34.601-90 Комплекс стандартов на автоматизированные системы.

Автоматизированные системы. Стадии создания ГОСТ 34.602-89 Информационная технология.

Комплекс стандартов на автоматизированные системы.

Техническое задание на создание автоматизированной системы РД 50-34.698-90 Комплекс стандартов и руководящих документов на автоматизированные системы.

Автоматизированные системы требования к содержанию документов 2.1.3. Стандарты ИСО в области системной и программной инженерии Ряд нормативных документов ИСО прямо или косвенно касается технической документации в сфере информационных технологий и порядка ее разработки. В отличие от ЕСПД и КСАС, эти документы, за исключением разве что ISO/IEC 15289, содержат минимум конкретных требований к составу и структуре документов. Зато они насыщены всевозможными методическими указаниями, направленными на получение технической документации наилучшего качества. Практическое применение этих стандартов требует предварительной работы по их внедрению, т. е. по переосмыслению существующего положения дел в предлагаемых ими терминах, по реорганизации работы персонала и его обучению. В конечном счете, на базе стандартов ИСО каждая организация, считающая следование им полезным, разрабатывает свой внутренний стандарт.

Стандарты ИСО/МЭК, в отличие от ЕСПД, содержат много разумных правил содержательного характера, но не содержит процедур их формальной проверки. В этой связи можно применять оба ряда стандартов одновременно:

они касаются разных аспектов документирования и друг другу практически не противоречат.

Подчеркнем, что номинально в Росси действующими стандартами являются именно стандарты этой серии.

В табл. 2.3 перечислены стандарты ИСО, касающиеся программной и системной документации, а также процессов ее разработки.

Таблица 2.3.

ГОСТ Р ИСО/МЭК 12207- ГОСТ Р ИСО/МЭК ТО 15271-2002 Руководство по применению ГОСТ Р ИСО/МЭК ГОСТ Р ИСО/МЭК 9126-93 Оценка программной продукции. Характеристики качества и руководство по их применению ГОСТ Р ИСО/МЭК 15910-2002 Процесс создания документации пользователя программного средства ГОСТ Р ИСО/МЭК ТО 9294- Руководство по управлению документированием программного обеспечения ГОСТ Р ИСО/МЭК 15288-2005 Системная инженерия.

ГОСТ Р 51904- ISO 6592: ГОСТ Р ИСО 9127-94 Документация пользователя и информация на упаковке Детальное содержание стандартов рассматривается в специальном курсе.

Для сравнения в табл. 2.4 приведены перечни процессов ЖЦ проектирования и разработки ПО, определяемые имеющими наибольшее хождение в России системами стандартов:

ГОСТ Р ИСО/МЭК 12207-99 «Информационная технология. Процессы жизненного цикла программных средств»

ГОСТ Р ИСО/МЭК 15288-2005 «Информационная технология. Системная инженерия. Процессы жизненного цикла систем»

ГОСТ Р 51904-2002 «Программное обеспечение встроенных систем. Общие требования к разработке и документированию».

Таблица 2.4.

ГОСТ Р ИСО/МЭК 12207-99 ГОСТ Р ИСО/МЭК 15288-2005 ГОСТ Р 51904- Эксплуатация Управление средой предприятия ний к ПО Сопровождение Управление инвестициями проектирование ПО Вспомогательные процессы Управление конфигурацией Управление ресурсами Интегральные проОбеспечение качества Управление качеством цессы Разрешение проблем Управление рисками сертификационное соУправление конфигурациями провождение Организационные процессы Создание инфраструктуры Управление информацией Обучение Определение требований правоУсовершенствование обладателей Как реализуются процессы в каждом стандарте? Если в ГОСТ 19.* и даже в ГОСТ 34.* четко записано, какой процесс и когда выполняется, то в ГОСТ Р ИСО/МЭК этой регламентации нет. Здесь процессы могут выполняться в течение различных этапов ЖЦ, из процессов выбираются отдельные задачи. Стандарты этой серии являются скорее рамочными и предполагают развитие во взаимодействии заказчика и разработчика, в том числе создание на их основе корпоративных стандартов Это обстоятельство, в частности, прямо прописано в ГОСТ Р 51904-2002:

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

В настоящем стандарте обсуждаются характеристики, формы, методы контроля конфигурации и содержание документов ЖЦ ПО».

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

Системно-инженерный взгляд на проектирование ПО отражен в стандартах серии «Системная инженерия» (табл. 2.5).

Таблица 2. Обозначение Наименование ISO/IEC 15288 – Системная и программная инженерия – содержание информационных продуктов (документации) системного или программного ISO/IEC 15289– ISO/IEC TR 19760– Программная и системная инженерия – управление жизненным ISO/IEC TR 24774– Системная и программная инженерия – руководство по управлеISO/IEC PDTR Системная инженерия – применения и управление процессами ISO/IEC 26702– Системная и программная инженерия – рекомендованная практика архитектурного описания для систем, имеющих программISO/IEC 42010– Стандарты этой серии имеют следующие характеристики:

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

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

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

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

проекта);

ссылаются на связанный стандарт ISO 12207;

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

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

стадии ЖЦ жестко стандартом не предписываются, они могут сосуществовать или возобновляться после завершения;

стадии ЖЦ определяют основные точки принятия решений – вехи проекта (decision gates);

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

Архитектурное описание концепции в соответствии со стандартами ISO/IEC 42010–2007, IEEE 1471 представлено на рис. 2.1.

Has 1..* Рис. 2.1. Архитектура концепции стандартов ISO/IEC 42010–2007, IEEE В качестве структурных элементов эти стандарты использует процессы – типовые шаблоны, отражающие те или иные организационные практики.

Существенно, что процессы документированы, могут быть предметом обсуждения, а их выполнение, согласно ISO 15504, должно проверяться по формальным показателям, в том числе:

– наличие продуктов (результатов процессов;

– выполнение всех предписанных действий и задач;

– выполнение требований и ограничений;

– выполнение измерений хода процесса.

В то же время стандарты технологически нейтральны, т.е. конкретный перечень технологий для предписанных процессов не регламентируется. Так, в управлении моделью жизненного цикла разработчик имеет выбор из IDEF, UML, DEMO, BusinessStudio, ОргМастер и т.д., в проектном управлении – выбор из CPM, CCPM, Last Planner и т.д. Реализация такого выбора должна быть закреплена в корпоративных стандартах и является ключевым фактором успешного внедрения.

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

• RD - Определение производственных требований, • ES - Исследование существующих систем, • TA - Определение технической архитектуры, • DB - Проектирование и построение БД, • MD - Проектирование и реализация модулей, • CV - Конвертирование данных, • DO - Документирование, • TE - Тестирование, • TR - Обучение, • TS - Переход к новой системе, • PS - Поддержка и сопровождение.

Тогда ЖЦ процесса разработки может выглядеть, например, так:

RD.020 – RD.030 – RD.070 – BR.020 – BR.080 – MD.020 – MD.060 – DO.070 – TE.110 – PM.050 – CV.140 – PM.080, где RD.020 – изучение существующих бизнес-процессов, RD.030 – моделирование будущих бизнес-процессов, RD.070 – выявление детальных требований к будущим бизнес-процессам, BR.020 – отображение бизнеспроцессов в функциональность приложения, BR.080 – тестирование принятых решений, MD.020 – оценка решений по доработке функциональности приложения, MD.060 – дизайн расширений функциональности приложения DO.070 – разработка инструкций пользователя, TE.110 – тестирование приложения, PM.050 – установка приложения на систему периода эксплуатации CV.140 – ввод начальных данных, PM.080 – запуск новой системы Доработка функционала описывается цепочкой задач BR.020 – BR.080 – MD.020, где BR.020 – выявление «дыр» функциональности приложения, предварительное формулирование решения, как можно устранить «дыры»; BR.080 – первоначальная оценка предложенного предварительного решения; MD. – окончательное формулирование решения, как можно устранить «дыры», оценка трудозатрат.

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

Вопросы, связанные со стандартами, включая аспекты применения международных стандартов в России, их сравнение со стандартами серий ГОСТ 34, ГОСТ Р и т.п., активно обсуждаются в сети Интернет (см.,, например, [ФОСТАС]).

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

– конкретность и детализация требований;

– необходимый уровень открытости и гибкости, адаптируемости к конкретным условиям;

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

– специфика прикладной области 2.1.6. Стандарт CobiT и его роль в управлении ИТ Среди перечисленных в табл. 2.12 стандартов ключевую роль в российской практике играет стандарт CobiT (Контрольные ОБъекты для Информационных и смежных Технологий) – набор документов, в которых изложены принципы управления и аудита информационных технологий [CobiT]. В состав стандарта входят шесть книг, ориентированных на разные аудитории (рис. 2.37).

Структура CobiT. CobiT реализует единый подход к сбору, анализу информации, подготовке выводов и заключений на всех этапах управления, контроля и аудита ИТ, возможность сравнения существующих ИТ-процессов с "лучшими" практиками, в том числе отраслевыми. В основу стандарта CobiT положено следующее утверждение: для предоставления информации, необходимой организации для достижения ее целей, ресурсы ИТ должны управляться набором естественно сгруппированных процессов. Для этого CobiT выделяет 34 высокоуровневые цели контроля, по одной на каждый ИТпроцесс, которые сгруппированы в 4 домена:

Планирование и Организация;

Проектирование и Внедрение;

Эксплуатация и Сопровождение;

Мониторинг.

Ресурсы ИТ в CobiT описаны пятью составляющими:

Данные – объекты в широком смысле (внутренние и внешние), структурированные и неструктурированные, а также графика, звук и т.д.

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

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

Оборудование – все ресурсы, создающие и поддерживающие информационные технологии.

Люди – персонал, его навыки: умение планировать и организовывать, комплектовать, обслуживать и контролировать информационные системы и услуги.

Включая Высокоуровневые Цели Контроля

ПРИНЦИПЫ ОБЪЕКТЫ ПРИНЦИПЫ

УПРАВЛЕНИЯ КОНТРОЛЯ АУДИТА

Рис. 2.37.. Состав книг CobiT Денежные средства или капитал рассматриваются не в качестве ИТ-ресурса, а в качестве инвестиций в любой из вышеуказанных ресурсов.

В качестве критериев оценки информации используются:

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

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

Конфиденциальность – обеспечение защиты информации от неавторизованного ознакомления.

Целостность – точность, полнота и достоверность информации в соответствии с требованиями бизнеса.

Пригодность – предоставление информации по требованию бизнеспроцессов.

Согласованность – соответствие законам, правилам и договорным обязательствам.

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

Определять уровни обслуживания и управлять ими Управлять услугами сторонних организаций Управлять производительностью и наращиваемостью Обеспечивать непрерывность услуг Обеспечивать безопасность системы Определить и распределить затраты Рис. 2.38. Вопросы CobiT на всем жизненном цикле ИТ Схема CobiT, объединяющая вышеперечисленные артефакты на всем протяжении ЖЦ, представлена на рис. 2.38.

Особенностью идеологии CobiT является то, что он рассматривает управление и аудит в ИТ-сфере как две части одного целого (оказание воздействия и контроль результатов).

Управления ИТ по стандарту CobiT. Управление ИТ предоставляет основу, которая связывает ИТ-процессы, ИТ-ресурсы и информацию со стратегией и целями организации. Реализуя общий принцип единства архитектуры бизнеса и ИТ-архитектуры (см. раздел1.2.1), CobiT формулирует цели управления ИТ в организации в виде следующих вопросов:

Что является результатом ИТ-процессов?

Что является решением проблем в ИТ?

Из чего состоят эти решения?

Будут ли работать эти решения?

Как их реализовать?

Для получения измеримых ответов на эти вопросы в CobiT используются следующие артефакты:

Модели зрелости;

Критические факторы успеха (КФУ);

Ключевые индикаторы цели (КИЦ);

Ключевые показатели результата (КПР).

Модели зрелости в CobiT предназначены для контроля над ИТпроцессами организации и являются аналогом модели CMMI для оценки уровня зрелости разработки программного обеспечения. В соответствии с моделью, каждый из 34 процессов управления ИТ располагается на одном из 5 уровней:

0. Не существует. Полное отсутствие каких-либо процессов управления ИТ.

Организация не признает существования проблем в ИТ;

1. Начало (Анархия). Организация признает существование проблем управления ИТ и необходимость их решения, но не существует никаких стандартизованных решений, подход руководства к решению ИТ-проблем хаотичен;

2. Повторение (Фольклор). Существует всеобщее осознание проблем управления ИТ. Показатели деятельности и ИТ-процессов находятся в развитии, охватывая процессы планирования, функционирования, мониторинга и управления инвестициями в ИТ. Руководство организации регламентировало меры по управлению ИТ, а также методы управления и оценки, но процесс не был принят в организации. Не существует формализованного обучения, набора взаимосвязанных стандартных процедур управления, ответственность возложена на сотрудников.

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

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

4. Управление (Измеряемый). Существует полное понимание проблем управления ИТ на всех уровнях организации, постоянно происходит обучение сотрудников. Определены и поддерживаются в актуальном состоянии соглашения об уровне обслуживания. Четко распределена ответственность, установлен уровень владения процессами. Процессы ИТ соответствуют бизнесу и стратегии ИТ. В первую очередь улучшения в процессах ИТ основываются на измеряемых количественных показателях.

Существует возможность управлять процедурами и метриками процессов, измерять их соответствие. Все совладельцы процесса осознают риски, важность ИТ и возможности, которые они предоставляют. Руководство организации определило допустимые отклонения, при которых процессы должны работать. Если процессы не работают эффективно и продуктивно, действия предпринимаются во многих (но не всех случаях). Процессы постоянно совершенствуются, их результаты соответствуют "лучшим практикам". Формализован порядок анализа первопричин. Присутствует понимание необходимости постоянного совершенствования. Ограниченно применяются передовые технологии, основанные на современной инфраструктуре и модифицированных стандартных инструментах. Все необходимые ИТ-специалисты вовлечены в бизнес-процессы. Управление ИТ превращается в процесс уровня всей организации. Деятельность управления ИТ интегрируется в процесс управления организацией;

5. Оптимизация (Оптимизируемый). В организации существует углубленное понимание управления ИТ, проблем и решений ИТ, а также перспектив.

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

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

Шкала моделей зрелости процессов управления представлена на рис.

2.39 (верхняя часть рисунка).

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

Примеры КФУ:

Действия по управлению ИТ интегрированы в процессы управления организации и стиль работы руководителей;

Действия по управлению ИТ ясно определены, формализованы и осуществляются на основе потребностей предприятия с соответствующей отчетностью;

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

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

Улучшение управления производительностью и стоимостью;

Увеличение дохода от инвестиций в ИТ;

Сокращение времени запуска в продажу нового продукта или услуги;

Поиск новых и удовлетворение существующих клиентов;

Эталонное тестирование зрелости управления ИТ.

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

Примеры КИР:

Увеличение рентабельности ИТ-процессов;

Улучшение работы и планирования действий по совершенствованию ИТпроцессов;

Увеличение нагрузки на ИТ-инфраструктуру;

Повышение степени удовлетворения пользователей (опросы пользователей и количество жалоб);

Повышение производительности сотрудников (в том числе, повышение морального духа).

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

Для достижения пятого, "оптимизированного" уровня зрелости в управлении ИТ организация должна быть, по крайней мере, на пятом уровне в домене Мониторинг и как минимум на четвертом уровне моделей зрелости для всех других доменов.

Аудит ИТ по стандарту CobiT. Для каждого ИТ-процесса, определенного CobiT, в Принципах аудита представлена следующая информация:

Секция высокого уровня принципов аудита:

Название бизнес-процесса;

Требования бизнеса (Объекты контроля высокого уровня);

Как осуществлять контроль;

Секция детального уровня принципов аудита:

Детальные объекты контроля;

Как понять ИТ-процесс (кому задавать вопросы);

Как оценить контроль ИТ-процесса;

Как оценить соответствие этого контроля управлению;

Как доказать риск не выполнения целей управления.

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

Для инструментальной поддержки аудита разработан программный продукт CobiT Advisor 3rd Edition (Audit). "CobiT Advisor" представляет собой базу данных Foxpro, структурированную в соответствии с 34 процессами и 318 объектами контроля стандарта CobiT, которая позволяет хранить, обрабатывать и предоставлять информацию о результатах проведения аудита в форме отчетов в различных форматах (например, MS Word, Excel).

На практике при проведении аудита для каждого ИТ-процесса ИТаудитору, как минимум, необходимо выполнить следующую работу:

1. Определить высокоуровневый объект контроля;

2. Определить ИТ-процесс;

3. Проанализировать границы аудита;

4. Определить детальные объекты контроля;

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

6. Назначить задания на оценку средств контроля (Принято ли во внимание...);

7. Оценить соответствие;

8. Проверить доказательства.

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

1. Общий раздел.

2. Описание текущей ситуации.

3. Выводы и заключения.

4. Рекомендации.

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

Содержание отчетов может варьироваться в зависимости от уровней предоставления информации:

Резюме для руководителей – краткий документ (объемом в 1–3 страницы), предоставляется высшему руководству на уровне генерального директора, финансового директора, исполнительного директора;

Общий – полный отчет, предоставляется менеджерам среднего звена.

Кроме того, на российском рынке ИТ-консалтинга Заказчик в большинстве случаев требует от подрядчика (в основном от аудиторской компании) не только заключения и рекомендаций, но и их реализации, хотя бы до стадии проведения тендеров на поставку оборудования или услуг.

Рис. 2.39 иллюстрирует процессы управления и аудита по стандарту CobiT.

Легенда используемых символов Требования международных Текущий статус организации Рис. 2.39. Процессы управления и аудита Проведение аудита ИТ представлено в левой части рисунка. Объекты контроля располагаются в соответствующих фазах бизнес-процессов, которые могут быть формализованы с соблюдением требований стандартов, предоставляя информацию с каждого объекта контроля на более высокий уровень. Собираемая информация объединяется в высокоуровневые объекты контроля, которые затем сводятся в четыре домена CobiT. Оценка организации выводится на шкале модели зрелости организации, и лицу, принимающему решения, гарантируется возможность оценки текущего состояния ИТ в организации, сравнения с требованиями международных стандартов, а также с "лучшей" практикой и стратегией организации в той же отрасли.

Процессы управления схематично отражены в правой половине рисунка.

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

Рис. 2.40. Разделение объектов управления и аудита Рис. 2.40 отражает разделение объектов управления и аудита в CobiT.

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

Открытый стандарт CobiT имеет свою нишу в общем комплексе стандартов, методик и руководств. Остановимся на его пересечениях с ITIL, который тоже содержит рекомендации по управлению ИТ-услугами.

ITIL – библиотека лучшего практического опыта в части предоставления ИТ-услуг, а CobiT специализируется и на управлении, и на аудите ИТ.

Процессы ITIL, как и любые другие процессы, могут управляться и контролироваться стандартом CobiT.

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

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

2.2.1. Определения и классификация программных требований Понятие программного требования имеет несколько трактовок [Glossary], [Вигерс]:

условие или возможность, требуемая пользователем для решения задач или достижения целей;

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

документальная репрезентация (зафиксированное представление, определение, описание) условий или возможностей, перечисленных в предыдущих пунктах;

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

Управление требованиями является критически важным в проектах по разработке ПО и во многом определяет саму возможность успешного выполнения проекта.

Классификация требований разнообразна. Так, [SWEBOK] выделяет:

требования к продукту / требования к процессу;

функциональные / нефункциональные требования;

системные / программные / общие требования.

На рис. 2.2 представлен классический подход [Вигерс] высокоуровневого структурирования групп требований как требований к продукту.

Рис. 2.2. Классификация требований по [Вигерс] Стандарт ГОСТ Р 51904-2002 определяет следующие понятия:

требование – характеристика того, чем система или ПО должны обладать, чтобы быть приемлемыми для заказчика;

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

требования верхнего уровня – требования к ПО, разработанные на основании анализа системных требований и требований, связанных с безопасностью системы;

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

Предложена также модель классификации FURPS+ (рис. 2.3):

функциональные требования (Functionality) требования удобства использования (Usability) требования надежности (Reliability) требования производительности (Performance) требования возможности сопровождения (Supportability) При этом символом "+" обозначены дополнительные условия, в том числе:

проектные ограничения требования управления системой требования к графическому интерфейсу пользователя физические требования юридические требования Рис. 2.3. Классификация требований по модели FURPS+ Функциональные требования часто представляются в виде сценариев (вариантов использования, Use Сase). Работа с ними подробно рассматривается в соответствующем курсе. В контексте управления проектом разработки ПО важна также роль нефункциональных требований, явно не выделенных в модели FURPS+, в частности:

бизнес-правила, в том числе распределение ответственности в проектируемом ПО (например, кто будет осуществлять конкретный вариант использования) и внутрикорпоративные инициативы (например, стремление достичь зрелости процессов по CMMI 4-го уровня). При разработке требований в сценариях Use Cases обычно включается ссылка на уже описанное бизнес-правило, для описания которых разработаны специализированные языки, например, OCL – Object Constraint Language, BRML – Business Rules Markup Language;

внешние интерфейсы, в том числе взаимодействие с другими системами и операционной системой;

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

В связи с активным развитием agile-методологий (см. разделы 1.3.10– 1.3.13) существует также структурирование требований по высокоуровневым возможностям (ключевым характеристикам, особенности) – features (жаргонное название – фичи), которые определяются в в рамках маркетинговой стратегии продвижения тиражируемого решения для конкретной целевой аудитории. Согласно [Вигерс], feature – это группа требований, узнаваемая заинтересованными лицами, которые вовлечены в процесс принятия решения по приобретению ПО. С точки зрения инженерии требований, features являются самостоятельным артефактом, который может быть соотнесен как с функциональными требованиями, так и с нефункциональными (в том числе с ограничениями проектирования или атрибутами качества). Это может быть список характеристик коробочного продукта или список высокоуровневых возможностей системы, например, при автоматизации бизнес-процессов конкретной организации. Features могут быть разного уровня детализации – от выражения высокоуровневых возможностей системы (например, «Расчет заработной платы …»), до достаточно конкретных требований (например, «Автоматическое уведомление Клиента по e-mail о резервировании товара на складе») Процесс работы с требованиями действует постоянно на всех этапах ЖЦ ПО и, в свою очередь, состоит из следующим процессов:

извлечение требований, анализ требований, спецификация требований, проверка (валидация) требований.

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

Участниками этого процесса являются Заинтересованные лица (stakeholders)– все, кто имеет возможность (в том числе, материальную) повлиять на реализацию проекта/продукта. Они группируются в определенные роли. [SWEBOK] выделяет следующие роли:

Пользователи (Users) – те, кто будет непосредственно использовать ПО;

Заказчики (Customers) – те, кто отвечает за заказ программного обеспечения или, в общем случае, являются целевой аудиторией на рынке программного обеспечения (образуют целевой рынок ПО);

Заметим, что ГОСТ Р ИСО/МЭК 12207-99 определяет более суженное понятие заказчика как организацию, которая приобретает или получает систему, программный продукт или программную услугу от поставщика..

Аналитики (Market analysts) – представители потребителей для продуктов массового рынка ПО;

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

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

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

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

интервьюрирование – традиционный подход извлечения требований;

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

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

прототипы – инструмент для уточнения и/или детализации требований;

(от бумажных моделей до пилотных подсистем или бета-версии продуктов);

наблюдение – непосредственное присутствие аналитиков и инженеров рядом с пользователем в процессе выполнения последним его бизнеспроцесса: заметим, что типовая практика в eXtreme Programming onsite customer – присутствующий заказчик (см. раздел 1.3.11);

Разъясняющие встречи (facilitated meetings [SWEBOK]) – особая форма встреч участников проекта и заинтересованных лиц со стороны заказчика, посвященная обсуждению тех вопросов, ответы на которые не могут быть определены в результате обычных интервью и которые требуют вовлечения большего количества лиц, чем просто пары пользователь-аналитик;

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

На рис. 2.4 [Storyboard] представлены колмпоненты раскадровки. Извлечение требований путем раскадровки поддерживается различным ПО (см., например, [Storyboard]).

другие, достаточно эффективные практики (например, Requirements Workshop, Role Playing и т.п.), описание которых можно найти в литературе.

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

обнаружение и разрешение конфликтов между требованиями;

определение границ задачи, решаемой создаваемым программным обеспечением; в общем случае – определение scope (или bounds), границ и содержания программного проекта;

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

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

классификация требований;

концептуальное моделирование;

архитектурное проектирование и распределение требований.

Классификация требований рассмотрена выше в настоящем разделе.

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

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

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

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

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

определение системы – документ, который описывает требования к системе с точки зрения области применения (домена). Соответственно, изложение требований в нем ведется в терминах прикладной области;

системные требования – документ, который описывает деятельность системных инженеров;

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

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

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

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

Излишнее акцентирование внимания на деталях реализации, т.е. попытка отразить в документе не то, ЧТО должна делать система, а то, КАК она это будет делать.

Слабая формализация бизнес-процессов.

Проверка (валидация) требований. В связи с высокой важностью требований для успеха проекта в целом для них должны быть предусмотрены процедуры проверки (verification) и утверждения = аттестации (validation, как это сформулировано в ГОСТ Р ISO/IEC 12207).

Напомним, что стандарт ИСО 9000:2000 определяет эти термины следующим образом:

Верификация – подтверждение на основе представления объективных свидетельств того, что установленные требования были выполнены.

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

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

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

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

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

утверждение модели. Проверка и аттестация модели, например, объектно-ориентированного представления бизнес-сущностей и связей между ними, может быть выполнена формальными методами, например, путем статического анализа, поиска связей и путей взаимодействия между объектами и выделения различного рода несоответствий и т.д. С другой стороны, соответствие модели заданным требованиям может быть закреплено формально со стороны пользователей/заказчика;

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

[SWEBOK] особо выделяет специфику работы с требованиями.

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

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

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

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

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

2.2.3. Примеры корпоративных решений для поддержки требований Согласно ГОСТ Р 51904-2002, организация должна разрабатывать корпоративные стандарты на разработку требований, учитывающие принятые в организации подходах, применяемые методологии, методы и практики, специфику проектов, а также требования заказчиков к определению требований и форме представления результатов их анализа.

В качестве примера можно привести руководство "Введение в Управление требованиями с использованием Team Foundation Server" [VS TFS 2010].

Целью данного руководства является предоставление формализованного опыта Microsoft в виде рекомендованных процедур и процессов, конфигураций Visual Studio Team System и Team Foundation Server, а также развитие навыков по дисциплине "Инженерия требований" в ЖЦ разработки ПО. Ввиду разнообразия методик, используемых в промышленной разработке ПО, в руководство ориентировано на различные методологию - традиционную и гибкую разработку.

В зависимости от процесса, вы можете создать рабочий элемент для требования как сценарий (функциональные требования для MSF Agile), качество обслуживания (нефункциональные требования для MSF Agile), как история (XP), сценарий использования (RUP) или как требование (MSF для CMMI или Традиционный). Рабочие элементы используются для определения и отслеживания требования. Это позволяет отображать их в журнале, ранжировать, проверять, назначать и формировать отчетность. Существенно, что требование на бизнес-уровне определяется рабочим элементом "Возможность" (Feature) в Team Foundation Server, что добавляет элемент формальности, который можно не использовать для небольшой и более гибкой команды.

Для создания рабочих элементов можно использовать Microsoft Project, Microsoft Excel, клиент Team Foundation, Web Access или другой инструмент с использованием объектной модели Team Foundation, причем тип рабочего элемента Тестовый сценарий является новым свойством в Visual Studio2010.

Ключевые стадии процесса управления требованиями иллюстрируются рис.

2.5–2.9.

Для шаблона MSF CMMI тип рабочего элемента Возможность (рис. 2.7) добавлен как часть релиза Team Foundation Server 2010. При использовании шаблона MSF для Agile Возможность не существует, поэтому рекомендуется использовать бизнес-требования как тип рабочего элемента Возможность в целях отслеживания трассировки от бизнес-границ до системных границ.