exam06 3
Реферат к лекции 6 (22). Управление конфигурацией
Выполнила: Цициашвили Софья ИДБ-19-06
Проверила: Бабина Анастасия ИДБ-19-06
Инженерия - область человеческой интеллектуальной деятельности по применению достижений науки к решению конкретных проблем человечества. Инженерное сообщество может на основании целей инженерной деятельности выбирать и концентрировать технику, внедрять ее в инженерный процесс, а также направлять и ограничивать инженерный процесс. Программная инженерия — приложение систематического, дисциплинированного, измеримого подхода к разработке, функционированию и сопровождению программного обеспечения, а также исследованию этих подходов; то есть, приложение дисциплины инженерии к программному обеспечению.
Гибкая методология разработки - это система методов, основанных на итеративной разработке.
Основа методологии — разбиение проектов на маленькие рабочие кусочки, называемые пользовательскими историями. Согласно приоритетности задачи решают в рамках коротких двухнедельных итераций.
Feature driven development (FDD) — итеративная методология разработки программного обеспечения, одна из гибких методологий разработки. FDD представляет собой попытку объединить наиболее признанные в индустрии разработки программного обеспечения методики, принимающие за основу важную для заказчика функциональность (свойства) разрабатываемого программного обеспечения.
Основная цель данной методологии: разработка реального, работающего программного обеспечения систематически, в поставленные сроки.
В рамках методологии FDD все проектные работы требуется разделить на пять процессов:
- Разработка общей модели.
- Создание списка необходимых функций.
- Планирование работы над каждой функцией.
- Проектирование функции.
- Реализация функции.
Проект FDD начинается с высокоуровневого пошагового руководства области действия системы и ее контекста. Затем для каждой области моделирования небольшими группами создаются подробные модели предметной области, которые представляются на экспертную оценку. Одна или несколько из предложенных моделей выбираются, чтобы стать моделью для каждой предметной области. Модели предметной области постепенно объединяются в общую модель.
Информация, собранная при построении общей модели, используется для составления списка функций. Это осуществляется разбиением областей на подобласти с точки зрения функциональности. Каждая отдельная подобласть соответствует какому-либо бизнес-процессу, шаги которого становятся списком функций (маленькие части понимаемых пользователем функций, представленных в виде «<действие> <результат> <объект>», например, «проверка пароля пользователя»). Разработка каждой функции должна занимать не более 2 недель, иначе задачу необходимо разбить на несколько подзадач, каждая их которых сможет быть завершена за установленный двухнедельный срок.
Далее идет этап распределения функций. Владение классами распределяется среди ведущих программистов путем упорядочивания и организации свойств в классы.
Для каждого свойства создается проектировочный пакет. Ведущий программист выделяет небольшую группу свойств для разработки в течение двух недель. После оставляются подробные диаграммы последовательности для каждого свойства, уточняя общую модель. Далее пишутся «заглушки» классов и методов. В этот момент мы должны сфокусироваться на дизайне программного продукта.
После успешного рассмотрения дизайна, данная видимая клиенту функциональность реализуется до состояния готовности. Для каждого класса пишется программный код. После модульного тестирования каждого блока и проверки кода, завершенная функция включается в основной проект.
Для мониторинга проекта по разработке ПО и предоставления точных данных о развитии проекта необходимо протоколировать разработку каждого свойства. FDD выделяет шесть последовательных этапов для каждой функции.
Первые три полностью завершаются в процессе проектирования, последние три — в процессе реализации. Для удобства контроля за выполнением работ на каждом этапе показывается процент его готовности (выполнения). В таблице ниже приведены основные этапы. Функция, которая всё ещё находится в разработке, завершена на 44 % (Анализ области 1 % + Дизайн 40 % + Проверка дизайна 3 % = 44 %)
Следует отметить, что каскадная модель и FDD достаточно схожи, отличия абсолютно незначительные. Программные средства в обоих моделях проходят одни и те же фазы, однако при использовании каскадной модели объектом разработки выступают сразу все функции, а при FDD - одна. Далее подробнее рассмотрим на что может повлиять данное отличие.
Каскадная модель является одна из самых старых, подразумевает последовательное прохождение стадий, каждая из которых должна завершиться полностью до начала следующей. Благодаря её четкости, разработка проходит быстро, стоимость и срок заранее определены. Стоимость внесения изменений высока, потому что для ее инициализации приходится ждать завершения всего проекта.
Как было сказано до этого, в «гибкой» методологии разработки после каждой итерации заказчик может наблюдать результат и понимать, удовлетворяет он его или нет. Однако, в отличие от модели "Водопада", из-за отсутствия конкретных формулировок результатов сложно оценить трудозатраты и стоимость, требуемые на разработку. Методология подходит для больших или нацеленных на длительный жизненный цикл проектов, постоянно адаптируемых к условиям рынка. В отличие от модели водопада, в гибкой модели для старта проекта достаточно лишь небольшого планирования.
FDD построен на основе набора передового опыта (набора наилучших практик), признанного в отрасли и полученного из инженерии программного обеспечения. Эти практические методы строятся с точки зрения важного для клиента функционала. Дадим краткое описание каждого метода: 1)Объектное моделирование области. Состоит из исследования и выяснения рамок предметной области решаемой задачи, Результатом является общий каркас, который можно в дальнейшем дополнять функциями. 2)Разработка по функции. Любая функция, которая слишком сложна для разработки в течение двух недель, разбивается на меньшие подфункции до тех пор, пока каждая подзадача не может быть реализована за 2 недели. Это облегчает создание корректно работающих функций, расширение и модификацию системы. 3)Индивидуальное владение классом (кодом). Означает, что каждый блок кода закреплён за конкретным владельцем-разработчиком. Владелец ответственен за согласованность, производительность и концептуальную целостность своих классов. 4)Команда по разработке функций (свойств). Маленькая, динамически формируемая команда разработчиков, занимающаяся небольшой подзадачей. 5)Проверка кода. 6)Конфигурационное управление. Помогает с идентификацией исходного кода для всех функций (свойств), разработка которых завершена на текущий момент, и с протоколированием изменений, сделанных разработчиками классов. 6)Регулярная сборка. Регулярная сборка гарантирует, что всегда есть продукт (система), которая может быть представлена заказчику, и помогает находить ошибки при объединении частей исходного кода на ранних этапах. 7)Обозримость хода работ и результатов. Частые и точные отчёты о ходе выполнения работ на всех уровнях внутри и за пределами проекта о выполненной работе помогают менеджерам правильно руководить проектом.
Одним из примеров использования FDD может быть система, благодаря которой автоматически формируются отчёты о работе компании. Разобрав данный пример и используя такое понятие, как "полное организационно-техническое усилие" можно также увидеть, как связана сама инженерия с FDD. Ответив на вопросы, входящие в данное понятие, удастся определить, что в примере является источником данных, скоростью выполнения, возможностью редактирования и так далее. Функции - маленькие части понимаемых пользователем функций. Поэтому в данном случае функцию можно представить, например, в таком виде - "составление отчета компании".
В гибкой разработке FDD присутствует программная инженерия. Существованием этапа построения общей модели можно подтвердить данное высказывание, ведь это описание архитектуры, что очень важно для реализации некоторых действий. Например, если заказчика интересует информация об определенных характеристиках некоторого происшествия, записанного в отчет или строках/столбцах таблицы, содержащейся в отчете, то нужно посмотреть в общую модель, то есть предполагается, что она есть. На примере описанной системы заказчику придётся ждать всего около часа, чтоб получить такую информацию. Для составления отчета в целом уходит 5 часов. Для внесения правок в таблицу нужно около 1-2 часов, так как информация должна быть внесена корректно и заказчику нужно разобрать все детали информации, которую нужно внести в отчет(согласовать форму). Правки вносятся изменением предыдущей формы.
В данной системе автоматизировано формируются отчеты и легко разбиваются на небольшие функции, то есть каждый отчет - отдельная функция, и разрабатывается от 3 до 10 дней, что меньше двух недель, как и требуется в FDD. Завершив работу над функцией, программа уже выходит, так как отчеты независимы друг от друга. К неавтоматизированным действиям больше всего причастен разработчик, он заинтересован в правильности составления отчетов и все изменяющиеся требования учитываются. На каждом этапе разработки есть возможность получать информацию.
1. FDD Tools.
Мультиплатформенное приложение, поддерживающее гибкую методологию управления проектами.
2. CASE Spec.
Коммерческий корпоративный инструмент для функционально-ориентированной разработки.