Проектированием информационных систем называется многоступенчатый процесс их создания и/или модернизации путём применения упорядоченной совокупности методологий и инструментария. Проектирование (в отличие от моделирования) предполагает работу с пока несуществующим объектом и направлено на создание информационной системы в области:

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

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

Цель проектирования информационной системы и связанные понятия

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

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

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

Организация проектирования ИС

Организацию проектирования ИС принято разделять на 2 типа:

Каноническое проектирование отражает особенности технологии оригинального (индивидуального) процесса.
Типовое проектирование, для которого характерно типовое проектное решение (ТПР), тиражируется и пригодно к многократному использованию.

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

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

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

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

Этапы, в случае необходимости, можно укрупнять или детализировать – объединять последовательные этапы, исключать «лишние», начинать выполнение очередной стадии до завершения предыдущей.

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

Декомпозиция может иметь несколько уровней, что позволяет выделить классы ТПР:

элементные – по отдельной задаче (элементу),
подсистемные – по отдельным подсистемам,
объектные – отраслевые типовые проектные решения, содержащие весь набор подсистем.

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

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

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

Основные методологии проектирования ИС

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

SADT . Методология функционального моделирования работ, которая основана на структурном анализе и графическом представлении организации как системы функций. Тут выделяется функциональная, информационная и динамическая модели. В настоящее время методология известна как нотация (стандарт) IDEF0. Анализируемый процесс графически представляется в виде четырёхугольника, где сверху изображаются регламентирующие и управляющие воздействия, снизу – объекты управления, слева – входные данные, а справа – выходные.
RAD . Методология быстрой разработки приложений. В RAD быстрая разработка приложений возможна за счёт применения компонентно-ориентированного конструирования. Методология применяется на проектах с ограниченным бюджетом, нечёткими требованиями к ИС, при сжатых сроках реализации. К ней прибегают, если пользовательский интерфейс можно продемонстрировать в прототипе, а проект разделить на функциональные элементы.
RUP . В методологии RUP реализуются итерационный и наращиваемый (инкрементный) подходы. Построение системы происходит на базе архитектуры информационной системы, а планирование и проектное управление – на базе функциональных требований к ИС. Разработка общей информационной системы происходит итерациями, как комплекс отдельных небольших проектов со своими планами и задачами. Для итерационного цикла характерна периодическая обратная связь и адаптация к ядру ИС.

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

Согласно статистическим данным, собранным Standish Group (США), из 8380 проектов, обследованных в США в 1994 году, неудачными оказались более 30% проектов, общая стоимость которых превышала 80 миллиардов долларов. При этом оказались выполненными в срок лишь 16% от общего числа проектов, а перерасход средств составил 189% от запланированного бюджета. В то же время, заказчики ИС стали выдвигать все больше требований, направленных на обеспечение возможности комплексного использования корпоративных данных в управлении и планировании своей деятельности. Таким образом, возникла насущная необходимость формирования новой методологии построения информационных систем.

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

Проектирование ИС охватывает три основные области: проектирование объектов данных, которые будут реализованы в базе данных; проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным; учет конкретной среды или технологии, а именно: топологии сети, конфигурации аппаратных средств, используемой архитектуры (файл-сервер или клиент- сервер), параллельной обработки, распределенной обработки данных и т.п.

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

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

Начальным этапом процесса создания ИС является моделирование бизнес-процессов, протекающих в организации и реализующих ее цели и задачи. Модель организации, описанная в терминах бизнес-процессов и бизнес-функций, позволяет сформулировать основные требования к ИС. Это фундаментальное положение методологии обеспечивает объективность в выработке требований к проектированию системы. Множество моделей описания требований к ИС затем преобразуется в систему моделей, описывающих концептуальный проект ИС. Формируются модели архитектуры ИС, требований к программному обеспечению (ПО) и информационному обеспечению (ИО). Затем формируется архитектура ПО и ИО, выделяются корпоративные БД и отдельные приложения, формируются модели требований к приложениям и проводится их разработка, тестирование и интеграция. Целью начальных этапов создания ИС, выполняемых на стадии анализа деятельности организации, является формирование требований к ИС, корректно и точно отражающих цели и задачи организации-заказчика. Чтобы специфицировать процесс создания ИС, отвечающей потребностям организации, нужно выяснить и четко сформулировать, в чем заключаются эти потребности. Для этого необходимо определить требования заказчиков к ИС и отобразить их на языке моделей в требования к разработке проекта ИС так, чтобы обеспечить соответствие целям и задачам организации.

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

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

Кроме того, на этапе проектирования осуществляется также разработка архитектуры ИС, включающая в себя выбор платформы (платформ) и операционной системы (операционных систем). В неоднородной ИС могут работать несколько компьютеров на разных аппаратных платформах и под управлением различных операционных систем. Кроме выбора платформы, на этапе проектирования определяются следующие характеристики архитектуры: будет ли это архитектура "файл-сервер" или "клиент-сервер"; будет ли это 3-уровневая архитектура со следующими слоями: сервер, ПО промежуточного слоя (сервер приложений), клиентское ПО; будет ли база данных централизованной или распределенной. Если база данных будет распределенной, то какие механизмы поддержки согласованности и актуальности данных будут использоваться; будет ли база данных однородной. Если база данных не будет однородной, то какое ПО будет использовано для обмена данными между СУБД разных производителей (уже существующее или разработанное специально как часть проекта); будут ли для достижения должной производительности использоваться параллельные серверы баз данных (например, Oracle Parallel Server, DB2 UDB и т.п.). Этап проектирования завершается разработкой технического проекта ИС. На этапе реализации осуществляется создание программного обеспечения системы, установка технических средств, разработка эксплуатационной документации.

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

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

Жизненный цикл программного обеспечения ИС ЖЦ ПО ИС это непрерывный процесс, который начинается с момента принятия решения о необходимости создания ИС и заканчивается в момент его полного изъятия из эксплуатации. Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC (ISO Международная организация по стандартизации, IEC Международная комиссия по электротехнике).

Структура ЖЦ ПО по стандарту ISO/IEC базируется на трех группах процессов: основных процессах ЖЦ ПО (приобретение, поставка, разработка, эксплуатация, сопровождение); вспомогательных процессах, обеспечивающих выполнение основных процессов (документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, оценка, аудит, решение проблем); организационных процессах (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение).

Разработка проекта включает в себя все работы по созданию ПО и его компонентов в соответствии с заданными требованиями, включая оформление проектной и эксплуатационной документации, подготовку материалов, необходимых для проверки работоспособности и соответствующего качества программных продуктов, материалов, необходимых для организации обучения персонала, и т.д. В разработку ПО входят, как правило, анализ, проектирование и реализация (программирование).

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

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

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

Модели жизненного цикла ПО Стандарт 1SО/1ЕС не предлагает конкретную модель ЖЦ и методы разработки ПО. Под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует. Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы. К настоящему времени наибольшее распространение получили следующие основные модели ЖЦ: каскадная модель; спиральная модель; итерационная модель.

Каскадная модель Каскадная модель, которую иногда называют моделью "водопада" (waterfall model). Каскадная модель была предложена Уинстоном Рейсом в 1970 году В изначально существовавших однородных ИС каждое приложение представляло собой единое целое. Для разработки такого типа приложений применялся каскадный способ. Его основной характеристикой является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем. Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.

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

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

Спиральная модель. Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ, делающая упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом, углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации. Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, при этом необязательно ждать полного завершения работы на текущем. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная же задача как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований.

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

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

Естественное развитие каскадной и спиральной моделей привело к их сближению и появлению современного итерационного подхода, который представляет рациональное сочетание этих моделей. Итерационная модель. Создание ИС предполагает проведение увязки проектных решений, получаемых при реализации отдельных задач. Подход к проектированию снизу-вверх обусловливает необходимость таких итерационных возвратов, когда проектные решения по отдельным задачам комплектуются в общие системные решения, и при этом возникает потребность в пересмотре ранее сформулированных требований. Как правило, вследствие большого числа итераций возникают рассогласования в выполненных проектных решениях и документации. Запутанность функциональной и системной архитектуры созданной ИС, трудность в использовании проектной документации вызывают на стадиях внедрения и эксплуатации сразу необходимость перепроектирования всей системы. Длительный жизненный цикл разработки ИС заканчивается этапом внедрения, за которым начинается жизненный цикл создания новой ИС. Различные варианты итерационного подхода реализованы в большинстве современных технологий и методов: Rational Unified Process (RUP), Microsoft Solutions Framework (MSF) и Extreme Programming (XP).

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

MSF сходна с RUP, так же включает четыре фазы: анализ, проектирование, разработка, стабилизация, является итерационной, предполагает использование объектно-ориентированного моделирования. MSF в сравнении с RUP в большей степени ориентирована на разработку бизнес- приложений. Экстремальное программирование (ХР) является самым новым среди рассматриваемых методологий, сформировалось в 1996 году. В основе методологии лежит командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС, а разработка ведется с использованием последовательно дорабатываемых прототипов.

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

Существует две основных методологии проектирования:

Методология структурного проектирования;

Методология объектно-ориентированного проектирования.

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

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

Наиболее распространенные модели структурного подхода:

SADT - Structured Analysis and Design Techniques - описывает модели и функциональные диаграммы;

DFD - Data Flow Diagrams - диаграммы потоков данных;

ERD - Entity Relationship Diagrams - диаграммы «сущность - связь».

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

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

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

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

Для реализации проекта был выбран объектно-ориентированный подход в силу следующих факторов:

Возможность повторного использования кода;

Повышение безопасности кода за счет инкапсуляции;

Гибкость при модификации и расширении системы;

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

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

2. Intranet/Internet технологии в геодезии (технологии клиент/сервер).

3. Функциональные модели информационных объектов и бизнес-

Экзаменационный билет n 11

1. Кодирование информации, методы передачи информации, данные.

2. Теодолитная и тахеометрическая съемки.

3. Практический менеджмент информационных продуктов и

Экзаменационный билет n 12

1. Мировые информационные ресурсы.

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

3. Принципы оценки инженерно-геодезических работ.

Экзаменационный билет n 13

1. Web- ресурсы, методы поиска информации в Internet.

2. Организация хранения информационных ресурсов, вопросы

3. Проекции, применяемые при решении задач геодезии

Экзаменационный билет n 14

1. Операционные системы (ос): классификация, требования к порядку

2. Методы космической геодезии. Методы космической геодезии

3. Автоматизированное проектирование ис.

Экзаменационный билет n 15

1. Сервисы по: драйверы, интерфейсы, редакторы, средства передачи

2. Растровая и векторная графика в геодезии и картографии.

3. Архитектура микропроцессорных и компьютерных систем

1.4. Архитектура микропроцессорных систем

Вопрос 1

Экзаменационный билет n 16

Экзаменационный билет n 17

1. Жизненный цикл по.

2. Организационные методы защиты ис.

3. Фундаментальные геодезические постоянные.

Экзаменационный билет n 18

1. Геодезические приборы для измерений расстояний.

2. Нормативно-правовая база организации защиты информации.

3. Основы построения государственной геодезической сети (ггс) рф.

Экзаменационный билет n 19

2. Информационная инфраструктура предприятия (клиентская сеть).

3. Авторские права на профессиональные базы данных.

Экзаменационный билет n 20

2. Система государственной кодификации информационных ресурсов в

3. Проектирование гис.

Экзаменационный билет n 21

1. Средства линейных измерений в ггс.

2. Ис в геодезической и картографической сферах.

3. Порядок решения задач; обработка и хранение результатов, средства

Экзаменационный билет n 22

1. Web – дизайн.

Этапы проектирования Дизайн основной и типовых страниц сайта

2. Определение площадей. Электронные способы измерения площадей.

Экзаменационный билет n 23

1. Web – документы.

2. Автоматизированные ис.

3. Основы построения государственной геодезической сети (ггс) рф.

Экзаменационный билет n 24

1. Организация государственной геодезической службы в России.

2. Основные определения надежности ис.

3. Стандартизация сетей (iso, osi, эмвос – эталонная модель

Эталонная модель

Экзаменационный билет n 25

1. Топографические карты, номенклатура карт и планов.

Разбиение листа 1:1 000 000 на листы масштаба 1:200 000

Разбиение листа 1:1000000 на листы масштаба 1:100000

Приведем соответствие

2. Инженерно-техническая и физическая защита объектов в ис.

3. Клиентские сети; технологии «последней мили», сравнение технологий подключения клиентов.

Экзаменационный билет n 26

1. Ориентирование. Ориентирные углы, связь между ними.

Азимуты, румбы, дирекционные углы и зависимости между ними

2. Надежность, стандартизация и управления качеством в геодезии.

Государственный геодезический надзор

О строительных допусках

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

Определения

Стандарты в области информационной безопасности

Экзаменационный билет n 27

1. Рельеф местности и его изображение на топографических картах.

Методы изображения рельефа на планах и картах

Горизонтали

Чем меньше высота сечения, тем точнее должна быть выполнена работа по съемке рельефа.

3.Управление интеллектуальной собственностью предприятий и

Управление интеллектуальной собственностью предприятий и организаций.

Виды интеллектуальной собственности Авторское право

Смежные права

Виды нарушений права интеллектуальной собственности

Международная защита интеллектуальной собственности

Законодательство России в сфере интеллектуальной собственности

Экзаменационный билет n 28

1. Электронные способы измерения расстояний. Электронные способы измерения расстояний

Измерение длины линий дальномерами

2. Классификация методов проектирования ис. Классификация методов проектирования ис

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

Экзаменационный билет n 29

1. Понятие, определение информационной системы (ис).

Классификации информационных систем Классификация по архитектуре

Классификация по степени автоматизации

Классификация по характеру обработки данных

Классификация по сфере применения

Классификация по охвату задач (масштабности)

2. Определение компьютерных сетей, соединительных сетей

Классификация По территориальной распространенности

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

3. Методы оценки точности результатов геодезических измерений.

Экзаменационный билет n 30

1. Структура ис.

2. Основы криптографии, стеганографии, шифрования, хеширования, как способы защиты информации.

3. Ис обработки и представления данных (карты, планы и т.П.)

Экзаменационный билет n 31

Экзаменационный билет n 32

2. Классификация методов проектирования ис. Классификация методов проектирования ис

Информационная система (ИС) - это система, предназначенная для сбора, хранения и обработки информации.

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

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

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

поддерживать удобную дисциплину сопровождения, модификации и наращивания системы;

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

Проектирование ИС охватывает три основные области:

проектирование объектов данных, которые будут реализованы в базе данных;

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

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

Существует три основных метода проектирования ИС:

Каноническое проектирование.

Типовое проектирование.

Проектирование с помощью Case-технологий.

Каноническое проектирование ИС

Организация канонического проектирования ИС ориентирована на использование главным образом каскадной модели жизненного цикла ИС. Стадии и этапы работы описаны в стандарте ГОСТ 34.601-90.

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

Стадии и этапы создания ИС, выполняемые организациями-участниками, прописываются в договорах и технических заданиях на выполнение работ:

Стадия 1. Формирование требований к ИС.

На начальной стадии проектирования выделяют следующие этапы работ:

обследование объекта и обоснование необходимости создания ИС;

формирование требований пользователей к ИС;

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

Стадия 2. Разработка концепции ИС.

изучение объекта автоматизации;

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

разработка вариантов концепции ИС, удовлетворяющих требованиям пользователей;

оформление отчета и утверждение концепции.

Стадия 3. Техническое задание.

разработка и утверждение технического задания на создание ИС.

Стадия 4. Эскизный проект.

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

разработка эскизной документации на ИС и ее части.

Стадия 5. Технический проект.

разработка проектных решений по системе и ее частям;

разработка документации на ИС и ее части;

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

разработка заданий на проектирование в смежных частях проекта.

Стадия 6. Рабочая документация.

разработка рабочей документации на ИС и ее части;

разработка и адаптация программ.

Стадия 7. Ввод в действие.

подготовка объекта автоматизации;

подготовка персонала;

комплектация ИС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями);

строительно-монтажные работы;

пусконаладочные работы;

проведение предварительных испытаний;

проведение опытной эксплуатации;

проведение приемочных испытаний.

Стадия 8. Сопровождение ИС.

выполнение работ в соответствии с гарантийными обязательствами;

послегарантийное обслуживание.

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

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

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

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

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

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

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

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

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

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

Типовое проектирование ИС.

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

Типовое проектное решение (ТПР)- это тиражируемое (пригодное к многократному использованию) проектное решение. Принятая классификация ТПР основана на уровне декомпозиции системы. Выделяются следующие классы ТПР:

элементные ТПР - типовые решения по задаче или по отдельному виду обеспечения задачи (информационному, программному, техническому, математическому, организационному);

подсистемные ТПР - в качестве элементов типизации выступают отдельные подсистемы, разработанные с учетом функциональной полноты и минимизации внешних информационных связей;

объектные ТПР - типовые отраслевые проекты, которые включают полный набор функциональных и обеспечивающих подсистем ИС.

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

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

Критерии оценки ППП делятся на следующие группы:

назначение и возможности пакета;

отличительные признаки и свойства пакета;

требования к техническим и программным средствам;

документация пакета;

факторы финансового порядка;

особенности установки пакета;

особенности эксплуатации пакета;

помощь поставщика по внедрению и поддержанию пакета;

оценка качества пакета и опыт его использования;

перспективы развития пакета.

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

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

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

Типовая ИС в специальной базе метаинформации - репозитории - содержит модель объекта автоматизации, на основе которой осуществляется конфигурирование программного обеспечения. Таким образом, модельно-ориентированное проектирование ИС предполагает, прежде всего, построение модели объекта автоматизации с использованием специального программного инструментария (например, SAP Business Engineering Workbench (BEW), BAAN Enterprise Modeler). Возможно также создание системы на базе типовой модели ИС из репозитория, который поставляется вместе с программным продуктом и расширяется по мере накопления опыта проектирования информационных систем для различных отраслей и типов производства.

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

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

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

Модель конкретного предприятия строится либо путем выбора фрагментов основной или типовой модели в соответствии со специфическими особенностями предприятия (BAAN Enterprise Modeler), либо путем автоматизированной адаптации этих моделей в результате экспертного опроса (SAP Business Engineering Workbench).

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

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

Модель бизнес-функций представляет собой иерархическую декомпозицию функциональной деятельности предприятия (подробное описание см. в разделе "Анализ и моделирование функциональной области внедрения ИС").

Модель бизнес-процессов отражает выполнение работ для функций самого нижнего уровня модели бизнес-функций (подробное описание см. в разделе "Спецификация функциональных требований к ИС"). Для отображения процессов используется модель управления событиями (ЕРС - Event-driven Process Chain). Именно модель бизнес-процессов позволяет выполнить настройку программных модулей - приложений информационной системы в соответствии с характерными особенностями конкретного предприятия.

Модели бизнес-объектов используются для интеграции приложений, поддерживающих исполнение различных бизнес-процессов (подробное описание см. в разделе "Этапы проектирования ИС с применением UML").

Модель организационной структуры предприятия представляет собой традиционную иерархическую структуру подчинения подразделений и персонала (подробное описание см. в разделе "Анализ и моделирование функциональной области внедрения ИС").

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

Реализация типового проекта предусматривает выполнение следующих операций:

установку глобальных параметров системы;

задание структуры объекта автоматизации;

определение структуры основных данных;

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

описание интерфейсов;

настройку системы архивирования.

CASE-технологии.

CASE-средства автоматизации – это методологий структурного системного анализа и проектирования ИС . Основные компоненты интегрированного CASE-пакета: 1) средства централизованного хранения всей информации о проектируемом программном обеспечении в течение всего жизненного цикла (репозитарий); 2) средства ввода; 3) средства анализа; 4) средства вывода - требования к компонентам и к их поддержке.

CASE-средства служат инструментарием для поддержки и усиления методов структурного анализа и проектирования. Эти инструменты поддерживают работу пользователей при создании и редактировании графического проекта в интерактивном режиме, они способствуют организации проекта в виде иерархии уровней абстракции, выполняют проверки соответствия компонентов. Фактически CASE-средства представляют собой новый тип графически-ориентированных инструментов, восходящих к системе поддержки ЖЦ ИС. Обычно к ним относят любое программное средство, обеспечивающее автоматическую помощь при разработке ПО, его сопровождении или деятельности по управлению проектом, и проявляющее следующие дополнительные черты:

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

Помимо перечисленных основополагающих принципов графической ориентации, интеграции и

локализации всей проектной информации в репозитарии в основе концептуального построения

CASE-средств лежат следующие положения:

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

Широкое использование базовых программных средств, получивших массовое распространение в других приложениях (БД и СУБД, компиляторы с различных языков программирования, отладчики, документаторы, издательские системы, оболочки экспертных систем и базы знаний, языки четвертого поколения и др).

Автоматизированная или автоматическая кодогене-рация, выполняющая несколько видов генерации кодов: преобразования для получения документации, формирования БД, ввода/модификации данных, получения выполняемых машинных кодов из спецификаций ПО, автоматической сборки модулей из словарей и моделей данных и повторно используемых программ, автоматической конверсии ранее используемых файлов в форматы новых требований.

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

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

Рентабельность.

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

Интегрированный CASE-пакет содержит четыре основные компонента:

Средства централизованного хранения всей информации о проектируемом ПО в течении всего

ЖЦ (репозитарий) являются основой CASE-пакета. Соответствущая БД должна иметь возможность поддерживать большую систему описаний и характеристик и предусматривать надежные меры по защите от ошибок и потерь информации. Репозитарий должен обеспечивать:

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

Средства ввода предназначены для ввода данных в репозитарий, а также для организации взаимодействия с CASE-пакетом. Эти средства должны поддерживать различные методологии и использоваться на всем ЖЦ разными категориями разработчиков: аналитиками, проектировщиками, инженерами, администраторами и т.д.

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

Средства вывода служат для документирования, управления проектом и кодовой генерации.

Все перечисленные компоненты в совокупности должны:

ЭЛЕКТРОННЫЙ КОНСПЕКТ ЛЕКЦИЙ

ПО ДИСЦИПЛИНЕ

«ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ»

Тема 1. Введение. Основы методологии проектирования информационных систем 5

Жизненный цикл программного обеспечения 6

Модели жизненного цикла программного обеспечения 7

Макетирование 10

Спиральная модель жизненного цикла 11

Компонентно-ориентированная модель 13

Тема 2. Структурный анализ и проектирование 15

Определение структурного анализа 15

Средства структурного анализа 17

Моделирование потоков данных 18

Контекстная диаграмма 20

Построение иерархии диаграмм потоков данных 21

Методология функционально стоимостного анализа 21

Методология функционального моделирования SADT (Structured Analysis AND Design Technique) 22

Состав функциональной модели SADT 23

Иерархия диаграмм 24

Словарь данных 26

Тема 3. Построение информационной модели системы. Проектирование баз данных 28

Диаграммы сущность-связь (ERD) 28

Сущности, отношения и связи в нотации Чена 28

Типы связей в нотации Чена 30

Ассоциативная связь 30

Диаграммы атрибутов в классической модели Чена 31

Нотация Баркера. Модель сущность- связь в нотации Баркера 32

Методология IDEF1X 34

Тема 4. Методика построения информационной модели данных (модели «сущность-связь») 37

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

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

Использование средств и техники структурного системного анализа 38

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

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

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

Состав, структура и функциональные особенности case-средств 46

Поддержка графических моделей 47

Требования к современному диаграммеру 47

Тема 6. Структурное тестирование программного обеспечения 49

Основные понятия и принципы тестирования программного обеспечения 49

Особенности тестирования белого ящика 52

Способ тестирования базового пути 53

Потоковый граф 53

Цикломатическая сложность 54

Шаги способа тестирования базового пути 55

Способы тестирования условий 55

Тестирование ветвей и операторов отношения 56

Способ тестирования потоков данных 57

Тестирование циклов 59

Тема 7. Функциональное тестирование программного обеспечения 64

Особенности тестирования черного ящика 64

Способы разбиения на эквивалентности 65

Способ анализа граничных значений 66

Способ диаграмм причин–следствий 67

Тема 8. Организация процесса тестирования программного обеспечения 70

Методика тестирования программных систем 70

Тестирование элементов 71

Тестирование итераций 73

Восходящее тестирование интеграции 75

Тестирование правильности 75

Системное тестирование 77

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

Тенденция развития информационных систем приводит к возрастанию их сложности. Современные крупные проекты характеризуются следующими особенностями:

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

наличие тесно взаимодействующих компонентов;

отсутствие прямых аналогов ограничивает возможность использования типовых решений;

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

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

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

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

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

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

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

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

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

сложно обнаруживать ошибки в проектных решениях;

документация имеет низкое качество;

тестирование требует длительного времени и часто дает неудовлетворительные результаты.

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

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

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

умение разработчиков строить новые программы отстает от требований к новым программам;

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

Ключом решения этих проблем является грамотная организация процесса создания программного обеспечения, реализация технологических принципов промышленного конструирования информационных систем. Эти же проблемы способствовали появлению программных технологических средств социального класса, так называемых case(Computer Aided Software Engineering)-средств.

Case-средства реализует case-технология создания и сопровождения информационных систем.

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

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

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

Использование case-средств дает разработчику следующие преимущества:

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

за короткое время можно получить прототип создаваемой системы. Это позволяет на ранних этапах проектирования оценить ожидаемый результат;

освобождение разработчика от рутинной работы;

поддержка сопровождения программного обеспечения.