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

Методы и концепции.

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

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

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

Классификация по реализационной специфике методологий

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

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

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

Смешанные методологии.

Смешанные методологии включают объединение методов нескольких методологий. Наиболее часто объединяются методологии функционального и логического программирования. Существуют исследовательские работы в области объединения объектно-ориентированного и логического программирования. Ряд исследований посвящен вопросам унификации методологий программирования.

Петров В.Н. в своей книге "Технологии разработки программного обеспечения" приводит еще одну методологию - RAD (Rapid Application Development).

Методология быстрой разработки приложений RAD.

На начальном этапе существования компьютерных информационных систем их разработка велась на традиционных языках программирования. Однако по мере возрастания сложности разрабатываемых систем и увеличения запросов пользователей потребовались новые средства, обеспечивающие значительное сокращение сроков разработки. Это послужило предпосылкой к созданию целого направления в области программного обеспечения - инструментальных средств для быстрой разработки приложений. Развитие этого направления привело к появлению на рынке программного обеспечения средств автоматизации практически всех этапов жизненного цикла информационных систем. Эти средства приобрели название методологии быстрой разработки приложений RAD (Rapid Application Development).

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

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

небольшой команде программистов (обычно от 2 до 10 человек);

тщательно проработанный производственный график работ, рассчитанных сравнительно короткий срок разработки (от 2 до 6 мес);

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

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

используется итерационная (спиральная) модель разработки;

полное завершение работ на каждом из этапов жизненного цикла не обязательно;

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

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

тестирование и развитие проекта осуществляются одновременно с разработкой;

разработка ведется немногочисленной и хорошо управляемой командой профессионалов;

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

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

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

2.2 Методологии разработки информационных систем в зарубежной литературе

Формально методологии можно разделить на два типа - классические (монументальные, предсказуемые, где все этапы детально проектируется заранее и не допускается отклонение от первоначального плана) и их противоположность - адаптивные (гибкие, где в процессе работы допустимо и даже типично перепроектирование). В зависимости от начальных условий и характера поставленной задачи, может применяться как классическая, так и адаптивная методология (Рис.4).

Классическая (монументальная) методология применяется, если:

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

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

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

Итерационный процесс на данном этапе смещен в область анализа, проектирования и разработки технического задания, процесс разработки строго документирован и линеен. Срок создания технического задания составляет около 60% времени от всего процесса разработки.

Адаптивная (agile - гибкая или lightweight - легкая) методология применяется, если:

Не ясны или изменяются требования к системе.

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

Необходимо как можно быстрее получить первые версии работающей программы.

Решаемая программой задача трудно поддается документированию.

На реализацию всех требований есть достаточный запас времени.

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

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

Используется система контроля версий.

Оформление кода стандартизировано.

Первоочередное исправления ошибок перед внесением любых других изменений.

Выполняется регулярное резервное копирование всех проектных данных.

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