Методология и технология разработки информационных систем (стр. 5 из 8)

В ASD обычный статический жизненный цикл "Планирование - Проектирование - Конструирование" заменен на динамический "Обдумывание - Взаимодействие - Обучение".

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

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

Функционально-ориентированная разработка (Feature Driven Development или FDD).

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

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

разработка общей модели;

составление списка необходимых функций системы;

планирование работы над каждой функцией;

проектирование функции;

конструирование функции.

Разработчики в FDD делятся на "хозяев классов" и "главных программистов". Главные программисты привлекают хозяев задействованных классов к работе над очередным свойством. Для сравнения, в ХР нет персонально ответственных за классы или методы. К работе над любым классом может привлекаться любой из участников разработки.

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

Метод разработки динамических систем (Dynamic System Development Method или DSDM).

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

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

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

DSDM неприменима если:

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

не определена группа пользователей;

проект зависит от сложных внутренних вычислений.

Основные принципы DSDM:

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

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

Требования заказчика - прежде всего.

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

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

Все изменения обратимы (возвращение - основная черта DSDM).

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

Глава 3. Технология разработки информационных систем

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

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

поддерживать полный жизненный цикл информационной системы;

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

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

технология должна обеспечивать возможность ведения работ по проектированию отдельных подсистем небольшими группами (3-7 человек);

обеспечивать минимальное время получения работоспособной системы;

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

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

Технологии характеризуются в двух измерениях: вертикальном (представляющем процессы) и горизонтальном (представляющем стадии).

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

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

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

Существуют несколько технологических подходов.

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

Строгие (классические, жесткие, предсказуемые) подходы применяют для средних, крупно-масштабных и гигантских проектов с относительно ясными требованиями к системе и более-менее фиксированным объемом работ. Одно из основных требований к таким проектам - как можно большая предсказуемость. В эту группу входят следующие подходы: [8]

Каскадные технологические подходы.

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

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

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

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

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

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

Каркасные подходы.

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