maran program engineering (Маран Программная инженерия), страница 10

Архитектура — это представление всего проекта с выделением важных характеристик и затушевывани50ем деталей. Варианты использования определяют функции, а архитектура —форму. Для определения формы разрабатываемой системы архитектор долженпроанализировать ключевые функции будущей системы. Как показывает опыт,ключевые функции отражены примерно в 5–10% вариантов использования, которые содержат функции ядра системы. На основе анализа ключевых вариантовиспользования разрабатывается архитектура создаваемого программногопродукта, которая в ходе дальнейшей работы над проектом должнарасширяться и дополняться, но не переделываться кардинальным образом.Разработка программных продуктов — это сложная работа.

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

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

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

В [8] это сформулировано так: «Единственное, что постоянно в разработке программ — это изменение требований»;• итерации позволяют ускорить процесс разработки в целом, потому чтокороткий и четкий план разработки предпочтительнее длинного и непонятного и способствует эффективной работе разработчиков;• на каждой итерации выполняется тестирование, что позволяет вовремязаметить допущенные ошибки и недостатки и принять своевременномеры для их устранения.При реализации сложных проектов большого объема результатом первыхитераций может быть лишь прототип будущей системы, который не можетбыть внедрен, а используется лишь как база для будущих итераций, для отработки принципов реализации, для достижения лучшего взаимопонимания заказчиков и разработчиков.51Для разработки программного продукта УП циклически повторяется: каждый цикл включает в себя фазы анализа, проектирования, реализации и внедрения.

Каждая фаза состоит из 2−3 итераций. Каждый цикл представляет собой мини-проект, реализуемый по модели «мини-водопад».Каждая фаза заканчивается вехой; веха определяется по наличию определенного набора моделей, представленных в заранее оговоренном виде. На каждой вехе следует ответить на вопросы: что удалось достичь на законченной фазе, что не удалось (в таком случае возникают вопросы: Почему? Что надо сделать?), что планируется на следующей фазе.Разработка нового программного продукта начинается с составления модели вариантов использования, которая в ходе разработки:• описывается в модели анализа;• реализуется в модели проектирования;• распределяется в модели развертывания;• реализуется в модели реализации;• проверяется в модели тестирования.Модель вариантов использования дает ответ на вопрос: «Что должна делать система?», оставляя ответ на вопрос: «Как?» на потом.Модель анализа предназначена для уточнения деталей вариантов использования и создания первичного распределения поведения системы по набору объектов.

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

е. для описания принципов функционирования той предметной области, для которой создается новыйпрограммный продукт. Для модели предметной области подходит диаграммаклассов, для бизнес-модели — диаграмма деятельности.Подведем итоги. В ходе фазы анализа идея превращается в концепциюготового продукта и создается план его разработки. Можно сказать и так: прикладная задача превращается в программистскую задачу. Должны быть получены ответы на следующие вопросы:• что система должна делать для ее основных пользователей;• как должна выглядеть архитектура системы;• каков план и во что обойдется разработка продукта?52В ходе фазы проектирования детально описывается большинство вариантов использования и разрабатывается архитектура системы. В ходе этой фазыопределяются наиболее критичные варианты использования и создается базовая архитектура.

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

Определение требованийЦель определения требований − ответить на вопрос, что должно делатьсоздаваемое программное обеспечение для каждого потенциального пользователя? Правильный и исчерпывающий ответ на этот главный вопрос позволит направить процесс разработки на получение правильной системы. Определениемтребований занимаются системные аналитики. Основное внимание следует обратить на то, что клиенты, с которыми мы работаем (которые являются главнымнашим источником информации и, как правило, не являются специалистами поинформационным технологиям), должны быть способны прочесть и понять результаты определения требований. Для выполнения этого условия для описаниятребований следует использовать язык клиента. Типовой рабочий процесс определения требований включает следующие тесно взаимосвязанные шаги:• перечисление возможных требований;• описание контекста системы;• определение функциональных требований;• определение нефункциональных требований.Перечисление возможных требований.

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

Это, в первую очередь, влияет на определение функциональных требований. Контекст определяется составом действующих лиц и их вариантов использования. Важной частью описания контекста является создание глоссария: списка применяемых в предметной областитерминов и их определений. Это необходимо для того, чтобы в дальнейшем заказчик и разработчик «говорили на одном языке». В глоссарии должны бытьустранены синонимия (несколько терминов для обозначения одного и того жепонятия) и омонимия (одно слово обозначает разные понятия).Определение функциональных требований (какими функциями должно обладать создаваемое программное обеспечение) заключается в разработкемодели вариантов использования.Определение нефункциональных требований заключается в определении характеристик создаваемого программного обеспечения, важнейшими среди них являются:• ограничения на программно-техническую среду реализации (техническиесредства, операционная система, система управления базами данных,инструментальная система реализации);• объемно-временные характеристики (предполагаемый объем базы данных, ограничения на время реализации, количество одновременно работающих пользователей);• требования к защите данных (достаточно традиционных имени пользователя и пароля или нужно применять средства защиты данных);• требования к надежности создаваемого программного обеспечения.Нефункциональные требования могут быть связаны с вариантами использования (например, ограничения на время отклика) или относиться к системе в целом (например, надежность).

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

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