Методологии и технологии проектирования информационных систем.

Общие требования к методологи и технологии.

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

Технология проектирования определяется как совокупность трех составляющих:

1)Пошаговой процедуры, определяющей последовательность технологических операций проектирования;

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

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

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

Технология проектирования, разработки и сопровождения ИС должна удовлетворять следующим общим требованиям:

1)Технология должна поддерживать полный ЖЦПО.

2) Технология должна обеспечивать гарантированные достижения, цели разработки ИС с заданным качеством и в установленное время.

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

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

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

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

Здесь речь идет о сроках реализации отдельных подсистем. Реализация ИС в целом в короткие сроки может потребовать привлечение большого числа разработчиков. При этом эффект может оказаться ниже, чем при реализации в более короткие сроки отдельных подсистем меньшим числом разработчиков.

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

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

6) Технология должна обеспечивать независимость выполняемых проектных решений от средств реализации ИС. Технология должна быть поддержана комплексом согласованных Case-средств, обеспечивающих автоматизацию процесса, выполняемых на всех стадиях ЖЦ.

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

К таким стандартом относятся:

а)Стандарт проектирования.

б) Стандарт оформления проектной документации.

в) Стандарт последовательного интерфейса.

Стандарт проектирования должен устанавливать:

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

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

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

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

Стандарт оформления проектной документации должен устанавливать:

1)Комплектность, состав и структуру документации на каждой стадии проектирования.

2) Требования к оформлению документации, включая требования к содержанию разделов, подразделов, пунктов, таблиц и т. д.

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

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

5) Требования к настройке Case-средств для обеспечения подготовки документации в соответствии с установленными требованиями.

Стандарт интерфейса пользователя должен устанавливать:

1)Правила оформления экранов (шрифты, цветовая палитра, состав и расположение окон и элементов управления).

2) Правила использования клавиатуры и мыши.

3) Правила оформления текстов помощи.

4) Перечень стандартных сообщений.

5) Правила обработки реакции пользователя.

 

Методология RAD.

Одним из возможных подходов к разработке ПО, в рамках спиральной модели ЖЦ, является метод быстрой разработки приложений RAD (Rapid Application Development).

Под ним, обычно понимается процесс разработки ПО, содержащего 3 элемента:

1. небольшую команду программистов;

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

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

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

ЖЦ ПО, по методологии RAD, состоит из 4 фаз:

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

Результат фазы: список приоритетов функций будущей ИС. Предварительное функциональное и информационное моделирование ИС.

2. Фаза проектирования. Часть пользователей принимает участие в техническом проектировании системы под руководством специалистов – разработчиков. CASE- средства используются для быстрого получения работающих прототипов приложения. Пользователи, взаимодействуя с ними, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей фазе. Более подробно рассматриваются процессы системы. Анализируется и корректируется функциональная модель. Каждая процедура рассматривается более детально. При необходимости для каждого элемента процедуры создаётся частичный прототип, устраняются неясности или неоднозначности. Определяются требования к разграничению доступа к данным. Определяется набор необходимой документации. Оценка количества функциональных элементов. Принимается решение о разделе ИС на подсистемы, поддающиеся обработки одной команды разработчиков за приемлемое время (60 – 90 дней). С использованием CASE- средств проект распределяется между разработчиками.

Результат фазы:

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

2. функциональные модели в целом и подсистем, реализованные командами разработчиков;

3. точно определённые, с помощью CASE- средств интерфейсы между подсистемами;

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

Все модели и прототипы должны быть получены с применением CASE- средств, которые будут использованы в дальнейшем при построении системы. Это требование вызвано тем, что при передаче информации с этапа на этап может произойти неконтролируемое искажение данных. Применение единой среды хранения информации о проекте позволит этого избежать. В отличие от традиционных подходов (использование специфических средств прототипирования не предназначенных для построения реальных приложений) в методологии RAD каждый прототип развивается как часть бедующей системы. Таким образом на следующую фазу передаётся более полная и полезная информация.

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

Завершение физического проектирование системы:

1. определяется необходимость распределённых данных;

2. анализ используемых данных;

3. производится физическое проектирование БД;

4. определяются требования к аппаратным ресурсам;

5. определяются способы повышения производительности;

6. завершение разработки документации проекта.

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

4. Фаза внедрения. Обучение пользователей. Внедрение новой системы и обслуживание существующих систем.

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

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

1. <1000 функциональных элементов – один человек;

2. 1000 – 4000 функциональных элементов – одна команда разработчиков;

3. >4000 функциональных элементов – 4000 функциональных элементов на одну команду разработчиков.

Основные принципы методологии RAD:

1. разработка приложений итерациями;

2. необязательно полное завершение работ на каждом этапе ЖЦ;

3. обязательное вовлечение пользователей в процесс разработки ИС;

4. необходимость применения CASE- средств, обеспечивающих целостность проекта;

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

6. необходимость использования генераторов кода;

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

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

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

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