Материалы для подготовки по курсу «Управление требованиями и системы поддержки жизненного цикла» ДЛЯ СТУДЕНТОВ НАПРАВЛЕНИЕ ПОДГОТОВКИ 09.03.01 «ИНФОРМАТИКА И ВЫЧИСЛИТЕЛЬНАЯ ТЕХНИКА» ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ 1. Система – совокупность интегрированных и регулярно взаимодействующих или взаимозависимых элементов, созданная для достижения определенных целей, причем отношения между элементами определены и устойчивы, а общая производительность или функциональность системы лучше, чем у простой суммы элементов [7]. 2. Структура – строение и внутренняя форма организации системы, способ взаимодействия элементов системы посредством определённых связей. 3. Системный подход – направление методологии научного познания, в основе которого лежит рассмотрение объекта как системы: целостного комплекса взаимосвязанных элементов; совокупности взаимодействующих объектов; совокупности сущностей и отношений. 4. Процесс – динамическое изменение системы во времени. 5. Требование – 1. условия или возможности, необходимые пользователю для решения проблем или достижения целей; 2. условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетворять стандартам, спецификациям или другим формальным документам; 3. документированное представление условий или возможностей для п. 1 и 2. 6. Проект – это уникальный набор процессов, состоящих из скоординированных и управляемых задач с начальной и конечной датами, предпринятых для достижения цели. Достижение цели проекта требует получения результатов, соответствующих определённым заранее требованиям, в том числе ограничения на получения результатов, таких как время, деньги и ресурсы. 7. Информационная система – комплекс, включающий вычислительное и коммуникационное оборудование, программное обеспечение, лингвистические средства и информационные ресурсы, а также системный персонал и обеспечивающий поддержку динамической информационной модели некоторой части реального мира для удовлетворения информационных потребностей пользователей. 8. Управление требованиями – это систематический подход к выявлению, организации и документированию требований к системе, а также процесс, в ходе которого вырабатывается и обеспечивается соглашение между заказчиком и выполняющей проект группой по поводу меняющихся требований к системе. 9. Функциональные требования (functional requirements) – определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнестребований. 10.Нефункциональные требования описывают цели и атрибуты качества проекта. 11.Атрибуты качества системы (quality attributes) – дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. 12.Характеристика продукта (feature) – это набор логически связанных функциональных и нефункциональных требований, которые обеспечивают возможности пользователя и удовлетворяют бизнестребованиям. 13.Бизнес-требования – требования заказчиков, имеющие высший приоритет, описывающие саму суть информационной системы, ее истинное назначение. 14.Системные требования (system requirements) – это высокоуровневые требования к продукту, которые содержат многие подсистемы. 15.Пользовательские требования (user requirements) – описывают цели и задачи, которые пользователи смогут решать при помощи системы. 16.Надежность – свойство объекта сохранять во времени в установленных пределах значения всех параметров, характеризующих способность выполнять требуемые функции в заданных режимах и условиях применения, технического обслуживания, хранения и транспортирования; в узком смысле – свойство объекта сохранять работоспособное состояние в течение некоторого времени или некоторой наработки 17.Устав проекта – документ, отражающий ключевые сведения о проекте, разрабатываемый в ходе подготовки проекта. 18.План управления проектом – должен отражать содержание и границы проекта, ключевые вехи проекта, плановый бюджет проекта, предположения и ограничения, требования и стандарты. 19.Техническое задание – исходный документ на проектирование технического объекта (изделия). Он устанавливает основное назначение разрабатываемого объекта, его технические характеристики, показатели качества и технико-экономические требования, предписание по выполнению необходимых стадий создания документации (конструкторской, технологической, программной и т. д.) и её состав, а также специальные требования. 20.Образ информационной системы (vision) – описание того, что информационная система представляет сейчас и что она будет представлять собой по завершению каждой стадии ее разработки. Образ ИС позволяет ясно представить всем участникам команды, что за систему они строят. 21.Границы проекта (project scope) – указывают, какую функциональность ИС следует ожидать в текущей версии ИС, а также в что будет осуществляться в последующих. 22.Документ об образе и границах – содержит бизнес-требования. Владельцем данного документа, как правило является то лицо, которое финансирует проект. 23.Глоссарий – представляет собой документ, описывающий все основные определения, встречающиеся в проекте. 24.Спецификация требований (Software Requirements Specification, SRS) – законченное описание поведения программы, которую требуется разработать. Включает ряд пользовательских сценариев (use cases), которые описывают все варианты взаимодействия между пользователями и программным обеспечением. 25.Вариант использования – описание последовательности действий, которые может осуществлять система в ответ на внешние воздействия пользователей или других программных систем. 26.Жизненный цикл проекта – представляет собой непрерывный процесс, начинающийся с момента принятия решения о создании информационной системы и заканчивается в момент полного изъятия ее из эксплуатации. 1 ТЕОРЕТИЧЕСКАЯ ЧАСТЬ 1. Понятие жизненного цикла информационной системы Понятие жизненного цикла является одним из базовых понятий методологии проектирования информационных систем. Жизненный цикл информационной системы представляет собой непрерывный процесс, начинающийся с момента принятия решения о создании информационной системы и заканчивается в момент полного изъятия ее из эксплуатации. Существует международный стандарт, регламентирующий жизненный цикл информационных систем – ISO/IEC 12207. Стандарт ISO/IEC 12207 определяет структуру жизненного цикла, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания информационной системы. Согласно данному стандарту структура жизненного цикла основывается на трех группах процессов: - основные процессы жизненного цикла (приобретение, поставка, разработка, эксплуатация, сопровождение); - вспомогательные процессы, обеспечивающие выполнение основных процессов (документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, оценка, аудит, разрешение проблем); - организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого жизненного цикла, обучение). Рассмотрим каждую из указанных групп более подробно. Основные процессы жизненного цикла Среди основных процессов жизненного цикла наибольшую важность имеют три: разработка, эксплуатация и сопровождение. Каждый процесс характеризуется определенными задачами и методами их решения, исходными данными, полученными на предыдущем этапе, и результатами. Разработка Разработка информационной системы включает в себя все работы по созданию информационного программного обеспечения и его компонентов в соответствии с заданными требованиями. Разработка информационного программного обеспечения также включает: - оформление проектной и эксплуатационной документации; Q подготовку материалов, необходимых для проведения тестирования разработанных программных продуктов; - разработку материалов, необходимых для организации обучения персонала. Разработка является одним из важнейших процессов жизненного цикла информационной системы и, как правило, включает в себя стратегическое планирование, анализ, проектирование и реализацию (программирование). Эксплуатация Эксплуатационные работы можно подразделить на подготовительные и основные. К подготовительным относятся: - конфигурирование базы данных и рабочих мест пользователей; - обеспечение пользователей эксплуатационной документацией; - обучение персонала. Основные эксплуатационные работы включают: - непосредственно эксплуатацию; - локализацию проблем и устранение причин их возникновения; - модификацию программного обеспечения; - подготовку предложений по совершенствованию системы; - развитие и модернизацию системы. Сопровождение Службы технической поддержки играют весьма заметную роль в жизни любой корпоративной информационной системы. Наличие квалифицированного технического обслуживания на этапе эксплуатации информационной системы является необходимым условием для решения поставленных перед ней задач, причем ошибки обслуживающего персонала могут приводить к явным или скрытым финансовым потерям, сопоставимым со стоимостью самой информационной системы. Основными предварительными действиями при подготовке к организации технического обслуживания информационной системы являются следующие: выделение наиболее ответственных узлов системы и определение для них критичности простоя. Это позволит выделить наиболее критичные составляющие информационной системы и оптимизировать распределение ресурсов для технического обслуживания: - определение задач технического обслуживания и их разделение на внутренние (решаемые силами обслуживающего подразделения) и внешние (решаемые специализированными сервисными организациями). Таким образом, производится четкое определение круга исполняемых функций и разделение ответственности; - проведение анализа имеющихся внутренних и внешних ресурсов, необходимых для организации технического обслуживания в рамках описанных задач и разделения компетенции. Основные критерии для анализа: наличие гарантии на оборудование, состояние ремонтного фонда, квалификация персонала; - подготовка плана организации технического обслуживания, в котором необходимо определить этапы исполняемых действий, сроки их исполнения, затраты на этапах, ответственность исполнителей. Обеспечение качественного технического обслуживания информационной системы требует привлечения специалистов высокой квалификации, которые в состоянии решать не только каждодневные задачи администрирования, но и быстро восстанавливать работоспособность системы при сбоях. Вспомогательные процессы Среди вспомогательных процессов одно из главных мест занимает управление конфигурацией. Это один из вспомогательных процессов, поддерживающих основные процессы жизненного цикла информационной системы, прежде всего процессы разработки и сопровождения. При разработке проектов сложных информационных систем, состоящих из многих компонентов, каждый из которых может разрабатываться независимо и, следовательно, иметь несколько вариантов реализации и/или несколько версий одной реализации, возникает проблема учета их связей и функций, создания единой структуры и обеспечения развития всей системы. Управление конфигурацией позволяет организовывать, систематически учитывать и контролировать внесение изменений в различные компоненты информационной системы на всех стадиях ее жизненного цикла. Организационные процессы Управление проектом связано с вопросами планирования и организации работ, создания коллективов разработчиков и контроля над сроками и качеством выполняемых работ. Техническое и организационное обеспечение проекта включает: - выбор методов и инструментальных средств для реализации проекта; - определение методов описания промежуточных состояний разработки; - разработку методов и средств испытаний созданного программного обеспечения; - обучение персонала. Обеспечение качества проекта связано с проблемами верификации, проверки и тестирования компонентов информационной системы. Верификация – это процесс определения соответствия текущего состояния разработки, достигнутого на данном этапе, требованиям этого этапа. Проверка – это процесс определения соответствия параметров разработки исходным требованиям. Проверка отчасти совпадает с тестированием, которое проводится для определения различий между действительными и ожидавшимися результатами и оценки соответствия характеристик информационной системы исходным требованиям. 2. Структура жизненного цикла информационной системы Полный жизненный цикл информационной системы включает в себя, как правило, анализ, проектирование, кодирование (программирование), тестирование, внедрение и эксплуатацию. Главная особенность индустрии АИС состоит в концентрации сложности на начальных этапах ЖЦ (анализ, проектирование) при относительно невысокой сложности и трудоемкости последующих этапов. Более того, нерешенные вопросы и ошибки, допущенные на этапах анализа и проектирования, порождают на последующих этапах трудные, часто неразрешимые проблемы и, в конечном счете, приводят к неуспеху всего проекта. Рассмотрим эти этапы более подробно. Анализ требований является первой фазой разработки АИС, на которой требования заказчика уточняются, формализуются и документируются. Фактически на этом этапе дается ответ на вопрос: «Что должна делать будущая система?». Именно здесь лежит ключ к успеху всего проекта. В практике создания больших систем АИС известно немало примеров неудачной реализации проекта именно из-за неполноты и нечеткости определения системных требований. Список требований к разрабатываемой системе должен включать: - совокупность условий, при которых предполагается эксплуатировать будущую систему (аппаратные и программные ресурсы, предоставляемые системе; внешние условия ее функционирования; состав людей и работ, имеющих к ней отношение): - описание выполняемых системой функций; - ограничения в процессе разработки (директивные сроки завершения отдельных этапов, имеющиеся ресурсы, организационные процедуры и мероприятия, обеспечивающие защиту информации). Целью анализа является преобразование общих, неясных знаний о требованиях к будущей системе в точные (по возможности) определения. На этом этапе определяются: - архитектура системы, ее функции, внешние условия, распределение функций между аппаратурой и АИС; - интерфейсы и распределение функций между человеком и системой; - требования к программным и информационным компонентам АИС, необходимые аппаратные ресурсы, требования к БД, физические характеристики компонент АИС, их интерфейсы. Этап проектирования дает ответ на вопрос: «Как (каким образом) система будет удовлетворять предъявленным к ней требованиям?». Задачей этого этапа является исследование структуры системы и логических взаимосвязей ее элементов, причем здесь не рассматриваются вопросы, связанные с реализацией на конкретной платформе. Проектирование определяется как «(итерационный) процесс получения логической модели системы вместе со строго сформулированными целями, поставленными перед нею, а также написания спецификаций физической системы, удовлетворяющей этим требованиям». Обычно этот этап разделяют на два подэтапа: - проектирование архитектуры АИС, включающее разработку структуры и интерфейсов компонент, согласование функций и технических требований к компонентам, методам и стандартам проектирования, производство отчетных документов; - детальное проектирование, включающее разработку спецификаций каждой компоненты, интерфейсов между компонентами, разработку требований к тестам и плана интеграции компонент. В результате деятельности на этапах анализа и проектирования должен быть получен проект системы, содержащий достаточно информации для реализации системы на его основе в рамках бюджета выделенных ресурсов и времени. В ходе этапа кодирования (программирования), отталкиваясь от результатов проектирования, реализуем систему в виде компонентов – исходных текстов программ, сценариев, двоичных файлов, исполняемых модулей и т. д. Более конкретно, целью кодирования является: - Планирование необходимой на каждой итерации сборки системы. Мы используем инкрементный подход к разработке, результатом чего является реализация системы посредством последовательности малых управляемых шагов. - Распределение системы путем отображения исполняемых компонентов на узлы модели размещения. Эта деятельность базируется на активных классах, обнаруженных в ходе анализа. - Реализация классов и подсистем проектирования, обнаруженных в ходе проектирования, Так, классы проектирования реализуются в виде файлов компонентов, содержащих исходные тексты программ. В рабочем процессе тестирования проверяются результаты реализации путем тестирования каждого билда, включая как внутренние и промежуточные, так и финальные версии системы, передаваемые внешним агентам. Задачей тестирования является: - Планирование тестов, необходимых на каждой итерации, включая тесты на целостность и системные тесты. Тесты на целостность необходимо проводить после каждого билда, в то время как системные тесты требуются только в конце итерации. - Проектирование и реализация тестов для создания тестовых примеров, определяющих предмет тестирования, процедур тестирования, определяющих метод проведения тестирования, и, по возможности, – исполняемых тестовых компонентов для автоматизации тестирования. - Проведение разнообразных тестов и систематическая обработка результатов каждого теста. Билды, в которых обнаруживаются дефекты, подвергаются повторному тестированию. После этого может произойти возврат к предшествующим рабочим процессам с целью исправления серьезных ошибок. В фазе эксплуатации и сопровождения внимание сосредоточено на том, чтобы способствовать утверждению продукта в сообществе пользователей. Способ, которым это делается, зависит от сущности отношений программы и ее рынка. Так, если программа выводится на массовый рынок, команда разработчиков распространяет бета-версию среди типичных пользователей, найденных на специальных площадках, где «водятся» бета-тестеры. Если продукт предназначен для одиночного клиента или нескольких площадок в крупной организации, команда устанавливает продукт на одной из этих площадок. Основные задачи этой фазы: - сравнить функциональность системы, разработанной на предыдущих фазах, с требованиями и выяснить степень удовлетворенности заинтересованных лиц; - рассмотреть все вопросы, необходимые для работы пользователей с системой, включая недостатки, сообщения о которых приходят от бета-тестеров и группы приемо-сдаточного тестирования. Команда готовится к тиражированию продукта, разбивке его по пакетам, развертыванию и резервному копированию, и восстановлению системы. На этой фазе мы не вносим в продукт коренных изменений. Команда разработчиков и клиент должны вносить серьезные изменения в требования на более ранних фазах. Однако команда отыскивает небольшие недостатки, которые не были замечены на фазе построения и могут быть исправлены в рамках существующего базового уровня. В обязанности команды по отношению к клиенту может также входить предоставление поддержки при создании подходящей для работы с проектом среды и обучение организации клиента правильному использованию продукта. Команда может оказывать пользователям помощь при параллельной работе с новой системой и с той унаследованной системой, которую она заменяет. Также она может способствовать конверсии баз данных в новую конфигурацию. В случае если продукт предназначен для широкого распространения (рынок коробочных продуктов), эти сервисы обычно встраиваются в программу установки, которая является частью продукта и поддерживается службой поддержки. Фаза внедрения завершается выпуском продукта. Жизненный цикл образуется в соответствии с принципом нисходящего проектирования и, как правило, носит итерационный характер: реализованные этапы, начиная с самых ранних, циклически повторяются в соответствии с изменениями требований и внешних условий, введением ограничений и т.п. На каждом этапе жизненного цикла порождается определенный набор документов и технических решений, при этом для каждого этапа исходными являются документы и решения, полученные на предыдущем этапе. Каждый этап завершается верификацией порожденных документов и решений с целью проверки их соответствия исходными. Сведем данные по каждому этапу в итоговую таблицу. Таблица 1. Жизненный цикл АИС. № Наименование этапа Основные характеристики 1 Разработка и анализ Определяются основные задачи АИС, проводится бизнес-модели декомпозиция задач по модулям и определяются функции с помощью которых решаются эти задачи. Описание функций осуществляется на языке производственных (описание процессов предметной области), функциональных (описание форм обрабатываемых документов) и технических требований (аппаратное, программное, лингвистическое обеспечение АИС). Метод решения: Функциональное моделирование. Результат: 1.Концептуальная модель АИС, состоящая из описания предметной области, ресурсов и потоков данных, перечень требований и ограничений к технической реализации АИС. 2.Аппаратно-технический состав создаваемой АИС. 2 Формализация бизнес- Разработанная концептуальная модель модели, формализуется, т.е. воплощается в виде логической разработка логической модели АИС. модели Метод решения: Разработка диаграммы бизнес-процессов. "сущность-связь" (ER (Entity-Relationship) – CASEдиаграммы). Результат: Разработанное информационное обеспечение АИС: схемы и структуры данных для всех уровней модульности АИС, документация по 3 4 5 логической структуре АИС, сгенерированные скрипты для создания объектов БД. Выбор Разработка АИС: выбирается лингвистическое лингвистического обеспечение (среда разработки – инструментарий), обеспечения, проводится разработка программного и разработка методического обеспечения. Разработанная на программного втором этапе логическая схема воплощается в обеспечения АИС. реальные объекты, при этом логические схемы реализуются в виде объектов базы данных, а функциональные схемы – в пользовательские формы и приложения. Метод решения: Разработка программного кода с использованием выбранного инструментария. Результат: Работоспособная АИС. Тестирование и отладка На данном этапе осуществляется корректировка АИС информационного, аппаратного, программного обеспечения, проводится разработка методического обеспечения (документации разработчика, пользователя) и т.п. Результат: Оптимальный состав и эффективное функционирование АИС. Комплект документации: разработчика, администратора, пользователя. Эксплуатация и Особенность АИС созданных по архитектуре контроль версий клиент сервер является их многоуровневость и многомодульность, поэтому при их эксплуатации и развитии на первое место выходят вопросы контроля версий, т.е. добавление новых и развитие старых модулей с выводом из эксплуатации старых. Например, если ежедневный контроль версий не ведется, то в как показала практика, БД АИС за год эксплуатации может насчитывать более 1000 таблиц, из которых эффективно использоваться будет лишь 20-30%. Результат: Наращиваемость и безизбыточный состав гибкой, масштабируемой АИС 3 Модели жизненного цикла информационной системы. Моделью жизненного цикла информационной системы будем называть некоторую структуру, определяющую последовательность осуществления процессов, действий и задач, выполняемых на протяжении жизненного цикла информационной системы, а также взаимосвязи между этими процессами, действиями и задачами. В стандарте ISO/IEC 12207 не конкретизируются в деталях методы реализации и выполнения действий и задач, входящих в процессы жизненного цикла информационной системы, а лишь описываются структуры этих процессов. Это вполне понятно, так как регламенты стандарта являются общими для любых моделей жизненного цикла, методологий и технологий разработки. Модель же жизненного цикла зависит от специфики информационной системы и условий, в которых она создается и функционирует. Поэтому не имеет смысла предлагать какие-либо конкретные модели жизненного цикла и методы разработки информационных систем для общего случая, без привязки к определенной предметной области. Существующие модели ЖЦ определяют порядок исполнения этапов в ходе разработки, а также критерии перехода от этапа к этапу. В соответствии с этим выделяют три следующие модели ЖЦ: 1. Каскадная модель (70-80г.г.) – предполагает переход на следующий этап после полного окончания работ по предыдущему этапу. 2. Поэтапная модель с промежуточным контролем (80-85г.г.) – итерационная модель разработки АИС с циклами обратной связи между этапами. Преимущество такой модели заключается в том, что межэтапные корректировки обеспечивают меньшую трудоемкость по сравнению с каскадной моделью; с другой стороны, время жизни каждого из этапов растягивается на весь период разработки. 3. Спиральная модель (86-90г.г.) – делает упор на начальные этапы ЖЦ: анализ требований, проектирование спецификаций, предварительное и детальное проектирование. На этих этапах проверяется и обосновывается реализуемость технических решений путем создания прототипов. Каждый виток спирали соответствует поэтапной модели создания фрагмента или версии программного изделия, на нем уточняются цели и характеристики проекта, определяется его качество, планируются работы следующего витка спирали. Таким образом, углубляются и последовательно конкретизируются детали проекта, и в результате выбирается обоснованный вариант, который доводится до реализации. К настоящему времени наибольшее распространение получили следующие две основные модели жизненного цикла: - каскадная модель, иногда также называемая моделью «водопад» (waterfall); - спиральная модель. 4. Каскадная модель жизненного цикла информационной системы Каскадная модель демонстрирует классический подход к разработке различных систем в любых прикладных областях. Для разработки информационных систем данная модель широко использовалась в 70-х и первой половине 80-х годов. Каскадные методы проектирования хорошо описаны в зарубежной и отечественной литературе разных направлений: методических монографиях, стандартах, учебниках. Организация работ по каскадной схеме официально рекомендовалась и широко применялась в различных отраслях. Таким образом, наличие не только теоретических оснований, но и промышленных методик и стандартов, а также использование этих методов в течение десятилетий позволяет называть каскадные методы классическими. Каскадная модель предусматривает последовательную организацию работ. При этом, основной особенностью является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будут полностью завершены все работы на предыдущем этапе. Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. 1. Основные этапы разработки по каскадной модели За десятилетия существования модели «водопад» разбиение работ на стадии и названия этих стадий менялись. Кроме того, наиболее разумные методики и стандарты избегали жесткого и однозначного приписывания определенных работ к конкретным этапам. Тем не менее, все же можно выделить ряд устойчивых этапов разработки, практически не зависящих от предметной области (Рис. 8): - анализ требований заказчика; - проектирование; - разработка; - тестирование и опытная эксплуатация; - сдача готового продукта. Анализ Проектирование Разработка Тестирование Сдача Рис. 8 – Каскадная модель разработки На первом этапе проводится исследование проблемы, которая должна быть решена, четко формулируются все требования заказчика. Результатом, получаемым на данном этапе, является техническое задание (задание на разработку), согласованное со всеми заинтересованными сторонами. На втором этапе разрабатываются проектные решения, удовлетворяющие всем требованиями, сформулированным в техническом задании. Результатом данного этапа является комплект проектной документации, содержащей все необходимые данные для реализации проекта. Третий этап – реализация проекта. Здесь осуществляется разработка программного обеспечения (кодирование) в соответствии с проектными решениями, полученными на предыдущем этапе. Методы, используемые для реализации, не имеют принципиального значения. Результатом выполнения данного этапа является готовый программный продукт. На четвертом этапе проводится проверка полученного программного обеспечения на предмет соответствия требованиям, заявленным в техническом задании. Опытная эксплуатация позволяет выявить различного рода скрытые недостатки, проявляющиеся в реальных условиях работы информационной системы. Последний этап – сдача готового проекта. Главная задача этого этапа – убедить заказчика, что все его требования реализованы в полной мере. Этапы работ в рамках каскадной модели часто также называют частями «проектного цикла» системы. Такое название возникло потому, что этапы состоят из многих итерационных процедур уточнения требований к системе и вариантов проектных решений. Жизненный цикл самой системы существенно сложнее и больше. Он может включать в себя произвольное число циклов уточнения, изменения и дополнения уже принятых и реализованных проектных решений. В этих циклах происходит развитие информационной системы и модернизация отдельных ее компонентов. 2. Основные достоинства каскадной модели Каскадная модель имеет ряд положительных сторон, благодаря которым она хорошо зарекомендовала себя при выполнении различного рода инженерных разработок и получила широкое распространение. Рассмотрим основные достоинства модели «водопад»: - на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности. На заключительных этапах также разрабатывается пользовательская документация, охватывающая все предусмотренные стандартами виды обеспечения информационной системы: организационное, методическое, информационное, программное, аппаратное; - выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения и соответствующие затраты. Каскадная модель изначально разрабатывалась для решения различного рода инженерных задач и не потеряла своего значения для прикладной области до настоящего времени. Кроме того, каскадный подход хорошо зарекомендовал себя и при построении определенных информационных систем. Имеются в виду системы, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования, с тем чтобы предоставить разработчикам свободу выбора реализации, наилучшей с технической точки зрения. К таким информационным системам, в частности, относятся сложные расчетные системы, системы реального времени. Тем не менее, несмотря на все свои достоинства, каскадная модель имеет ряд недостатков, ограничивающих ее применение при разработке информационных систем. Причем эти недостатки делают ее либо полностью неприменимой, либо приводят к увеличению сроков разработки и стоимости проекта. В настоящее время многие неудачи программных проектов объясняются именно применением последовательного процесса разработки. 3. Недостатки каскадной модели Перечень недостатков каскадной модели при ее использовании для разработки информационных систем достаточно обширен. Вначале просто перечислим их, а затем рассмотрим основные из них более подробно: - существенная задержка получения результатов; - ошибки и недоработки на любом из этапов выясняются, как правило, на последующих этапах работ, что приводит к необходимости возврата на предыдущие стадии; - сложность распараллеливания работ по проекту; - чрезмерная информационная перенасыщенность каждого из этапов; - сложность управления проектом; - высокий уровень риска и ненадежность инвестиций. Задержка получения результатов обычно считается главным недостатком каскадной схемы. Данный недостаток проявляется в основном в том, что вследствие последовательного подхода к разработке согласование результатов с заинтересованными сторонами производится только после завершения очередного этапа работ. Поэтому может оказаться, что разрабатываемая информационная система не соответствует требованиям пользователей. Причем такие несоответствия могут возникать на любом этапе разработки – искажения могут непреднамеренно вноситься и проектировщиками-аналитиками, и программистами, так как они не обязательно хорошо разбираются в тех предметных областях, для которых производится разработка Кроме того, используемые при разработке информационной системы модели автоматизируемого объекта, отвечающие критериям внутренней согласованности и полноты, могут в силу различных причин устареть за время разработки (например, из-за внесения изменений в законодательство, колебания курса валют и т. п.). Это относится и к функциональной модели, и к информационной модели, и к проектам интерфейса пользователя, и к пользовательской документации. Возврат на более ранние стадии. Данный недостаток каскадной модели, в общем-то, является одним из проявлений предыдущего. Поэтапная и последовательная работа над проектом может быть следствием того, что ошибки, допущенные на более ранних этапах, как правило, обнаруживаются только на последующих стадиях работы над проектом. Поэтому, после того как ошибки проявятся, проект возвращается на предыдущий этап, перерабатывается и снова передается на последующую стадию. Это может служить причиной срыва графика работ и усложнения взаимоотношений между группами разработчиков, выполняющих отдельные этапы работы. Самым же неприятным является то, что недоработки предыдущего уровня могут обнаруживаться не сразу на последующем уровне, а позднее (например, на стадии опытной эксплуатации могут проявиться ошибки в описании предметной области). Это означает, что часть проекта должна быть возвращена на начальный уровень работы. Вообще, работа может быть возвращена с любого этапа на любой предыдущий этап, поэтому в реальном случае каскадная схема разработки имеет вид, приведенный на Рис. 9. Анализ Проектирование Разработка Тестирование Сдача Рис. 9 – Реальный процесс разработки по каскадной схеме Одной из причин данной ситуации является то, что в качестве экспертов, участвующих в описании предметной области, часто выступают будущие пользователи системы, которые нередко не могут четко сформулировать то, что они хотели бы получить. Кроме того, заказчики и исполнители часто неправильно понимают друг друга вследствие того, что исполнители обычно не являются специалистами в предметной области решаемой задачи, а заказчики далеки от программирования. Сложность параллельного ведения работ. Отмеченные выше проблемы возникают вследствие того, что работа над проектом строится в виде цепочки последовательных шагов. Причем даже в том случае, когда разработку некоторых частей проекта (подсистем) можно вести параллельно, при использовании каскадной схемы распараллеливание работ весьма затруднительно. Сложности параллельного ведения работ связаны с необходимостью постоянного согласования различных частей проекта. Чем сильнее взаимозависимость отдельных частей проекта, тем чаще и тщательнее должна выполняться синхронизация, тем сильнее зависимы друг от друга группы разработчиков. Поэтому преимущества параллельного ведения работ просто теряются. Отсутствие параллелизма негативно сказывается и на организации работы всего Коллектива разработчиков. Работа одних групп сдерживается другими. Пока производится анализ предметной области, проектировщики, разработчики и те, кто занимается тестированием и администрированием, почти не имеют работы. Кроме того, при последовательной разработке крайне сложно внести изменения в проект после завершения этапа и передаче проекта на следующую стадию. Так, например, если после передачи проекта на следующий этап группа разработчиков нашла более эффективное решение, оно не может быть использовано. Это связано с тем, что более раннее решение уже, возможно, реализовано и связано с другими частями проекта. Поэтому исключается (или, по крайней мере, существенно затрудняется) доработка проекта после его передачи на следующий этап. Информационная перенасыщенность. Проблема информационной перенасыщенности возникает вследствие сильной зависимости между различными группами разработчиков. Данная проблема заключается в том, что при внесении изменений в одну из частей проекта необходимо оповещать всех разработчиков, которые использовали или могли использовать эту часть в своей работе. Когда система состоит из большого количества взаимосвязанных подсистем, то синхронизация внутренней документации становится важной самостоятельной задачей. Причем синхронизация документации на каждую часть системы – это не более чем процесс оповещения групп разработчиков. Самим же разработчикам необходимо ознакомиться с изменениями и оценить, не сказались ли эти изменения, на уже полученных результатах. Все это может потребовать проведения повторного тестирования, и даже внесения изменений в уже готовые части проекта. Причем эти изменения, в свою очередь, должны быть отражены во внутренней документации и разосланы другим группам разработчиков. Как следствие, объем документации по мере разработки проекта растет очень быстро, так что требуется все больше времени для составления документации и ознакомления с ней. Следует также отметить, что, кроме изучения нового материала, не отпадает и необходимость в изучении старой информации. Это связано с тем, что вполне вероятна ситуация, когда в процессе выполнения разработки изменяется состав группы разработчиков (этот процесс носит название ротации кадров). Новым разработчикам необходима информация о том, что было сделано до них. Причем чем сложнее проект, тем больше времени требуется, чтобы ввести нового разработчика в курс дела. Сложность управления проектом при использовании каскадной схемы в основном обусловлена строгой последовательностью стадий разработки и наличием сложных взаимосвязей между различными частями проекта. Последовательность разработки проекта приводит к тому, что одни группы разработчиков должны ожидать результатов работы других команд. Поэтому требуется административное вмешательство для того, чтобы согласовать сроки работы и состав передаваемой документации. В случае же обнаружения ошибок в выполненной работе необходим возврат к предыдущим этапам выполнения проекта. Это приводит к дополнительным сложностям в управлении проектом. Разработчики, допустившие просчет или ошибку, вынуждены прервать текущую работу (над новым проектом) и заняться исправлением ошибок. Следствием этого обычно является срыв сроков выполнения как исправляемого, так и нового проектов. Требовать же от команды разработчиков ожидания окончания следующей стадии разработки нерационально, так как приводит к существенным потерям рабочего времени. Упростить взаимодействие между группами разработчиков и уменьшить информационную перенасыщенность документации можно, уменьшая количество связей между отдельными частями проекта. Однако это обычно весьма непросто. Далеко не каждую информационную систему можно разделить на несколько слабосвязанных подсистем. Высокий уровень риска. Чем сложнее проект, тем больше продолжительность каждого из этапов разработки и тем сложнее взаимосвязи между отдельными частями проекта, количество которых также увеличивается. Причем результаты разработки можно реально увидеть и оценить лишь на этапе тестирования, то есть после завершения анализа, проектирования и разработки – этапов, выполнение которых требует значительного времени и средств. Как уже было отмечено выше, запоздалая оценка создает значительные проблемы при выявлении ошибок анализа и проектирования – требуется возврат проекта на предыдущие стадии и повторение процесса разработки. Однако возврат на предыдущие стадии может быть связан не только с ошибками, но и с изменениями, произошедшими за время выполнения разработки в предметной области или в требованиях заказчика. Причем возврат проекта вследствие этих причин на доработку не гарантирует, что предметная область снова не изменится к тому моменту, когда будет готова следующая версия проекта. Фактически это означает, что существует вероятность того, что процесс разработки «зациклится» и никогда не дойдет до сдачи в эксплуатацию. Расходы на проект будут постоянно расти, а сроки сдачи готового продукта – постоянно откладываться. Поэтому можно утверждать, что сложные проекты, разрабатываемые по каскадной схеме, имеют повышенный уровень риска. 5. Спиральная модель жизненного цикла Спиральная модель, в отличие от каскадной, предполагает итерационный процесс разработки информационной системы. При этом возрастает значение начальных этапов жизненного цикла, таких как анализ и проектирование. На этих этапах проверяется и обосновывается реализуемость технических решений путем создания прототипов. 1. Итерации Каждая итерация представляет собой законченный цикл разработки, приводящий к выпуску внутренней или внешней версии изделия (или подмножества конечного продукта), которое совершенствуется от итерации к итерации, чтобы стать законченной системой (рис. 10). Проектирование Анализ Формулирование требований 90 Версия 1 Разработка Версия 2 Версия 3 Интеграция Рис. 10 – Итерации Таким образом, каждый виток спирали соответствует созданию фрагмента или версии программного изделия, на нем уточняются цели и характеристики проекта, определяется его качество, планируются работы следующего витка спирали. На каждой итерации углубляются и последовательно конкретизируются детали проекта, в результате чего выбирается обоснованный вариант, который доводится до окончательной реализации. Использование спиральной модели позволяет осуществлять переход на следующий этап выполнения проекта, не дожидаясь полного завершения работы на текущем – недоделанную работу можно будет выполнить на следующей итерации. Главная задача каждой итерации – как можно быстрее создать работоспособный продукт, который можно показать пользователям системы. Таким образом, существенно упрощается процесс внесения уточнений и дополнений в проект. 2. Преимущества спиральной модели Спиральный подход к разработке программного обеспечения позволяет преодолеть большинство недостатков каскадной модели и, кроме того, обеспечивает ряд дополнительных возможностей, делая процесс разработки более гибким. Рассмотрим преимущества итерационного подхода более подробно: - итерационная разработка существенно упрощает внесение изменений в проект при изменении требований заказчика; - при использовании спиральной модели отдельные элементы информационной системы интегрируются в единое целое постепенно. При итерационном подходе интеграция производится фактически непрерывно. Поскольку интеграция начинается с меньшего количества элементов, то возникает гораздо меньше проблем при ее проведении (по некоторым оценкам, при использовании каскадной модели разработки интеграция занимает до 40% всех затрат в конце проекта); - уменьшение уровня рисков. Данное преимущество является следствием предыдущего, так как риски обнаруживаются именно во время интеграции. Поэтому уровень рисков максимален в начале разработки проекта. По мере продвижения разработки ожидаемый риск уменьшается. Данное утверждение справедливо при любой модели разработки, однако при использовании спиральной модели уменьшение уровня рисков происходит с наибольшей скоростью. Это связано с тем, что при итерационном подходе интеграция выполняется уже на первой итерации и при выполнении начальных итераций выявляются многие аспекты проекта, такие как пригодность используемых инструментальных средств и программного обеспечения, квалификация разработчиков и т. п. На рис. 11 приведены в сравнении графики зависимости уровня рисков от времени разработки при использовании каскадного и итерационного подходов; - итерационная разработка обеспечивает большую гибкость в управлении проектом, давая возможность внесения тактических изменений в разрабатываемое изделие. Например, можно сократить сроки разработки за счет уменьшения функциональности системы или использовать в качестве составных частей системы продукцию сторонних фирм вместо собственных разработок. Это может быть актуальным в условиях конкурентной борьбы, когда необходимо противостоять продвижению изделия, предлагаемого конкурентами; Риски Спиральная модель Каскадная модель Время Рис. 11 – Зависимость рисков от времени разработки - итерационный подход упрощает повторное использование компонентов (позволяет использовать компонентный подход к программированию – более подробно об этом мы будем говорить в следующей главе). Это обусловлено тем, что гораздо проще выявить (идентифицировать) общие части проекта, когда они уже частично разработаны, чем пытаться выделить их в самом начале проекта. Анализ проекта после проведения нескольких начальных итераций позволяет выявить общие, многократно используемые компоненты, которые на последующих итерациях будут совершенствоваться; - спиральная модель позволяет получить более надежную и устойчивую систему. Это связано с тем, что по мере развития системы ошибки и слабые места обнаруживаются и исправляются на каждой итерации. Одновременно могут корректироваться критические параметры эффективности, что при использовании каскадной модели выполняется только перед внедрением системы; - итерационный подход позволяет совершенствовать процесс разработки – анализ, проводимый в конце каждой итерации, позволяет проводить оценку того, что должно быть изменено в организации разработки, и улучшить ее на следующей итерации. 3. Проблемы, возникающие при использовании спиральной модели Основная проблема спирального цикла – определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Иначе процесс разработки может превратиться бесконечное совершенствование уже сделанного. При итерационном подходе полезно следовать принципу «лучшее – враг хорошего». Поэтому завершение итерации должно производиться строго в соответствии с планом, даже если не вся запланированная работа закончена. Планирование работ обычно проводится на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков. В следующем пункте будет рассмотрен один из важнейших этапов, входящий во все модели жизненных циклов – управление требованиями. 6. Введение в управление требованиями В настоящее время разработка информационных систем является жизненно важной составляющей мировой экономики. Постоянно развивающийся в условиях конкуренции бизнес требует от компаний снижения стоимости продукции и услуг, а также выпуска их на рынок в конкурентоспособные сроки. Для удовлетворения подобных потребностей компании вынуждены автоматизировать свои бизнес-процессы с помощью информационных систем. Информационные системы по своей природе являются неосязаемыми, абстрактными, сложными, постоянно изменяемыми, и не случайно многие проекты по их созданию заканчиваются неудачей. По исследованиям Standish Group более половины проектов по разработке информационных систем значительно превысили отведенное на них время и бюджет, а треть проектов было прекращено. Причиной краха наибольшей части проектов по созданию информационных систем являются неполные требования к программному обеспечению и их спецификации, а также неконтролируемые изменения требований в процессе создания системы. По данным исследовательской организации Standish Group покали, что 31% проектов будет прекращен до завершения. Затраты на 52,7 % проектов составляют 189% от первоначальной оценки. Исходя из этого, исследователи Standish Group показали, что американские компании и правительственные учреждения потратят 81 миллиард долларов на программные проекты, которые так и не будут завершены. Эти же организации заплатят дополнительно 59 миллиардов долларов за программные проекты, которые хотя и завершатся, но значительно превысят первоначально отведенное на них время. К наиболее часто встречающимся факторам, создающим «проблемы» в программных проектах, относятся следующие: Недостаток исходной информации от клиента: 13% проектов Неполные требования и документы требований: 12% проектов Изменение требований и документов требований: 12% проектов. Несоответствия технологических навыков: 7% проектов Неправильный подбор персонала и выделение ресурсов: 6% проектов Нереалистичное составление графиков и планирование времени: 4% проектов Другое Напротив, наиболее важными факторами успеха проектов были выделены следующие: Подключение к разработке пользователей: 16% успешных проектов Поддержка со стороны исполнительного руководства: 14 % Ясная постановка требований: 12% Исследования Standish Group показали, что наибольшее количество ошибок происходит на этапе сбора, анализа и документирования требований. Доля ошибок в различных артефактах при разработке ПО представлена на рисунке 1. Рис. 1 – Доля ошибок в различных артефактах при разработке ПО Вследствие ошибок на разных этапах разработки ПО приходится затрачивать 30–50% средств от общего бюджета проекта на их исправление. Причем 70–85% от общего числа исправлений связанно именно с ошибками, допущенными на этапе сбора, анализа и документирования требований. Наибольшее количество ошибок в требованиях происходит из-за следующих факторов: Не выявлены требования – 12,8% Не четко сформулированы требования – 12,3% Изменения требований – 11,8% Резюмируя, можно сделать вывод, что ошибка, допущенная в самом начале проекта (на этапе сбора, анализа и документирования требований), обходится в 200 раз дороже при внедрении и сдаче ПО. Следовательно, руководители организаций должны очень тщательно относиться к одному из основополагающих процессов разработки ПО – сбору, анализу и документированию требований, усовершенствуя данный процесс внутри организации. Управление требованиями является важной частью процесса разработки программного обеспечения. Хорошо отлаженный процесс управления требованиями определяет эффективность и скорость создания системы. Это особенно важно для тех отраслей, где время создания продукта и степень удовлетворения требований заказчика являются ключевыми факторами успеха. В управлении требованиями присутствует значительная организационная составляющая, которая помогает с помощью требований управлять всем проектом, определяя его сроки, бюджет, ресурсы и технологии. Процесс разработки и управления требованиями к программному обеспечению определяет сбор, анализ, документирование требований в соответствии с заранее определенными планами, методами и характеристиками качества требований. Данный процесс позволяет также отслеживать и управлять изменениями требований, что существенно при меняющихся условиях рынка. 7. Основы управления требованиями Устав проекта — документ, отражающий ключевые сведения о проекте, разрабатываемый в ходе подготовки проекта. Задачи данного документа — сформировать единое представление о проекте у всех участников и формализовать достигнутые договоренности. Для повышения вероятности разделяемой ответственности, приемки результатов проекта, а также удовлетворения заказчиков и других заинтересованных сторон проекта их необходимо привлекать в процессы инициации проекта. В Уставе проекта документируются первоначальные требования к проекту, удовлетворяющие потребностям и ожиданиям заинтересованных сторон. Базовая (первая) версия Устава проекта утверждается ответственным за его утверждение лицом и является признанием того, что работы по проекту могут быть начаты. Все изменения, касающиеся целей проекта, согласовываются с Заказчиком (и/или) Инвестором проекта и обязательно вносятся в Устав проекта. В рамках процессов инициации менеджер проекта получает полномочия применять ресурсы организации для последующих работ проекта. Устав проекта документирует бизнес-потребности, текущее понимание потребностей заказчика, а также новый продукт, услугу или результат, который планируется создать, например: назначение или обоснование проекта; измеримые цели проекта и соответствующие критерии успеха; требования высокого уровня; описание проекта высокого уровня; риски высокого уровня; сводное расписание контрольных событий; сводный бюджет; требования к одобрению проекта (что составляет успех проекта, кто решает, что проект оказался успешным, и кто подписывает проект); назначенный менеджер проекта, уровень ответственности и полномочий; имя и полномочия спонсора или другого лица (лиц), утверждающего Устав проекта За подготовку и внесение изменений в Устав проекта в компании необходимо назначить ответственное лицо. Изменения в Устав проекта должны вноситься в следующих случаях: произошли изменения в параметрах проекта (сроки, содержание, бюджет, качество); произошли изменения в требованиях Заказчика (и/или) Инвестора проекта; произошли изменения в параметрах продукта проекта; произошли изменения во внутренних/внешних условиях проекта. Изменения в Устав проекта должны быть оформлены соответствующим образом, а внесение изменений в Устав проекта должны быть санкционированы Руководителем проекта. 8. Определение требования IEEE Standard Glossary of Software Engineering Terminology определяет требования как: 1. Условия или возможности, необходимые пользователю для решения проблем или достижения целей; 2. Условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетворять стандартам, спецификациям или другим формальным документам; 3. Документированное представление условий или возможностей для пунктов 1 и 2. Это определение охватывает требования как пользователей (внешнее поведение системы), так и разработчиков (некоторые скрытые параметры). Термин пользователи следует распространить на всех заинтересованных лиц, так как не все, кто заинтересован в проекте — пользователи. 9. Уровни требований Требования к ПО состоят из трех уровней — бизнес-требования, требования пользователей и функциональные требования. Вдобавок каждая система имеет свои нефункциональные требования. Модель на рис. 2 иллюстрирует способ представления этих типов требований. Как и все модели, она не полная, но схематично показывает организацию требований. Овалы обозначают типы информации для требований, а прямоугольники — способ хранения информации (документы, диаграммы, базы данных). Бизнес-требования (business requirements) содержат высокоуровневые цели организации или заказчиков системы. Как правило, их высказывают те, кто финансируют проект, покупатели системы, менеджер реальных пользователей, отдел маркетинга или «провидец» продукта. В этом документе объясняется, почему организации нужна такая система, то есть описаны цели, которые организация намерена достичь с ее помощью. Бизнес-требования принято записывать в форме документа об образе и границах проекта, который еще иногда называют уставом проекта (project charter) или документом рыночных требований (market requirements document). Создание такого документа будет описано далее. Требования пользователей (user requirements) описывают цели и задачи, которые пользователям позволит решить система. К отличным способам представления этого вида требований относятся варианты использования, сценарии и таблицы «событие - отклик». Таким образом, в этом документе указано, что клиенты смогут делать с помощью системы. Пример варианта использования — «Сделать заказ» для заказа билетов на самолет, аренды автомобиля, заказа гостиницы через Интернет. Функциональные требования (functional requirements) определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда именуемые требованиями поведения (behavioral requirements), они содержат положения с традиционным «должен» или «должна»: «Система должна по электронной почте отправлять пользователю подтверждение о заказе». Рис. 2 – Взаимосвязи нескольких типов информации для требований Термином системные требования (system requirements) обозначают высокоуровневые требования к продукту, которые содержат многие подсистемы, то есть система. Говоря о системе, мы подразумеваем программное обеспечение или подсистемы ПО и оборудования. Люди — часть системы, поэтому определенные функции системы могут распространиться и на людей. Функциональные требования документируются в спецификации требований к ПО (software requirements specification, SRS), где описывается так полно, как необходимо, ожидаемое поведение системы. Спецификация может быть представлена в виде документа, базы данных, крупноформатной таблицы с требованиями, хранилища данных в коммерческом инструменте управления требованиями. Спецификация требований к ПО используется при разработке, тестировании, гарантии качества продукта, управлении проектом и связанных с проектом функциях.. В дополнение к функциональным требованиям спецификация содержит нефункциональные, где описаны цели и атрибуты качества. Атрибуты качества (quality attributes) представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся легкость и простота использования, легкость перемещения, целостность, эффективность и устойчивость к сбоям. Другие нефункциональные требования описывают внешние взаимодействия между системой и внешним миром, а также ограничения проектирования и реализации. Ограничения (constraints) касаются выбора возможности разработки внешнего вида и структуры продукта. Люди часто рассуждают о характеристиках продукта. Характеристика (feature) — это набор логически связанных функциональных требований, которые обеспечивают возможности пользователя и удовлетворяют бизнесцели. В области коммерческого ПО характеристика представляет собой узнаваемую всеми заинтересованными лицами группу требований, которые важны при принятии решения о покупке — элемент маркированного списка в описании продукта. Характеристики продукта, которые перечисляет клиент, не эквивалентны тем, что входят в список необходимых для решения задач пользователей. В качестве примеров характеристик продуктов можно привести избранные страницы или закладки Web-браузера, контроль за орфографией, запись макрокоманды, сервопривод стекла в автомобиле, on-line- обновление или изменение налогового кодекса, ускоренный набор телефонного номера или автоматическое определение вируса. Характеристики могут охватывать множество вариантов использования, и для каждого варианта необходимо, чтобы множество функциональных требований было реализовано для выполнения пользователем его задач. Для лучшего восприятия различных видов требований, рассмотрим программу подготовки текстов. Бизнес-требование может выглядеть так: «Продукт позволит пользователям исправлять орфографические ошибки в тексте эффективно». На коробке CD-ROM указано, что проверка грамматики включена как характеристика, удовлетворяющая бизнес-требование. Соответствующие требования пользователей могут содержать задачи (варианты использования) вроде такой: «Найдите орфографическую ошибку» или «Добавьте слово в общий словарь». Проверка грамматики имеет множество индивидуальных функциональных требований, которые связаны с такими операциями, как поиск и выделение слова с ошибкой, отображение диалогового окна с фрагментом текста, где это слово находится, и замена слова с ошибкой корректным вариантом по всему тексту. Атрибут качества легкость и простота использования (usability) как раз и определяет его значение посредством слова «эффективно» в бизнес-требованиях. Менеджеры и сотрудники отдела маркетинга определяют бизнестребования для ПО, которые помогут их компании работать эффективнее (для информационных систем) или успешно конкурировать на рынке (для коммерческих продуктов). Каждое требование пользователя должно быть сопоставлено бизнес-требованию. На основе требований пользователя аналитики определяют функции, которые позволят пользователям выполнять их задачи. Разработчикам необходимы функциональные и нефункциональные требования, чтобы создавать решения с желаемой функциональностью, определенным качеством и требуемыми рабочими характеристиками, не выходя за рамки налагаемых ограничений. Хотя в модели на рис. 2 показан поток требований в направлении сверху вниз, следует ожидать и циклов, и итераций между бизнес-требованиями, требованиями пользователей и функциональными требованиями. Кто бы, когда бы ни предложил новые характеристики, варианты использования или функциональные требования, аналитик должен спросить; «Они попадают в указанные границы?» Если ответ «да», то они соответствуют спецификации. Если — «нет», то на «нет», как известно, и суда нет. А вот если ответ «нет, но они должны там быть», то заказчик или тот, кто финансирует проект, должен решить, готов ли он раздвинуть границы проекта, чтобы принять новое требование. 10.Разработка и управление требованиями Управление требованиями (requirements management) делится на разработку требований (requirements development) и управление требованиями (requirements management) (Рис.3). Рис.3 – Компоненты области разработки технических условий Разработка требований Далее можно подразделить этот этап на извлечение (elicitation), анализ (analysis), документирование (specification) и утверждение (validation). В эти подэтапы входят все действия, включающие сбор, оценку и документирование требований для ПО или ПО-содержащих продуктов, в том числе: идентификация классов пользователей для данного продукта; выяснение потребностей тех, кто представляет каждый класс пользователей; определение задач и целей пользователей, а также бизнес-целей, с которыми эти задачи связаны; анализ информации, полученной от пользователей, чтобы отделить задачи от функциональных и нефункциональных требований, бизнес правил, предполагаемых решений и поступающих извне данных; распределение высокоуровневых требований по компонентам: к определенным в системной архитектуре; установление относительной важности атрибутов качества; установление приоритетов реализации; документирование собранной информации и построение моделей; просмотр спецификации требований, который позволяет удостовериться в том, что запросы пользователей всеми понимаются одинаково, и устранение возникших проблем до передачи документа разработчикам. Управление требованиями Этот этап определяется как «выработка и поддержание взаимного согласия с заказчиками по поводу требований к разрабатываемому ПО». Это соглашение воплощается в спецификации (в письменной форме) и моделях. Одобрение пользователей — только половина дела. Разработчики также должны принять задокументированные требования и высказаться за создание этого продукта. К действиям по управлению требованиями относятся: определение основной версии требований (моментальный срез требований для конкретной версии продукта); просмотр предлагаемых изменений требований и оценка вероятности воздействия каждого изменения до его принятия; включение одобренных изменений требований в проект установленным способом; согласование плана проекта с требованиями; обсуждение новых обязательств, основанных на оцененном влиянии изменения требований; отслеживание отдельных требований до их дизайна, исходного кода и вариантов тестирования; отслеживание статуса требований и действий по изменению на протяжении всего проекта. Основные шаги процесса управления требованиями На рисунке 4 изображена структурная схема процесса управления требованиями с декомпозицией на основные шаги. Рис. 4 – Шаги процесса управления требованиями Каждый представленный выше шаг в процессе управления может повторяться множество раз, причем, переходы от шага к шагу могут быть прямыми и обратными. Обратная связь позволяет уточнять, дорабатывать и корректировать требования. Процесс управления требованиями приведен на рисунке 5: Рис. 5 – Процесс управления требованиями Далее будут подробно рассмотрены этапы процесса. 11. Планирование процесса Процесс управления требования начинается с планирования. На этапе планирования системный аналитик создает план управления требованиями и шаблоны необходимой документации. Планирование – первый шаг при работе с требованиями, он начинается на этапе предпроектного обследования. План управления требованиями является одним из наиболее важных документов в процессе управления требованиями. В данном документе определяются типы требований и атрибуты каждого типа, отношения между требованиями, документы, использующиеся в данном процессе. Также системный аналитик определяет и заносит в план решение об использовании специального инструментального средства для управления требованиями. Расширенный вариант плана управления требованиями может содержать описание ролей, участвующих в процессе; задач, выполняемых каждой ролью, и другую служебную информацию. Как было сказано выше, на этапе планирования также создаются шаблоны необходимых документов: глоссария, технического задания, документаконцепции. При работе с государственным заказчиком для описания требований чаще всего используется техническое задание, разработанное в соответствие с ГОСТ 34.602-89 или ГОСТ 19.201-78. Если нет жестких требований со стороны заказчика на соответствие государственным стандартам, можно использовать спецификацию требований на основе стандарта IEEE 830-1998. Современные инструментальные средства позволяют создавать автоматические отчеты с необходимой информацией. Если принято решение о том, что документация будет создаваться автоматически с использованием отчетов, на этапе планирования необходимо создать шаблоны таких отчетов. Шаблоны отчетов, также как и шаблоны документов, должны быть разработаны с учетов требований государственных стандартов. 12. Выявление требований Выявление требований является самой сложной задачей в процессе управления требованиями. От того насколько полно собраны требования, зависит реализация проекта и последующее удовлетворение заказчика. Часто на практике заказчики и пользователи информационной системы отдалены от команды разработчиков, что вызывает трудности при выявлении требований. Однако, кроме заказчиков и пользователей, существуют и другие источники требований: документы, описывающие существующие или конкурирующие продукты; существующие спецификации требований к системе; отчеты об ошибках и запросы от пользователей по совершенствованию системы; результаты маркетинговых исследований; существующая документация с описанием процессов деятельности заказчика и др. Первой задачей при выявлении требований является определение пользователей информационной системы, которые будут работать с системой, и если не учесть их потребностей, конечный продукт может потерпеть неудачу. При коммуникациях с конечными пользователями аналитик должен определить задачи, которые необходимо решать пользователям с помощью разрабатываемой системы, а также характеристики качества, определяющие то, как пользователи хотят выполнять свои задачи. Методы выявления требований В своей практике аналитики используют большое количество различных методов по выявлению требований. Для того, чтобы собрать наиболее полные требования рекомендуется по возможности использовать сразу несколько методов. Ниже представлен список основных методов выявления требований: интервьюирование и анкетирование, проведение семинаров, мозговой штурм, работа в фокус-группе, создание прототипов системы, варианты использования, анализ существующей документации, анализ интерфейсов (программных и аппаратных), анализ структуры программного обеспечения по коду (reverse engineering). Выбор конкретного метода зависит от характера разрабатываемого приложения, опыта и уровня подготовки проектной команды, заказчика и других факторов. Интервью Интервью является основным способом получения требований от заказчика и пользователя информационной системы. В данной работе я не буду приводить примеры опросников и рекомендации о том, как проводить интервью. Тема интервьюирования затронута во многих книгах по управлению требованиями. Стоит отметить основные правила, которые необходимо помнить во время и после интервью: Аналитик должен быть компетентен в предметной области заказчика; Во время интервью аналитик должен сосредоточиться на проблеме; Аналитик должен задавать открытые вопросы, которые предполагают развернутый ответ; Аналитик может предлагать свои идеи на счет разрабатываемой системы; Аналитик должен выяснить ожидания интервьюируемых (что, если…); Аналитик должен протоколировать результаты интервью. Также стоит отметить, что до проведения интервью должна быть определена его цель и идентифицированы кандидаты на проведение интервью. Семинары требований В результате интервью могут появиться нерешенные вопросы. Для решения подобных вопросов и обсуждение требований проводятся специальные семинары. Как правило, на семинары приглашаются представители заказчика и члены проектной команды. При проведении семинара рекомендуется обсуждать только вынесенные в программу вопросы, придерживаться темы обсуждения и работать на одном уровне абстракции. Уровень абстракции означает, например, то, что если обсуждаются концептуальные вопросы не стоит углубляться в детали реализации. Семинар также удобен для определения цели разрабатываемой системы, приоритетов требований, сроков реализации требований. На семинаре могут проводится мозговые штурмы для генерации новых идей и ключевых возможностей системы. Мозговой штурм Мозговой штурм является превосходным способом поиска новых идей для разрабатываемой системы и ее предметной области. Цель мозгового штурма сфокусироваться на проблеме и предложить определенное количество радикальных идей по решению данной проблемы. Фокус-группа В отличие от семинара, фокус группа собирается для решения определенной проблемы, как правило, по взаимодействию различных подсистем разрабатываемой системы. При разработке крупномасштабных информационных систем, отдельные подсистемы могут разрабатывать различные команды разработчиков (часто удаленные друг от друга на расстоянии). Для определения правил взаимодействия подсистем, формулирования требований к программным и аппаратным интерфейсам удобно собирать представителей различных команд в фокус группы. Решение проблем взаимодействия подсистем и разнесение ответственности между командами позволит создавать подсистемы, которые будут легко интегрироваться друг с другом. Прототипирование Программные прототипы, как начальное воплощение информационной системы, демонстрирует часть функциональности будущей системы. Работая с прототипом системы пользователь, может высказывать предположения, недочеты, которые будут оформляться в виде требований к программному продукту. Каждый прототип должен иметь определенную цель создания, например, реализация функции, представление внешнего вида программы, тестирование варианта архитектуры системы. Существует большое количество разновидностей прототипов. Наиболее используемыми являются «горизонтальный» и «вертикальный» прототипы. Горизонтальный прототип представляет собой изображения пользовательских интерфейсов, которые демонстрируют пользователю внешний вид будущей системы и характеризуют методы работы с системой. Выполнение задач может быть представлено последовательностью сменяющих друг друга пользовательских графических интерфейсов. Горизонтальные прототипы позволяют исследовать поведение системы в различных ситуациях: обработке ошибок, разветвление потоков задач и др. Вертикальный прототип предназначен для проверки определенной функциональности системы и исследования критически важных требований к интерфейсу, времени выполнения. Вертикальный прототип является законченной реализацией части будущей системы. С помощью вертикальных прототипов можно проверить удовлетворяет ли разработанная системная архитектура требованиям характеристик качества, произвести нагрузочное тестирование приложения. Варианты использования Вариант использования (use case) является мощным инструментом описания требований к системе с точки зрения пользователей. Пользовательские требования записываются в виде модели вариантов использования, которая содержит описание внешних по отношению к системе действующих лиц и их взаимодействие с разрабатываемой системой. На рисунке 6 приведена диаграмма вариантов использования информационной системы для библиотеки в нотации UML: Рис. 6 – Диаграмма вариантов использования Действующее лицо (actor) – это некто или нечто, внешнее по отношении к системе и взаимодействующее с системой для достижения определенной цели. К действующим лицам относятся: роли пользователей системы (кто вводит и использует информацию, кто заинтересован в выполнении требования, кто администрирует систему); внешнее оборудование, работающее с системой; другие системы. На диаграммах вариантов использования действующее лицо представляется в виде фигурки человека. Вариант использования представляет собой общую спецификацию совокупности выполняемой системой действий с целью предоставления некоторого наблюдаемого результата, который имеет значение для одного или нескольких действующих лиц. Вариант использования изображается в виде овала. Для того, чтобы показать какое действующее лицо инициирует вариант использования, применяются ассоциации, направленные от действующего лица к варианту использования. Варианты использования может иметь от одного до нескольких сценариев, описывающих шаги взаимодействия системы с пользователем или другой системой. Сценарий варианта использования может быть описан в текстовой форме или с помощью диаграмм деятельности. Описание требований в виде сценария варианта использования помогает аналитику: обнаружить неточности и неясности требований на ранних этапах разработки, понять деятельность пользователей, их предметную область, выявить объекты предметной области и понять их взаимоотношения. Варианты использования являются мощным инструментом в разработке программного обеспечения. Почти все существующие на сегодняшний день методологии разработки программного обеспечения основаны на вариантах использования. Пример диаграммы деятельности для варианта использования «Регистрация читателя» приведен на рисунке 7: Рис. 7 – Диаграмма деятельности Диаграммы деятельности описывает поток событий варианта использования. Варианты использования можно применять для описания бизнес-процессов, а диаграммы деятельности для описания задач и подпроцессов описываемого бизнес-процесса. На этапе формирования требований описывается только взаимодействие между действующим лицом и системой, т.е. система рассматривается как черный ящик. Проблемы, возникающие при выявлении требований Проблемы классификации требований Сложной задачей при выявлении требований является идентификация их типов. На практике, особенно при проведении интервью, требования формулируемые пользователем могут относиться к различным типам требований. Помимо классификации требований, к основным проблемам при выявлении требований относятся проблемы формулировки требований, терминологии и предвзятых решений. Проблемы формулировки требований Во время интервью многие пользователи и заказчики системы сталкиваются с проблемой объяснения выполняемых задач аналитику. Они помнят исключения и забывают порядок действий, забывают рассказать о простых на их взгляд задачах. Данная ситуация может привести к тому, что один и тот же процесс будет описан по-разному несколькими пользователями, что введет в заблуждение остальных и создаст ложное единое мнение. Для решения подобной проблемы, аналитик может наблюдать за работой пользователя и документировать все действия, выполняемые пользователем в его повседневной работе, или попросить пользователя самостоятельно документировать все выполняемые действия. Терминология В процессе разработки системы заказчики и пользователи выражаются с использованием терминологии, являющейся специфичной для их предметной области. Разработчики программного продукта должны понимать терминологию заказчика, для этого аналитик должен собирать термины предметной области заказчика и документировать их в глоссарии. Глоссарий терминов позволит не только понять требования пользователей, но и разобраться в предметной области разрабатываемой системы. Предвзятые решения Иногда заказчики и пользователи считают, что сами знают решение проблем их деятельности, вместо описания проблемы они высказывают идею решения этой проблемы, которая могут быть неоптимальными или просто ошибочными. Для решения данной проблемы необходимо анализировать причины, т.е. определять, почему пользователи хотят иметь некоторою функциональность системы, действительно она нужна или является субъективным желанием пользователя. 13. Анализ требований Стадия выявление требований является расходящимся процессом, которая нацелена на сбор большого количества информации. После выявления требований, аналитик имеет большое количество различной информации, полученной на интервью, при обследовании, из анкет и других источников. Полученную информацию необходимо уточнить, структурировать, исключить дублирование, сформулировать в виде требований и определить их приоритеты. Эти задачи решает стадия анализа требований. Целью анализа требований является получение понятных и непротиворечивых требований, на основе которых можно проектировать и реализовывать программное приложение. На данной стадии создаются модели требований, определяются недостающая информация, требования уточняются и для каждого требования задаются значения его атрибутов. Уточнение требований Во время анализа требований может возникнуть ситуация, когда собранные требования являются неполными или одно требование противоречит другому. В данной ситуации аналитик должен снова взаимодействовать с заказчиком, уточнять непонятные моменты, фиксировать все, что необходимо разработчикам и проектировщикам для реализации данных требований. Структуризация требований Целью структуризации требований является определение границ системы, декомпозиция и разнесение требований по функциональным областям предметной области. Для определения границ системы аналитик должен идентифицировать роли пользователей, которые будут работать с системой, и внешние системы, которые будут взаимодействовать с разрабатываемой системой, определить потоки входной и выходной информации. Для структурирования требований по функциональным областям применяются пакеты (каталоги) требований. Пакеты могут объединять требования по разным признакам: требования, принадлежащие одному типу, например, все бизнес требования. требования, связанные с конкретным пользователем или действующим лицом требования, принадлежащие к одной функциональной подобласти предметной области. Например, пакет Поиск может содержать все требования, относящиеся к поиску информации. Пакеты могут быть вложенными друг в друга, что позволяет создавать древовидную структуру требований. Помимо структуризации требований по пакетам, применяется декомпозиция требований. Декомпозиция требований позволяет разбивать требования на более детальные. Каждое родительское требование может иметь несколько дочерних требований, а одно дочернее требование принадлежать только одному родителю. Приоритеты Определение приоритетов требований является важной частью анализа, потому что приоритеты характеризуют важность требования и сроки их реализации. В определении приоритетов должно участвовать заказчики, пользователи и разработчики. Заказчики и пользователи определяют важную функциональность, которую они хотят получить в первую очередь и согласовывают ее разработчики. С помощью приоритетов можно планировать этапы разработки, релизы программного обеспечения. Наиболее важные требования реализуются и проверяются в первую очередь. Приоритет является одним из атрибутов требования, и поэтому аналитик определяет набор значений приоритета во время создания плана управления требованиями. Обычно на практике, используется три значения для приоритета: высокий, средний и низкий. Модели требований Требования удобно анализировать и описывать с помощью моделей требований. Существует множество методов, предназначенных для анализа требований и построения графических моделей требований. К наиболее используемым относятся методы анализа бизнес-процессов, объектноориентированного анализа и структурного анализа. При анализе бизнес процессов заказчика аналитик строит графические диаграммы процессов с описанием задач, бизнес - сущностей, должностных лиц, участвующих в процессе, определяет потоки данных, строит логическую модель данных предметной области. Бизнес моделирование позволяет аналитику разобраться в структуре и динамике организации заказчика, а также удостовериться в том, что заказчики, пользователи и разработчики имеют одинаковое понимание деятельности организации. При моделировании бизнеспроцессов можно использовать различные методологии проектирования: BPMN,UML, IDEF. Структурный анализ позволяет декомпозировать бизнес процессы на необходимое количество уровней. Каждый последующий уровень может быть представлен в виде отдельного шага бизнес-процесса, как представлено на). Углубляясь внутрь бизнес-процесса, можно прийти к элементарным действиям, которые могут быть реализованы в виде системных функций. Методология структурного анализа была ориентирована на структурные языки программирования, такие как Паскаль, и поэтому ее сложно применять для разработки систем с использованием объектно-ориентированных языков программирования. Для моделирования объектно-ориентированных систем используется методология объектно-ориентированного анализа и проектирования (ООАП), применяющая нотацию UML. Для описания и моделирования требований используются почти все диаграммы UML. Диаграмма вариантов использования описывает пользователей систем, пользовательские требования и границы разрабатываемой системы. Диаграмма деятельности позволяет описать последовательность действий пользователя при взаимодействии с системой и отклики системы. Также с ее помощью можно описывать бизнес процессы заказчика. На диаграмме классов изображаются основные сущности предметной области и их отношения. Весьма полезна так называемая системная диаграмма последовательностей, позволяющая идентифицировать системные события (приходящие извне) и соответственно системные операции, которые потом будут реализованы в виде операций и методов классов или их совокупности. Подход на основе моделей (MDA) позволяет описывать требования и архитектуру программной систему с помощью моделей, представленных в нотации UML, и является альтернативой текстового описания требований. Современные CASE средства, поддерживающие MDA, позволяют автоматически генерировать программный код из моделей системы. 14. Документирование требований Параллельно с процессом анализа требования описываются в проектной документации. Как говорилось ранее, требования могут документироваться при помощи текстового описания или в виде графических диаграмм. К основным документам, описывающим требования, относятся глоссарий, документконцепция и спецификация требований. Глоссарий Глоссарий (Glossary) представляет собой документ, описывающий все основные определения, встречающиеся в проекте. Сосредоточение определений в одном документе позволяет отслеживать изменения определений, добавление новых и удаление старых определений. Глоссарием могут пользоваться все участники проекта по разработке программного обеспечения: аналитики, разработчики, системные архитекторы, инженеры по тестированию и заказчики. В основном глоссарий содержит определения предметной области и дает участникам проекта возможность понимания предметной области. Также глоссарий позволяет участникам проекта разговаривать на «одном» языке. За ведение глоссария обычно отвечает системный аналитик. Спецификация требований Спецификация требований (Software Requirements Specification) используется для документирования требований к разрабатываемой системе или части системы. В спецификацию требований должна попадать информация о границах системы, выполняемых функциях, характеристиках качества, ограничениях и распределении приоритетов. В зависимости от заказчика, специфики проекта, применяемых методологий и процессов разработки спецификация требований может различаться по своему составу и структуре. В отечественных стандартах по разработке программного обеспечения, аналогом спецификации требований является техническое задание на разработку системы. Спецификация требований является фундаментальным документом, потому что на ее основе осуществляется планирование, проектирование и реализация проекта, разработка сценариев тестирование и пользовательской документации. Наличие спецификации требования, утвержденной заказчиком, позволяет снизить риски, связанные с разработкой, а именно: риск разного понимания требований разными участниками разработки; риск разработки программного обеспечения, не отвечающего потребностям заказчика; риск ошибочной оценки трудоемкости работ; риск смены команды разработчиков. 15. Проверка требований После того, как требования собраны и задокументированы, необходимо проверить качество требований и разработанных документов. В проверке качества требований участвует вся команда разработки программного обеспечения, а также эксперты предметной или другие представители заказчика. Наиболее распространенным методом проверки спецификаций требований является проверка экспертом предметной области. Эксперт проверяет спецификацию на наличие предметных неточностей, противоречий. После проверки и исправления замечаний спецификация требований утверждается заказчиком и команда приступает к проектированию и разработке программного обеспечения. Проверка одним лишь экспертом часто приводит к тому, что спецификация не содержит ошибок в предметной области и весь функционал описан правильно, но, как показывает практика, требования могут быть сложно реализуемыми, не тестируемыми, дорогостоящими. Для выхода из подобной ситуации в проверке требований также должны участвовать инженеры по тестированию, системные архитекторы и руководитель проекта. Для проверки требований рекомендуется также использовать руководства и контрольные списки, которые содержат рекомендации и критерии «хороших» требований. 16. Управление изменениями требований Требования к разрабатываемой системе могут изменяться не одни раз в процессе ее разработки. Причиной изменения требований могут служить результаты анализа требований, их уточнение, запросы пользователей на изменение системы, новые требования от заказчика и многое другое. Для того чтобы отслеживать все изменения и принимать решения о том, изменять требование или нет, необходимо использовать процесс управления изменениями требований. Процесс управления изменениями включает в себя: 1. Анализ запроса на изменение; 2. Создание (изменение требования) 3. Создание связи запроса с требованиями 4. Прослеживание влияния запроса на требования к системе. Для того чтобы требование существенно не повлияло на изменение многих связанных с ним требований необходимо проанализировать данное изменение и принять соответствующее решение. Часто бывает, что измененное или новое требование приводит к повторной разработке нового функционала или переделки большой части имеющегося программного кода, и, следовательно, может сказаться на сроках и бюджете проекта. Для предотвращения подобных ситуаций используется управление изменениями. 17. Стандарты За последние 20 лет разработано множество методологий, стандартов, сводов знаний, фреймворков (framework) и систем поддержки жизненного цикла ПО. Среди них RUP (Rational Unified Process), MSF (Microsoft Solutions Framework), Agile, ГОСТ, ISO, CMMI (Capability Maturity Model Integration), SWEBOK (Software Engineering Body of Knowledge), BABOK (Business Analysis Body of Knowledge), PMBOK (Project Management Body of Knowledge). В каждом из них по-своему обеспечиваются качество управления требованиями, и реализуется процесс управления требованиями, а также процессы поддержки жизненного цикла. Далее будут рассмотрены процессы поддержки жизненного цикла ПО и управления требованиями на примере Rational Unified Process. В связи с тем, что в наш курс нет возможности поместить оставшиеся стандарты и методологии, то с ними предлагается ознакомиться самостоятельно. 18. Rational Unified Process Ведущей методологией, в которой инструментально поддерживаются все этапы жизненного цикла разработки ПО, является методология Rational Unified Process (RUP). Она опирается на проверенные практикой методы анализа, проектирования и разработки ПО, методы управления проектами. RUP обеспечивает прозрачность и управляемость процесса и позволяет создавать ПО в соответствии с требованиями заказчика на момент сдачи ПО, а также в соответствии с возможностями инструментальных средств поддержки разработки. Отличительные черты RUP RUP – это итеративный процесс (Controlled Interactive); Предполагает сквозное применение аппарата Use Cases (Use Case Driven); Особое внимание уделяется разработке архитектуры (Architecture Centric); Включает управление требованиями и изменениями (Requirements Configuration and Change Management); Опирается на компонентно-базированную (КБ) концепцию разработки программных средств (ПС) (Component Based Development). Базируется на визуальном моделировании (Visual Modeling Techniques); Итерации RUP предлагает итеративный подход к проектированию и разработке ПС, основанный на спиральном жизненном цикле. Весь жизненный цикл включает четыре фазы – вхождение в проект (исследование), развитие (уточнение плана), конструирование и развертывание (Рис. 12). Каждая фаза складывается из последовательности итераций, число которых может быть любым. В каждой итерации перечисленные выше технологические процессы последовательно применяются к разработке небольшой части ПС. При этом допустимо предъявление результата заказчику. Он имеет возможность оценить выполненную реализацию, выдать свои замечания, которые могут привести к изменению и уточнению требований к ПС. Следующая итерация предполагает расширение уже разработанной части путем реализации и интеграции очередной порции требований и учета изменения требований в соответствии с замечаниями заказчика. Такая организация процесса имеет целый ряд преимуществ. Рис. 12 – Графическое представление процесса разработки по RUP Изменения и уточнения требований выявляются уже в ранний период разработки, когда объем программного кода сравнительно небольшой, поэтому трудоемкость внесения изменений существенно ниже. Уже на ранней стадии процесса разработки имеется возможность привлечения специалистов заказчика для оценки промежуточных версий (прототипов) ПС. Как результат – значительно более высокая вероятность того, что конечный продукт будет делать именно то, чего ждет от него заказчик, то есть, гарантируется высокое качество ПС. Снижаются архитектурные и интеграционные риски. При итеративном подходе создается устойчивая архитектура, которая прорабатывается на стадиях исследования, а затем проверяется и уточняется в нескольких начальных итерациях. Каждая итерация предполагает интеграцию новых элементов в систему, то есть, количество интегрируемых элементов в каждой итерации невелико и легче прослеживается, чем при глобальной интеграции всех разработанных элементов ПС. Итеративный подход способствует более полному повторному использованию программных элементов. Анализ результатов каждой итерации позволяет архитекторам ПС выделить фрагменты, потенциально подлежащие повторному использованию, а в следующей итерации оформить их как повторно используемые коды. Это свойство очень хорошо сочетается с идеями ОО и КБ проектирования. RUP – процесс, направляемый вариантами использования Понятие use case, введенное в языке UML, является основой для выполнения всех этапов жизненного цикла, рассматриваемых в RUP. Понятие «business use case» (вид деятельности) является ключевым при бизнес-анализе. На этапах анализа требований, проектирования и реализации use cases выступают в качестве вариантов использования системы (ВИ). При анализе требований, выделив ВИ, мы тем самым определяем требование или уровень иерархии требований к ПС. При детализации ВИ определяются объекты, и способы их взаимодействия, которые должны быть реализованы в программном коде. Следует особо выделить роль ВИ в планировании итераций. Как определить, какая функциональность должна быть реализована в очередной итерации? Здесь на выручку приходят диаграммы ВИ. Каждому ВИ можно приписать приоритет, определяющий, в какой итерации его следует реализовать. Можно показать все ВИ, реализуемые в очередной итерации, на отдельной диаграмме (или нескольких диаграммах). RUP – процесс, основанный на архитектуре В основе RUP лежит КБ разработка ПС, предусматривающая разработку компонентов и сборку ПС из разработанных и готовых компонент. В основе любого проекта лежат кардинальные решения, определяющие принципы построения ПС, которые находят свое отражение в архитектуре системы. Разработка архитектуры ПС в RUP преследует следующие цели: Описание организации ПС; Определение компонентов и их интерфейсов; Определение подсистем и объединение компонентов в подсистемы; Создание основы для повторного использования компонентов; Создание базиса для разработки; Контроль над проектом и поддержка целостности системы. Архитектура ПС находит отражение в различных архитектурных представлениях. Логическое представление отражает функциональные требования к системе. Оно определяет основные (архитектурно значимые) пакеты, подсистемы и классы проекта. Реализационное представление описывает организацию статических программных модулей (компонентов, файлов данных, исходного кода и др.) в терминах пакетов и уровней. Процедурное представление отражает аспекты параллельности задач, потоков и процессов во время работы системы и их взаимодействия. Представление развертывания показывает, как компоненты отображаются на базовые платформы и вычислительные узлы. Use case представление содержит ключевые ВИ и сценарии. Архитектурные представления акцентируют внимание только на таких элементах, которые имеют существенное влияние на структуру ПС, ее производительность, масштабируемость, устойчивость, сопровождаемость, возможность развития. К числу таких элементов относятся: Классы, моделирующие основные объекты деятельности; Механизмы, определяющие поведение этих классов; Уровни и подсистемы; Интерфейсы; Основные процессы и управляющие потоки. В RUP предусмотрено создание отдельного документа, содержащего описание архитектуры ПС. Технологические процессы в RUP В RUP определено 9 технологических процессов, для каждого из которых предложена методика выполнения. Технологические процессы делятся на две категории – основные процессы и процессы поддержки. К основным относятся: Бизнес-анализ, Управление требованиями, Анализ и проектирование, Реализация, Тестирование, Развертывание. Вспомогательные процессы включают: Управление проектом, Управление конфигурацией, Управление средой. Для каждого технологического процесса предусмотрены роли, определяющие поведение и обязанности отдельных лиц и групп, работающих в одной команде (например, системный аналитик, тестировщик), виды деятельности, определяющие работы, выполняемые исполнителями (например, проектирование класса, проектирование ВИ) и артефакты – документы, используемые, порождаемые или модифицируемые процессом. Основные артефакты в RUP – модель, элемент модели, документ, исходный код, исполняемая программа. 19 RUP. Роли при разработке информационной системы Количество ролей зависит от масштаба и количества проектов. При разработке небольших проектов одни и те же роли может выполнять один человек. Рассмотрим роли, которые присутствуют при разработке ИС по методологии RUP. В бизнес-моделировании участвуют: бизнес-аналитик – специалист организации-разработчика, который возглавляет и координирует работы по моделированию бизнеса; бизнес-разработчик – специалист организации-разработчика, который детализирует и уточняет бизнес модели, определяет бизнесисполнителей их обязанности и действия; заинтересованные лица – люди, предоставляющие информацию. Это могут быть бизнес-исполнители или клиенты организации, а также прочие люди, заинтересованные как в собственно результатах моделирования, так и в будущей ПС. эксперт – представитель обследуемой организации, участвующий в разработке модели (консультации, организация встреч с заинтересованными лицами, оценка результатов). Эксперт, в частности, может быть одним из бизнес-исполнителей. В анализе и моделировании требований участвуют: Системный аналитик – специалист организации-разработчика, который возглавляет и координирует работы по выявлению и моделированию требований. Разработчик ВИ – специалист организации-разработчика, который детализирует и уточняет модели требований. Заинтересованные лица – люди, предоставляющие информацию. Эксперт – представитель заказчика, участвующий в разработке модели требований. Разработчик пользовательского интерфейса – специалист организации-разработчика, который создает прототип пользовательского интерфейса ПС. На этапе анализа и проектирования работают: Системный архитектор – руководит работами по анализу и проектированию ПС. Он определяет общую структуру каждого архитектурного представления, декомпозицию представлений, группировку элементов и интерфейсы между группами. Разработчик – проектирует классы и отношения между ними Он определяет, как согласовывать классы со средой реализации. Разработчик БД – отвечает за проектирование базы данных ПС. На этапе реализации задействованы: Конструктор (кодировщик) разрабатывает компоненты и классы, выполняет блочное тестирование. Системный интегратор выполняет интеграцию элементов в программные конструкции (систему и подсистемы). Архитектор определяет структуру реализации (организацию уровней и подсистем). Рецензент кода проверяет качество программного кода и его соответствие стандартам проекта. В тестировании участвуют: Разработчик тестов отвечает за планирование, разработку и реализацию тестов. Он создает план и модель тестирования, методики испытаний (см. ниже) и выполняет оценку результатов тестирования. Тестировщик (испытатель) отвечает за выполнение системного тестирования. В его обязанности входит настройка и выполнение тестов, оценки выполнения теста, восстановление после ошибок, регистрация выявленных дефектов. 18. RUP. Процессы поддержки жизненного цикла RUP предусматривает три процесса поддержки жизненного цикла: управление проектом; управление конфигурацией; управление средой. Управление проектом. Цели Основной целью процесса управления проектом является обеспечение руководства проектом, направленное на успешную сдачу программного продукта. RUP акцентирует внимание на планировании жизненного цикла и отдельных итераций, управлении рисками, наблюдаемости хода проекта и метриках проекта. Планирование предполагает созданий двух видов планов: План фаз – крупномасштабный план проекта, показывающий основные вехи жизненного цикла (даты завершения больших этапов – фаз, выпуска эволюционных прототипов и т. д.) и требуемые ресурсы. Он создается в начале фазы исследования и обновляется по мере необходимости. План итераций создается для каждой итерации и предназначается для определения и распределения задач между участниками проекта. Риском будем называть все то, что может стоять на пути к успеху проекта и на данный момент является неизвестным или неопределенным. Главная идея управления рисками заключается в том, что не нужно пассивно ждать, пока риск станет проблемой, но требуется заблаговременно определять линию поведения. Управление рисками означает определение и оценку рисков, принятие линии поведения, направленной на устранение, снижение вероятности риска, а также выбор действий на случай реализации риска. Для контроля и управления проектом используются измерения. Они проводятся для того чтобы установить, насколько отдалено текущее состояние проекта от поставленной цели, спланировать работы и определить, как можно повысить эффективность процесса. Управление проектом. Деятельности Открытие нового проекта. Эта деятельность выполняется только в первой итерации. Осуществляется инициализация проекта, определяются и оцениваются риски, разрабатывается бизнес-план. Цель – перевод проекта в стадию, когда возможно принятие решения о продолжении или об отказе от проекта. Оценка области действия проекта и рисков. Целью является пересмотр и уточнение возможностей и характеристик проекта, а также связанных с ним рисков. Создание плана разработки ПС. Создается план разработки ПС, включающий перечень рисков, планы измерений, управления рисками, разрешения проблем, принятия продукта. Определяется структура и ресурсы проекта. Разрабатывается план фаз проекта. Планирование итерации. Разрабатывается план очередной итерации, уточняется и корректируется бизнес-план и план разработки ПС. План итерации подробно описывает, что должно произойти за время итерации. Он определяет исполнителей и выполняемые ими работы. При создании плана итерации необходимо: Сформулировть объективные критерии успеха итерации. Они будут использоваться при ее оценке; Определить конкретные, измеримые артефакты, которые требуется разработать или изменить, а также выполняемые для этого работы; Использовать типичную итерационную декомпозицию работ для реальных действий, которые должны быть произведены; Использовать смету при определении продолжительности и объема работ для каждого вида деятельности, удерживая все значения в пределах бюджета. Наблюдение и контроль. Эта деятельность включает распределение работ и создание графика работ, наблюдение за состоянием проекта, обработку исключительных ситуаций, и создание отчета о состоянии. Выполняется обработка предложенных изменений и включение их в график работ текущей или последующих итераций, производится наблюдение за активными рисками, дается оценка прогресса и качества проекта. В RUP постоянно выполняемые оценки состояния проекта являются основой для решения разных проблем и управления рисками проекта. Если команда разработчиков выявила проблему, назначается сотрудник, ответственный за ее разрешение, и определяется дата, когда проблема должна быть разрешена. Ход процесса должен регулярно контролироваться, а обновления должны выполняться по мере необходимости. Управление итерацией. Целью этой деятельности является получение достаточных для выполнения итерации ресурсов, разделение требуемых работ, оценка результатов итерации. Завершение фазы. Выполняются работы, завершающие выполнение фазы. Даются ответы на следующие основные вопросы: Решены ли все основные проблемы предыдущей итерации? Известно ли состояние всех основных артефактов (см. ниже управление конфигурацией)? Рассмотрены ли все проблемы развертывания? При удовлетворительном состоянии проекта выдается разрешение на переход к следующей фазе. Завершение проекта. Руководитель проекта подготавливает проект к завершению. Готовится заключительная оценка состояния. При успешной сдаче проекта заказчик получает программный продукт в пользование. Высвобождающие ресурсы могут быть перераспределены (использованы в других проектах). Управление конфигурацией и изменениями. Цели Целью управления конфигурацией и изменениями является поддержание целостности артефактов с учетом возможности внесения в них изменений в соответствии с запросами на изменения. Этот вспомогательный процесс распространяется на весь жизненный цикл программного продукта и складывается из трех отдельных процессов. Управление конфигурацией (Configuration management). Процесс управления конфигурацией (УК) связан с определением артефактов, зависимостей между ними и конфигураций, являющихся непротиворечивыми множествами взаимосвязанных артефактов. Сюда же относятся вопросы распределения рабочих сред между участниками проекта с целью предотвращения ненужного дублирования документов. УК декларирует, что все артефакты подчиняются управлению версиями. По мере развития проекта у каждого артефакта появляются множество версий. Все они сохраняются в архиве проекта, причем ведется история изменений, в которой указывается причины и цели создания каждой версии каждого артефакта. Записанную в архив проекта версию нельзя изменить, можно лишь создать новую версию. Кроме того, знания о зависимостях между артефактами позволяют точно повторять действия при создании наборов артефактов (например, при сборке программы из отдельных файлов). Создание версий и связей поддерживается с помощью инструментальных средств УК. УК позволяет: исключить возможность потери артефактов, обеспечить возможность «возврата назад» в случаях, когда принятые решения и полученные при их реализации версии артефактов не устраивают заказчика или разработчиков проекта, гарантировать точное повторение действий над группой связанных артефактов в итерациях, избегать дублирования артефактов и связанной с этим возможности привнесения дополнительных дефектов, поддерживать наблюдаемость хода выполнения работ по проекту путем предоставления нужной информации. Управление внесением изменений Деятельности этого процесса направлены на сбор и сохранение запросов на внесение изменений, поставляемых как участниками разработки ПС, так и внешними сторонами. Запросы на внесение изменений могут появляться по разным причинам (исправление дефекта, улучшение параметра качества продукта, например, производительности, задание дополнительных требований и т. д.) Каждый запрос на внесение изменений сохраняется в базе данных проекта и может находиться в разных состояниях в зависимости от хода выполнения работ по этому запросу (новый, зарегистрированный, принятый, завершенный и др.). Состояния запросов изменяются участниками проекта в соответствии с выделенными правами. По мере работы с запросом в него добавляется информация (например, сначала это может быть только описание дефекта, затем добавляется результаты анализа, указываются затрагиваемые артефакты, назначается исполнитель). С запросом может быть связан приоритет, позволяющий определить порядок выполнения работ по запросам на изменения. Управление состоянием и измерениями Этот процесс связан с управлением проектом и направлен на предоставление информации, полезной для оценки: Состояния, прогресса, общих тенденций и качества продукта; Издержек и расходов; Проблемных областей, требующих внимания; Того, что сделано и что необходимо сделать. Вся необходимая информация находится в базе данных и архиве проекта. Руководитель работ оценивает состояние дел путем непосредственного просмотра запросов, истории версий артефактов или на основе анализа различных отчетов, формируемых инструментальным средством УК. Анализ позволяет руководителю оценить имеющиеся ресурсы и принять необходимые управленческие решения. Деятельности Планирование конфигурации проекта и управления изменениями. Описываются все виды деятельности, связанные с УК, которые надо выполнить. Описывается процесс контроля над изменениями. Создание среды УК. Целью этой деятельности является создание рабочей среды, в которой будут доступны все артефакты, будет обеспечена разработка, интеграция и архивирование продукта. Создание рабочей среды исполнителей. В пределах своей рабочей среды исполнитель получает доступ к артефактам проекта, имеет возможность вносить в них изменения и предлагать внесение изменений в проект в целом. Изменения, сделанные отдельными исполнителями, направляются в рабочую среду интеграции. Управление версиями. При записи артефакта в архив проекта формируется его новая версия. Управление версиями предусматривает обязательное указание причин и целей создания версии. При выборе артефакта из архива можно указать конкретную версию. Управление запросами на внесение изменений. Целью этой деятельности является обеспечение последовательного внесения изменений в проект и информирование о состоянии продукта, его изменениях и о влиянии изменений на стоимость и сроки выполнения проекта. Наблюдение за состоянием конфигурации. Наблюдаемость процесса разработки обеспечивается путем доступа руководства проекта к хранимым артефактам и запросам на изменения, а также путем предоставления отчетов о состоянии конфигурации. При этом инструментальные средства, поддерживающие управление конфигурацией и изменениями, могут выполнять требуемые измерения. Например, можно показать процент завершенных запросов, число открытых запросов высокого приоритета и т. д. Управление средой. Цели Многие виды деятельностей, предусмотренные RUP, могут быть автоматизированы посредством инструментальных средств, что позволит избежать наиболее трудоемких, напряженных и подверженных ошибкам аспектов разработки ПС. Цель процесса управления средой – процедурная и инструментальная поддержка организации, разрабатывающей ПС. Она включает: Выбор и приобретение инструментальных средств; Настройку инструментальных средств под требования организацииразработчика; Конфигурирование процесса; Усовершенствование процесса; Создание технических служб поддержки. Роли и артефакты Основным исполнителем процесса является технолог. В его обязанности входит конфигурирование процесса перед запуском проекта и усовершенствование процесса в ходе проектных работ. Поддержка аппаратной и программной среды разработки ложится на плечи системного администратора. Главным создаваемым артефактом является план разработки, описывающий процесс, используемый в данном проекте. В нем указывается, какие артефакты, предусматриваемые в RUP, будут использоваться в проекте и каким образом. Деятельности Подготовка среды к реализации проекта. Выполняется оценка текущего состояния организации-разработчика и имеющейся инструментальной поддержки. Создается предварительный план разработки. Составляется перечень инструментальных средств, которые предполагается использовать при разработке. Составляется перечень шаблонов для производства основных артефактов. Подготовка среды к итерации. Производится дополнение и уточнение плана разработки, выполняется подготовка и настройка инструментальных средств, которые будут использоваться в итерации. Составляется набор шаблонов для артефактов, создаваемых в итерации. Осуществляется подготовка сотрудников к использованию инструментальных средств. Подготовка руководящих директив. Для каждого основного технологического процесса подготавливается набор директив на основе анализа проблем и дефектов предыдущих итераций. 19. RUP. Программное обеспечение IBM Rational Suite Управление архитектурой Решения IBM по управлению архитектурой делятся на две категории: Enterprise Architecture Management (управление архитектурой предприятия EAM) и Architecture, Design, and Construction (архитектура, дизайн и конструирование - ADC). Enterprise Architecture Management позволяет связать коммерческие и технические потребности организации в единую согласованную и динамичную систему, предоставив ключевые возможности для управления изменениями, вызванными бизнес-требованиями. EAM помогает минимизировать затраты при объединениях, слияниях, поглощениях и других инициативах, при этом максимально снижая связанные с ними риски и способствуя нахождению способов повышения эффективности выполнения операций. Благодаря выстраиванию единого процесса создания продукта от разработки стратегии до внедрения, EAM помогает извлекать максимальную коммерческую выгоду из технологических решений. Решения IBM по управлению архитектурой предприятия включают следующие продукты: Rational System Architect Rational Asset Manager Решения IBM Rational ADC включают ведущие в отрасли системы и средства разработки программного обеспечения, позволяющие упростить и ускорить процесс разработки. Они повышают прозрачность и предсказуемость проектов, а также расширяют возможности повторного использования компонентов разрабатываемых продуктов. Решения ADC изначально создавались для аналитиков, архитекторов и разработчиков программного обеспечения как инструменты управления изменениями в архитектуре, поддержки ее согласованности и обеспечения соответствия текущим требованиям. Также ADC включают среды разработки приложений. Семейство ADC состоит из следующих решений: Rational Application Developer для разработки под WebSphere Rational Business Developer Rational Modeling Extension для Microsoft .NET Rational Rhapsody Rational Rose Rational Rose Technical Developer Rational SDL Suite Rational Software Architect Standard Edition Rational Software Architect для разработки под WebSphere Rational Software Modeler Rational Statemate Rational Tau Описание и управление требованиями IBM Rational предлагает методики описания и управления требованиями, позволяющие сократить временные и финансовые затраты. Используя продукты Rational, имеется возможность: Снизить необходимость доработки, повысить качество обратной связи и ускорить выпуск продуктов на рынок благодаря более эффективному взаимодействию с заказчиками. Повысить продуктивность за счет более четкого контроля и управления требованиями, а также более эффективной организации и поиска информации и требованиях. Привести конечные результаты проектов в соответствие с бизнес-целями и требованиями, чтобы выпущенные продукты в полной мере отвечали запросам заказчиков. Сократить расходы и минимизировать риски за счет анализа последствий изменений по мере их появления. Подтвердить соответствие программных продуктов благодаря оперативному контролю требований. Решения IBM по описанию и управлению требованиями включают следующие продукты. Rational Requirements Composer Rational RequisitePro Rational Doors Управление изменениями и выпусками IBM Rational предлагает универсальные, интегрированные продукты по управлению изменениями и выпусками, способствующие успешной поставке программного обеспечения. Эти решения помогают группам разработчиков приложений и аппаратных решений повысить продуктивность и эффективность совместной работы, улучшить прозрачность проектов, автоматизировать процессы разработки, повысить качество, управлять географически распределенными командами, а также отслеживать все изменения на всем протяжении жизненного цикла проекта. Решения IBM в этой области включают следующие продукты. Rational Team Concert™ IBM Rational Build Forge Rational Software Analyzer Rational Synergy Rational ClearCase Rational ClearQuest Rational Change Управление процессами и портфелями проектов Решения IBM Rational по управлению продуктами, проектами и портфелями преображают традиционный подход к выпуску продуктов. Они предоставляют средства для приведения программного обеспечения и инвестиций в соответствие с бизнес-целями компании, а также повышают вероятность успеха за счет внедрения лучших методик разработки и контроля. Эти решения помогают компаниям более последовательно и уверенно извлекать выгоду из существующих программных и аппаратных продуктов. Решения Rational отличаются открытостью, ориентированностью на роли участников проекта и поддержкой всего жизненного цикла проекта. Они включают следующие продукты. Rational Focal Point Rational Insight Rational Method Composer Rational Unified Process (RUP) Rational Harmony Rational Publishing Engine Управление качеством Решения IBM Rational для тестирования программного обеспечения и управления качеством меняют классические принципы совместной работы над качеством продуктов. Эти решения, включающие полный набор методик по подготовке продуктов к выпуску, проверенные подходы и интегрированные средства, поддерживают широкий спектр разнообразных приложений и помогают тестировщикам и другим специалистам по обеспечению качества успешно сокращать расходы и повышать качество. В итоге продукты IBM Rational увеличивают экономическую эффективность ключевых для бизнеса проектов. Эти решения ускоряют поиск и устранение неисправностей, гарантируя четкое взаимодействие между бизнес-пользователями, разработчиками, специалистами по обеспечению качества и ИТ-отделами. Они специально оптимизированы для оперативного контроля над ресурсами в процессе разработки, максимально быстрого выявления проблем и раннего предупреждения о рисках доступности на этапе эксплуатации продуктов. Rational Quality Manager Rational Functional Tester Rational Performance Tester Rational Service Tester для обеспечения качества решений на базе SOA Rational PurifyPlus® Rational Robot Rational Test Lab Manager Rational Test RealTime БИБЛИОГРАФИЧЕСКИЙ СПИСОК [1] К. Вигерс. Разработка требований к программному обеспечению, Русская Редакция, 2004 [2] Д. Леффингуэлл, Д. Уидриг, Принципы работы с требованиями к программному обеспечению. Унифицированный подход, Вильямс, 2002 [3] IIBA, A guide to the Business Analysis Body of Knowledge, v1.6, 2006 [4] IBM, Rational Unified Process v. 2003. [5] K. Baxter, Understanding Your Users., Morgan Kaufmann Publishers,2005 [6] Г. Буч, А. Якобсон, Дж. Рамбо, UML 2-е издание, Питер, 2006. [7] Project Management Body of Knowledge (PMBOK) [8] Alistair Cockburn – Writing Effective Use Cases [9] Лешек А. Мацяшек – Анализ требований и проектирования систем
