Классификация по реализационной специфике методологий
Каждое из ядер методологий имеет определенную специфику, определяющую некоторую организацию аппаратной поддержки данной методологии. На данный момент наиболее известными организациями являются две: централизованная и параллельная.
Ядра методологий изначально продумывались для централизованных архитектур. Позже появились параллельные аппаратные реализации, к которым стали адаптировать уже существовавшие методологии.
Примером параллельной методологии является методология императивного параллельного программирования - подход, в котором предлагается использование явных конструкций для параллельного исполнения выбранных фрагментов программ. Считается, что параллельное программирование возникло с изобретением каналов - независимых аппаратных контроллеров, позволявших центральному процессору выполнять новую прикладную программу одновременно с операциями ввода-вывода других программ. Первоначально с параллельным программированием имели дело лишь разработчики операционных систем.
К методам данной методологии можно отнести метод синхронизации исполняемого кода, который заключается в использовании специальных атомических операций для осуществления взаимодействия между одновременно исполняемыми фрагментами кода. Этот метод поддерживается концепцией примитивов синхронизации.
Смешанные методологии.
Смешанные методологии включают объединение методов нескольких методологий. Наиболее часто объединяются методологии функционального и логического программирования. Существуют исследовательские работы в области объединения объектно-ориентированного и логического программирования. Ряд исследований посвящен вопросам унификации методологий программирования.
|
|
|
Петров В.Н. в своей книге "Технологии разработки программного обеспечения" приводит еще одну методологию - RAD (Rapid Application Development).
Методология быстрой разработки приложений RAD.
На начальном этапе существования компьютерных информационных систем их разработка велась на традиционных языках программирования. Однако по мере возрастания сложности разрабатываемых систем и увеличения запросов пользователей потребовались новые средства, обеспечивающие значительное сокращение сроков разработки. Это послужило предпосылкой к созданию целого направления в области программного обеспечения - инструментальных средств для быстрой разработки приложений. Развитие этого направления привело к появлению на рынке программного обеспечения средств автоматизации практически всех этапов жизненного цикла информационных систем. Эти средства приобрели название методологии быстрой разработки приложений RAD (Rapid Application Development).
|
|
|
RAD - это комплекс специальных инструментальных средств быстрой проектировки прикладных информационных систем, позволяющих оперировать с определенным набором графических объектов, функционально отображающих информационные компоненты приложений.
Под методологией быстрой разработки приложений обычно понимается разработки информационных систем, основанный на трех основных элементах:
· небольшой команде программистов (обычно от 2 до 10 человек);
· тщательно проработанный производственный график работ, рассчитанных сравнительно короткий срок разработки (от 2 до 6 мес);
· итерационная модель разработки, основанная на тесном взаимодействии с заказчиком - по мере выполнения проекта разработчики уточняют и реализацию в продукте требований, выдвигаемых заказчиком.
Основные принципы:
1. используется итерационная (спиральная) модель разработки;
2. полное завершение работ на каждом из этапов жизненного цикла не обязательно;
3. в процессе разработки информационной системы необходимо тесное действие с заказчиком и будущими пользователями;
4. необходимо применение CASE-средств и средств быстрой разработки, средств управления конфигурацией, внесение изменений в проект и сопровождение готовой системы, использование прототипов, позволяющее полнее выяснить и реализовать потребности конечного пользователя;
|
|
|
5. тестирование и развитие проекта осуществляются одновременно с разработкой;
6. разработка ведется немногочисленной и хорошо управляемой командой профессионалов;
7. необходимы грамотное руководство разработкой системы, четкое планирование и контроль выполнения работ.
Средства RAD дали возможность реализовывать совершенно иную по сравнению с традиционной технологию создания приложений: информационные объекты формируются как некие действующие модели (прототипы), чье функционирование согласовывается с пользователем, а затем разработчик может переходить непосредственно к формированию законченных приложений, не теряя из виду общей картины проектирования системы.
Методологии, технологии и инструментальные средства проектирования составляют основу проекта любой информационной системы. Методология реализуется через конкретные технологии и поддерживающие их стандарты, методики и инструментальные средства, которые обеспечивают выполнение процессов жизненного цикла информационных систем.
|
|
|
Формально методологии можно разделить на два типа - классические (монументальные, предсказуемые, где все этапы детально проектируется заранее и не допускается отклонение от первоначального плана) и их противоположность - адаптивные (гибкие, где в процессе работы допустимо и даже типично перепроектирование). В зависимости от начальных условий и характера поставленной задачи, может применяться как классическая, так и адаптивная методология (Рис.2).
Рисунок 2. Классификация методологий
Классическая (монументальная) методология применяется, если:
1. У заказчика есть четкое мнение по поводу функциональности и дизайна будущей программы, то есть ему абсолютно и в деталях ясно, что он хочет получить на выходе.
2. Задача, решаемая программой, четко формализуется и может быть документирована, то есть, возможно, создать подробное техническое задание. Такое техническое задание должно полностью документировать каждое элементарное состояние работы программы, содержать полное описание специальных алгоритмов (если таковые используются), быть однозначно понимаемым во всех пунктах, описывать все детали дизайна пользовательского интерфейса. Техническое задание может быть разработано специалистами или заказчиком самостоятельно.
3. Требования к программе стабильны, и заказчик не будет ставить дополнительных условий по изменению функциональности программы во время ее разработки в рамках текущего контракта. Как следствие этого объем работ строго фиксирован, также как фиксирована и стоимость контакта.
4. Итерационный процесс на данном этапе смещен в область анализа, проектирования и разработки технического задания, процесс разработки строго документирован и линеен. Срок создания технического задания составляет около 60% времени от всего процесса разработки.
Адаптивная (agile - гибкая или lightweight - легкая) методология применяется, если:
1. Не ясны или изменяются требования к системе.
2. Заказчик представляет себе разрабатываемое ПО только в общих чертах и предполагает вносить изменения в функциональность или дизайн разрабатываемой программы во время разработки ("не понравилось - поменяйте").
3. Необходимо как можно быстрее получить первые версии работающей программы.
4. Решаемая программой задача трудно поддается документированию.
5. На реализацию всех требований есть достаточный запас времени.
При применении такой методологии разработка программы представляет собой последовательность большого количества итераций, каждая из которых занимает по времени от недели до месяца. По результатам каждой итерации требования к программе уточняются, и, при необходимости, итерация повторяется. Процесс разработки при такой методологии ведения проекта менее бюрократичен, основные акценты смещены в область практической реализации, а не на создание полной и описывающей "все и вся" документации. Для заказчика есть возможность практическим путем нащупать нужное решение, удовлетворяющее не только изначальным требованиям, но и в том числе тем, которые появятся по мере разработки продукта (а редкий проект обходится без появления таких требований). Заказчик в этом случае более плотно взаимодействует с разработчиками, находится постоянно в курсе текущего положения дел, участвует в проектировании очередного этапа и анализирует результаты выполненного.
В независимости от используемой методологии, рабочий процесс, подчиняется следующим простым, но важным правилам:
1. Используется система контроля версий.
2. Оформление кода стандартизировано.
3. Первоочередное исправления ошибок перед внесением любых других изменений.
4. Выполняется регулярное резервное копирование всех проектных данных.
5. Используются инструментальные средства автоматизации документирования исходного кода и ведения списков ошибок.
6. Выполняются различные виды тестирования, начиная от специально создаваемых тестовых проектов, заканчивая использованием специализированного инструментария.
Одной из важных составляющих успешного проекта является качественное и непрерывные общение с заказчиком. Эффективность сотрудничества, соответствие выполняемой работы требованиям заказчика гарантируются регулярными визитами к клиенту ответственных лиц на всем протяжении работ по проекту, отчетами и докладами о статусе проекта.
Потребность в альтернативе классическим (монументальным) методологиям, которые в основном основаны на документации, привела к тому, что в 2001 году был проведен семинар, куда были приглашены представители различных адаптивных (гибких) методологий. Результатом работы стал манифест гибкой разработки ПО (Manifest for Agile Software Development)
Более подробно остановимся на адаптивных (гибких) методологиях, так как они наиболее активно развиваются и используются в настоящее время.
Методология SCRUM.
Данная методология предназначена для небольших команд разработчиков. Проект начинается с создания "резерва свойств системы" (backlog). Резерв свойств - это набор функций системы, которые необходимо реализовать. Сами функции могут быть описаны с помощью пользовательских сценариев или более традиционных требований. Контроль над резервом имеет только один человек, обычно это заказчик системы. Резерв постоянно изменяется, функции дополняются и сортируются по приоритетам.
После того, как резерв будет немного наполнен, начинается первая итерация. Весь проект делится на итерации (спринты) длительностью в 30 дней. Длительность итерации можно варьировать, это зависит от конкретного проекта. Для одной итерации выбирают функции, которые будут в ней реализованы. Самое важное условие - неизменность выбранных функций во время одной итерации. Это позволяет разбить весь большой проект с изменяющимися требованиями на некоторое количество фиксированных небольших итераций со стабильными требованиями.
Запланированная дата окончания итерации должна жестко соблюдаться. Команда может не реализовать некоторые из выбранных для итерации функций, но дату окончания итерации переносить нельзя.
Отличительной чертой SCRUM является проведение ежедневных 15-30 минутных совещаний, которые так и называются scrum (потасовка). В ходе этих совещаний лидер команды задает каждому следующие вопросы:
Что удалось сделать из выбранных для данной итерации функций за прошедший день?
Были ли какие-либо проблемы с реализацией?
Что планируется сделать за сегодняшний день?
Это позволяет четко отслеживать ход проекта, быстро обнаруживать возникающие проблемы и, соответственно, быстро реагировать на них.
В конце спринта команда представляет работающий продукт с запланированной функциональностью. После этого устраивается совещание, на котором обсуждаются все неожиданные моменты, с которыми столкнулись разработчики, и планируется следующая итерация. Кроме того, на этом совещании можно изменять приоритеты и вообще все изменять.
Дата добавления: 2018-02-15; просмотров: 1192; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!