- •Жизненный цикл эис. Модели жизненного цикла эис.
- •Технологии и методы проектирования эис (эаис).
- •3,4 Классификация методов проектирования эис (эаис).
- •5. Типовое проектирование ис. Классификация типовых проектных решений (тпр). Методы типового проектирования.
- •Моделирование предметной области как основа проектирования ис.
- •Функциональная структура предметной области. Методологии моделирования функциональной структуры.
- •Методологии семейства idef. Стандарт idef0. Назначение. Область применения.
- •Правила построения диаграмм в нотации idef0.
- •Методологии семейства idef. Стандарт idef3. Назначение. Область применения.
- •Правила построения диаграмм в нотации idef3.
- •Назначение и правила построения dfd-диаграмм в программе bpWin (ca Process Modeler).
- •Правила построения диаграмм в нотации «Процедура» с использованием программы Business Studio.
- •Правила построения диаграмм в нотации «Процесс» с использованием программы Business Studio.
- •Объектная структура предметной области. Методологии моделирования объектной структуры.
- •Методология idef1x. Область применения. Основные возможности case-средства erWin (ca eRwin Data Modeler).
- •Правила построения концептуальной схемы данных в erWin. Особенности синтаксиса (правила наименования сущностей, виды сущностей, правила наименования связей, типы связей, мощность связей и пр.).
- •Базы данных. Основные понятия (банк данных, база данных, субд, приложение).
- •Трехуровневая система организации бд. Классификации бд.
- •Варианты архитектуры централизованных бд с сетевым доступом. Их достоинства и недостатки.
- •Классификация бд по структуре (модели) данных.
- •Реляционные бд. Основные принципы реляционной модели.
- •Основные понятия реляционных бд.
- •Типы связей в реляционных бд.
- •Категориальная связь. Способы разрешения (преобразования) категориальной связи в программе erWin (ca eRwin Data Modeler).
- •Триггеры ссылочной целостности. Назначение. Изменение параметров ri Actions в программе erWin (ca eRwin Data Modeler).
- •Каноническое проектирование эис. Стадии и этапы разработки (гост 34.601-90).
- •Состав и содержание технического задания на разработку системы (гост 34.602-89).
- •Процессы жизненного цикла по (гост р исо/мэк 12207-99)
- •Процессы жизненного цикла информационных систем (гост р исо/мэк 15288-2005).
- •Назначение и состав методологий внедрения эис.
- •Методология msf (Microsoft Solutions Framework). Понятие ит-решения.
- •Методология msf. Основные фазы и вехи проекта.
- •Методология msf. Проектная группа. Ролевые кластеры.
- •Методологии внедрения ис компании sap ag «asap» и «asap Focus». Сравнительный анализ.
- •Методология внедрения ис компании Microsoft «ms Dynamics Sure Step». Эволюция. Особенности.
- •Руководство pmbok. Группы процессов управления проектами.
- •Руководство pmbok. Области знаний по управлению проектами.
- •Сетевое планирование. Элементы сетевых моделей. Критический путь.
- •Правила расчета сетевых графиков секторным способом.
Жизненный цикл эис. Модели жизненного цикла эис.
Под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует.
Известны следующие базовые модели жизненного цикла.
Каскадная модель, в которой переход на следующий этап означает полное завершение работ на предыдущем этапе.
Его основной характеристикой является разбиение всей разработки на этапы, при этом переход на следующий этап происходит только после полного завершения работ на текущем (рис. 1).
Рис. 1. Каскадная схема разработки ПО.
Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. При этом этапы работ выполняются в логичной последовательности, что позволяет планировать сроки завершения всех работ и соответствующие затраты. Этот подход хорошо зарекомендовал себя при построении ИС, для которых в начале разработки можно достаточно точно и полно сформулировать все требования и предоставить разработчикам свободу реализовать их как можно лучше с технической точки зрения.
Его недостатки связаны с тем, что реальный процесс создания ПО ИС обычно не укладывается в такую жёсткую схему. Практически постоянно возникает потребность возвращаться к предыдущим этапам, уточнять или пересматривать принятые решения. В результате затягиваются сроки выполнения работы, пользователи могут вносить замечания лишь по завершению всех работ с системой. При этом модели автоматизируемого объекта могут устареть к моменту их утверждения.
Для преодоления этих проблем предложена поэтапная модель с промежуточным контролем (рис. 2).
Рис. 2. Поэтапная схема разработки ПО.
В поэтапной модели с промежуточным контролем разработка ПО ведётся итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют уменьшить трудоёмкость процесса разработки по сравнению с каскадной моделью. Время жизни каждого из этапов растягивается на весь период разработки.
Затем появилась спиральная модель ЖЦ (рис. 3), в которой на начальных этапах ЖЦ осуществляются анализ и проектирование.
Рис 3. Спиральная модель.
В этой модели особое внимание уделяется начальным этапам разработки – выработке стратегии, анализу и проектированию, где реализуемость тех или иных технических решений проверяется и обосновывается посредством создания прототипов (макетирования). Каждый виток спирали предполагает создание фрагмента (компонента) или версии программного продукта. На них уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации.
Полный жизненный цикл ИС должен поддерживаться комплексом инструментальных средств с учётом необходимости: адаптации типового проекта к различным системно-техническим платформам (техническим средствам, операционным системам и СУБД) и организационно-экономическим особенностям объектов внедрения; интеграции с существующими разработками (включая реинжиниринг приложений и конвертирование БД); обеспечения целостности проекта и контроля за его состоянием (наличие единой технологической среды создания, сопровождения и развития ИС, а также целостность репозитария). При этом желательно обеспечить независимость от программно-аппаратной платформы и СУБД, поддержку одновременной работы групп разработчиков, открытую архитектуру и возможности экспорта/импорта.