Пакет Visible Analyst Workbench (Visible Systems)

Visible Analyst Workbench представляет собой сетевое многопользовательское средство проектирования информационных систем, базирующееся на репозитарии, хранимом на сервере SQLBase, Oracle или Informix. Пакет основан на методологии Мартина и поддерживает следующие диаграммные техники:

диаграммы функциональной декомпозиции

диаграммы потоков данных в нотациях Йодана и Гейна-Сарсона

диаграммы “сущность-связь”

структурные карты в нотации Константайна.

Пакет обеспечивает генерацию схем БД для вышеперечисленных СУБД и поддерживает технологию FRE. Имеется возможность экспорта проектов в системы SQLWindows, PowerBuilder и Uniface.

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

ЗАКЛЮЧЕНИЕ

Деятельность Дж. Мартина принесла огромное значение. В середине 80-х годов на фирме Du Pont был формализован подход к разработке информационных систем, использующий последовательный выпуск прототипов системы, жесткие ограничения по времени и вовлечение конечных пользователей системы в ее разработку. После публикации в 1991г. книги Дж. Мартина «Rapid Application Development» (быстрая разработка приложений) этот подход получил широкую известность как RAD-технология. Технология RAD более всего подходит при разработке интерактивных приложений, в которых функциональные возможности реализуются на уровне пользовательского интерфейса. Четко определяется группа пользователей такого приложения. Большие приложения подвергаются разбиению на более мелкие функциональные компоненты.

В основе RAD-технологии лежали следующие положения:

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

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

Система разрабатывается небольшой командой из 4—б человек, включая 1—2 представителей пользователей. Члены команды должны быть уполномочены принимать необходимые решения. Во время разработки проекта состав команды практически не меняется, что позволяет уменьшить необходимость в промежуточной документации.

Разработка ведется итерациями при тесном вовлечении пользователей на протяжении всего цикла разработки системы. Основную роль играет правило 80/20, которое гласит, что 80 % работы может быть выполнено за 20 % времени, затрачиваемого на всю работу. Это означает, что нет смысла прикладывать усилия на тонкую настройку системы, когда еще до конца не определены основные требования к ней. Каждый шаг должен быть закончен настолько, насколько это необходимо для выполнения следующей работы.

На срок выпуска каждого прототипа накладываются жесткие ограничения по времени, превышать которые не разрешается. По истечении установленного срока прототип предъявляется заказчику для обсуждения.

Тестирование выполняется постепенно на протяжении всего жизненного цикла системы.

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

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

ИСПОЛЬЗОВАННАЯ ЛИТЕРАТУРА:

1. Мартин Дж. Организация баз данных в вычислительных системах. М.: Мир, 2014, 662 с.

2. Мартин Дж. Планирование развития автоматизированных систем. - М.: "Финансы и статистика", 2015.

3. interface/fset.asp?Url=/case/defs8.htm

4. techno.edu:16001/db/msg/15641.html