Основные виды работ, рекомендуемые при построении логической и физической моделей программной системы

1) Проведение функционального и информационного обследования предметной области, которая включает:

1. Определение организационной и топологической структуры организации.

2. Определение перечня функций организации.

3. Проведение анализа распределения функций по подразделениям и сотрудникам.

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

2) Разработка функциональной модели деятельности организации, которая включает:

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

2. Оценка объемов и интенсивности информационных потоков.

3. Разработка иерархий и диаграмм потоков данных.

4. Проведение архивизации структуры функциональной модели.

3) Разработка информационной модели включает:

1. Определение сущностей модели и их атрибутов.

2. Проведение анализа атрибутов и оптимизация их сущностей.

3. Идентификация отношений между сущностями.

4. Определение типов отношений.

5. Разрешение неспецифических отношений.

6. Анализ и оптимизация построенной информационной модели.

4) Разработка событийной модели включает:

1. Идентификацию перечня состояний модели.

2. Определение возможных переходов между состояниями.

3. Определение условий, активизирующих переходы и сопровождающих переходы действий.

4. Анализ и оптимизация событийной модели.

5) Разработка предложений по реорганизации предметной области включает:

1. Составление перечня рабочих мест и способов взаимодействия между ними.

2. Разработку требований к техническим средствам.

3. Разработку требований к программным средствам.

4. Разработку предложений по средствам взаимодействия подразделений.

5. Разработку предложений по этапам и срокам оптимизации.

Таким образом, фактически будет построено две модели:

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

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

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

1) Описать, увидеть и скорректировать будущую программную систему до ее реализации.

2) Уменьшить затраты на разработку и внедрение системы, оценить разработку по времени и по результатам.

3) Достичь взаимопонимания между заказчиками, пользователями, разработчиками, программистами и т. д.

4) Улучшить качество разработки системы за счет создания качественной структуры базы данных и выполнения функциональной декомпозиции типовых модулей.

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

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

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

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

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

5) модель можно использовать для корректировки программных средств отделов автоматизации предприятия.

Подход Мартина (IE–методология)

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

Основные этапы подхода Мартина:

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

2) Анализ процессов. На этом этапе основные процессы, разработанные на первом этапе, используются для разбиения общей задачи на частные. Для частных задач определяется информационная и функциональная модели. При этом диаграммы сущность-связь становятся нормализованными моделями данных. Для соотнесения данных и процессов в методологии Мартина предлагается использовать матрицы сущность-процесс.

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

4) Этап физического проектирования и реализации. На данном этапе выполняются преобразования логической модели информационной системы в физическую модель.

Вопросы для самоконтроля по теме 4:

1. Опишите основные этапы построения информационной модели данных.

2. Перечислите основные виды работ, рекомендуемые при построении логической модели программной системы.

3. Охарактеризуйте основные этапы подхода Мартина.

Тема 5. Методология RAD (Rapid Application Development)

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

Процесс разработки программного обеспечения в соответствии с методологией RAD имеет следующие особенности:

1) команда разработчиков включает от двух до десяти человек;

2) планы работ тщательно прорабатываются и обычно составляют от двух до шести месяцев;

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

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

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

1) фаза анализа и планирования требований;

2) фаза проектирования;

3) фаза построения;

4) фаза внедрения.

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

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

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

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

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

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

1) общая информационная модель системы;

2) функциональная модель системы в целом;

3) модели подсистем, реализуемых отдельными коллективами разработчиков;

4) определяемые с помощью CASE-средств интерфейсы между системами;

5) построенные прототипы экранов, отчетов, диалогов.

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

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

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

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

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

Результатом построения является готовая система, удовлетворяющая всем требованиям.

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

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

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

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

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

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

Оценка размеров приложения в соответствии с методологией RAD осуществляется на основе функциональных элементов. Функциональный элемент программной системы – это файл, форма, отчет или сообщение. Размер приложения определяется следующим образом. Если в программной системе имеется до 1 тыс. программных элементов, то реализация системы может выполняться 1 человеком. Если от 1 до 4 тыс. программных элементов, то разработка выполняется командой от 2 до 10 человек. Если более 4 тыс. элементов, то разработка системы осуществляется несколькими командами, каждая из которых разрабатывает до 4 тыс. функциональных элементов.