Курсовая работа: Методология и технология разработки информационных систем

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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