много...
1. Понятие и структура ИС.
Под информационной системой обычно понимается прикладная программная подсистема, ориентированная на сбор, хранение, поиск и обработку текстовой и/или фактографической информации. Подавляющее большинство информационных систем работает в режиме диалога с пользователем.
В наиболее общем случае типовые программные компоненты, входящие в состав информационной системы, реализуют:
• диалоговый ввод-вывод;
• логику диалога;
• прикладную логику обработки данных;
• логику управления данными;
• операции манипулирования файлами и (или) базами данных.
2.История развития и создания ИС.
Корпоративной информационной системой (КИС) мы будем называть совокупность специализированного программного обеспечения и вычислительной аппаратной платформы, на которой установлено и настроено программное обеспечение.
В последнее время все больше руководителей начинают отчетливо осознавать важность построения на предприятии корпоративной информационной системы как необходимого инструментария для успешного управления бизнесом в современных условиях.
Можно выделить три наиболее важных фактора, существенно влияющих на развитие корпоративных информационных систем:
• развитие методик управления предприятием;
• развитие общих возможностей и производительности компьютерных систем;
• развитие подходов к технической и программной реализации элементов информационной системы.
Можно выделить три наиболее существенных новшества, оказавших колоссальное влияние на развитие информационных систем в последние годы.
• Новый подход к программированию. С начала 90-х годов объектно-ориентированное программирование фактически вытеснило модульное; до настоящего времени непрерывно совершенствуются методы построения объектных моделей. Благодаря внедрению объектно-ориентированных технологий программирования существенно сокращаются сроки разработки сложных информационных систем, упрощаются их поддержка и развитие.
• Благодаря развитию сетевых технологий локальные информационные системы повсеместно вытесняются клиент-серверными и многоуровневыми реализациями.
• Развитие Интернета расширило возможности работы с удаленными подразделениями, открыло широкие перспективы электронной коммерции, обслуживания покупателей через Интернет и многое другое. Более того, определенные преимущества дает использование Интернет-технологий во внутренних сетях предприятий (так называемые интранет-технологии).
3-6. Классификация ИС
Информационные системы классифицируются по разным признакам. Рассмотрим наиболее часто используемые способы классификации.
По масштабу информационные системы подразделяются на следующие группы
• локальные;
• сетевые;
• корпоративные.
По сфере применения информационные системы обычно подразделяются на четыре группы:
• системы обработки транзакций;
• системы поддержки принятия решений;
• информационно-справочные системы;
• офисные информационные системы.
По способу организации групповые и корпоративные информационные системы подразделяются на следующие классы:
• системы на основе архитектуры файл-сервер;
• системы на основе архитектуры клиент-сервер;
• системы на основе многоуровневой архитектуры;
• системы на основе Интернет/интранет-технологий.
7. Области применения и реализвации ИС
Рассмотрим наиболее важные задачи, решаемые с помощью специальных программных средств.
-Бухгалтерский учет – классическая и наиболее часто реализуемая на сегодняшний день область применения информационных технологий.
-Управление финансовыми потоками. Внедрение информационных технологий в управление финансовыми потоками также обусловлено критичностью этой области управления предприятия к ошибкам.
-Управление складом, ассортиментом, закупками
-Управление производственным процессом
-Управление маркетингом. Управление маркетингом подразумевает сбор и анализ данных о фирмах-конкурентах, их продукции и ценовой политике, а также моделирование параметров внешнего окружения для определения оптимального уровня цен, прогнозирования прибыли и планирования рекламных кампаний.
- Документооборот. Хорошо отлаженная система учетного документооборота отражает реально происходящую на предприятии текущую производственную деятельность и дает управленцам возможность воздействовать на нее. Поэтому автоматизация документооборота позволяет повысить эффективность управления.
- Оперативное управление предприятием
-Предоставление информации о фирме.
8. Требования, предъявляемые к ИС
Информационная система должна соответствовать требованиям гибкости, надежности, эффективности и безопасности.
Гибкость, способность к адаптации и дальнейшему развитию подразумевает возможность приспособления информационной системы к новым условиям, новым потребностям предприятия.
Надежность информационной системы подразумевает ее функционирование без искажения информации, потери данных по «техническим причинам».
Система является эффективной, если с учетом выделенных ей ресурсов она позволяет решать возложенные на нее задачи в минимальные сроки.
Под безопасностью, прежде всего, подразумевается свойство системы, в силу которого посторонние лица не имеют доступа к информационным ресурсам организации, кроме тех, которые для них предназначены. Защита информации от постороннего доступа обеспечивается управлением доступом к ресурсам системы, использованием современных программных средств защиты информации
И, наконец, самый важный фактор, влияющий на процесс разработки, – знания и опыт коллектива разработчиков информационных систем.
9. CASE-средства
Термин CASE (Computer Aided Software/System Engineering) используется в настоящее время в весьма широком смысле. Первоначальное значение термина CASE ограничивалось лишь вопросами автоматизации разработки программного обеспечения. Однако в дальнейшем значение этого термина расширилось и приобрело новый смысл, охватывающий процесс разработки сложных информационных систем в целом. Теперь под термином «CASE-средства» понимаются программные средства, поддерживающие процессы создания и сопровождения информационных систем, включая анализ и формулировку требований, проектирование прикладного программного обеспечения и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы.
10. Экспертные системы.
Экспертные системы (ЭС) – это сложные программные комплексы, аккумулирующие знания специалистов в конкретных предметных областях и тиражирующие этот эмпирический опыт для консультаций менее квалифицированных пользователей.
При использовании оболочек и сред разработчик приложения полностью освобождается от программирования, его основные трудозатраты связаны с формированием базы знаний.
Надо отметить, что на заре появления ЭС специфика используемых в них языков, технологии разработки приложений и используемого оборудования (например, Lisp-машины) давала основания предполагать, что интеграция ЭС с традиционными, программными системами является сложной и, возможно, невыполнимой задачей при ограничениях, накладываемых реальными приложениями. Однако в настоящее время коммерческие инструментальные средства (ИС) для создания ЭС разрабатываются в полном соответствии с современными технологическими тенденциями традиционного програм мирования, что снимает проблемы, возникающие при создании интегрированных приложений.
11.Модели жизненного цикла информационной системы
Моделью жизненного цикла информационной системы будем называть некоторую структуру, определяющую последовательность осуществления процессов, действий и задач, выполняемых на протяжении жизненного цикла информационной системы, а также взаимосвязи между этими процессами, действиями и задачами.
В стандарте ISO/IEC 12207 не конкретизируются в деталях методы выполнения действий и решения задач, входящих в процессы жизненного цикла информационной системы, а лишь описываются структуры этих процессов. Это вполне понятно, так как регламенты стандарта являются общими для любых моделей жизненного цикла, методологий и технологий разработки. Модель же жизненного цикла зависит от специфики информационной системы и условий, в которых она создается и функционирует. Поэтому не имеет смысла предлагать какие-либо конкретные модели жизненного цикла и методы разработки информационных систем для общего случая, без привязки к определенной предметной области.
К настоящему времени наибольшее распространение получили две основные модели жизненного цикла:
• каскадная модель, иногда также называемая моделью водопада (waterfall);
• спиральная модель.
Каскадная модель демонстрирует классический подход к разработке различных систем в любых прикладных областях.
Спиральная модель, в отличие от каскадной, предполагает итерационный процесс разработки информационной системы. При этом возрастает значение начальных этапов жизненного цикла, таких как анализ и проектирование. На этих этапах проверяется и обосновывается реализуемость технических решений путем создания прототипов.
12. Стандарты ЖЦ
Корпоративные стандарты образуют целостную систему, которая включает три вида стандартов:
• на продукты и услуги;
• на процессы и технологии;
• на формы коллективной деятельности, или управленческие стандарты.
Существующие на сегодняшний день стандарты можно условно разделить на несколько групп.
• По предмету стандартизации.
• По утверждающей организации.
• По методическому источнику.
По определению, ISO 12207 – базовый стандарт процессов жизненного цикла ПО, ориентированный на различные виды ПО и типы проектов автоматизированных систем, в которых ПО является одной из составных частей. Стандарт определяет стратегию и общий порядок создания и эксплуатации ПО, он охватывает жизненный цикл от концептуализации идей до завершения проекта.
Целесообразность совместного использования стандартов на информационные системы и на ПО обуславливается одним из положений ISO 12207, согласно которому процессы, протекающие во время жизненного цикла ПО, должны быть совместимы с процессами, протекающими во время жизненного цикла автоматизированной системы.
Согласно ISO 12207, система – это объединение одного или нескольких процессов, аппаратных средств, программного обеспечения, оборудования и людей для удовлетворения определенных потребностей или целей.
В отличие от CDM фирмы Oracle, стандарт ISO 12207 в равной степени ориентирован на организацию действий каждой из двух сторон: поставщика (разработчика) и покупателя (пользователя); он может быть применен и в том случае, когда обе стороны относятся к одной организации.
В стандарте ISO 12207 не предусмотрено каких-либо этапов (фаз или стадий) жизненного цикла информационной системы. Данный стандарт определяет лишь ряд процессов, причем по сравнению с CDM стандарт ISO 12207 состоит из гораздо более крупных обобщенных процессов (приобретение, поставка, разработка и т. п.). Несколько утрируя, можно сказать, что один процесс ISO 12207 сопоставим со всеми процессами CDM вместе взятыми.
Согласно ISO 12207, каждый процесс подразделяется на ряд действий, а каждое действие – на ряд задач.
Очень важной особенностью ISO 12207 по сравнению с CDM является то, что каждый процесс, действие или задача инициируется и выполняется другим процессом по мере необходимости, причем нет заранее определенных последовательностей (естественно, при сохранении логики связей по исходным сведениям задач и т. п.).
13. Основные группы процессов ЖЦ.
Основные и вспомогательные процессы жизненного цикла
В стандарте ISO 12207 описаны пять основных процессов жизненного цикла программного обеспечения.
• Процесс приобретения определяет действия предприятия
• Процесс поставки определяет действия предприятия
• Процесс разработки определяет действия предприятия
• Процесс функционирования определяет действия предприятия
• Процесс сопровождения определяет действия персонала.
К вспомогательным процессам относятся:
• процесс решения проблем;
• процесс документирования;
• процесс управления конфигурацией;
• процесс обеспечения качества;
• процесс верификации;
• процесс аттестации;
• процесс совместной оценки;
• процесс аудита.
В стандарте ISO 12207 также определяются четыре организационных процесса:
• процесс управления;
• процесс создания инфраструктуры;
• процесс усовершенствования;
• процесс обучения.
14. Структура ЖЦ
Жизненный цикл формируется из определенных этапов (фаз) проекта и процессов, каждый из которых выполняется в течение нескольких этапов.
Методика CDM определяет следующие фазы жизненного цикла информационной системы:
• стратегия;
• анализ (формулирование детальных требований к прикладной системе);
• проектирование (преобразование требований в детальные спецификации системы);
• реализация (написание и тестирование приложений);
• внедрение (установка новой прикладной системы, подготовка к началу эксплуатации);
• эксплуатация (поддержка и сопровождение приложения, планирование будущих функциональных расширений).
Первый этап связан с моделированием и анализом процессов, описывающих деятельность организации, технологические особенности работы. Целью является построение моделей существующих процессов, выявление их недостатков и возможных источников совершенствования. Этот этап не является обязательным в случае, когда существующие технология и организационные структуры четко определены, хорошо понятны и не требуют дополнительного изучения и реорганизации.
15-16. Достоинства и недостатки каскадной модели.
Основные достоинства каскадной модели
• На каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности. На заключительных этапах также разрабатывается пользовательская документация, охватывающая все предусмотренные стандартами виды обеспечения информационной системы (организационное, методическое, информационное, программное, аппаратное).
• Выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения и соответствующие затраты.
Недостатки каскадной модели:
• существенная задержка в получении результатов;
• ошибки и недоработки на любом из этапов проявляются, как правило, на последующих этапах работ, что приводит к необходимости возврата назад;
• сложность параллельного ведения работ по проекту;
• чрезмерная информационная перенасыщенность каждого из этапов;
• сложность управления проектом;
• высокий уровень риска и ненадежность инвестиций.
17-18. Достоинства и недостатки спиральной модели
Преимущества спиральной модели
• Итерационная разработка существенно упрощает внесение изменений в проект при изменении требований заказчика.
• При использовании спиральной модели отдельные элементы информационной системы интегрируются в единое целое постепенно.
• Уменьшение уровня рисков.
• Итерационная разработка обеспечивает большую гибкость в управлении проектом, давая возможность внесения тактических изменений в разрабатываемое изделие.
• Итерационный подход упрощает повторное использование компонентов.
• Спиральная модель позволяет получить более надежную и устойчивую систему.
• Итерационный подход дает возможность совершенствовать процесс разработки – анализ, проводимый в конце каждой итерации, позволяет проводить оценку того, что должно быть изменено в организации разработки, и улучшить ее на следующей итерации.
Недостатки спиральной модели
Основная проблема спирального цикла – определение момента перехода на следующий этап.
19. Понятие проекта
Проект – это ограниченное по времени целенаправленное изменение отдельной системы с изначально четко определенными целями, достижение которых означает завершение проекта, а также с установленными требованиями к срокам, результатам, риску, рамкам расходования средств и ресурсов, организационной структуре.
Можно выделить следующие основные отличительные признаки проекта как объекта управления:
• изменчивость – целенаправленный перевод системы из существующего в некоторое желаемое состояние, описываемое в терминах целей проекта;
• ограниченность конечной цели;
• ограниченность продолжительности;
• ограниченность бюджета;
• ограниченность требуемых ресурсов;
• новизна для предприятия, для которого реализуется проект;
• комплексность – наличие большого числа факторов, прямо или косвенно влияющих на прогресс и результаты проекта;
• правовое и организационное обеспечение – создание специфической организационной структуры на время реализации проекта.
20. Классификация проектов
Классификация проектов
Проекты могут значительно отличаться по сфере приложения, составу, предметной области, масштабам, длительности, составу участников, степени сложности, значимости результатов и т. п. Проекты могут быть классифицированы по самым различным признакам.
• Класс проекта определяется по составу и структуре проекта. Обычно различают:
– монопроект (отдельный проект, который может быть любого типа, вида и масштаба);
– мультипроект (комплексный проект, состоящий из ряда монопроектов и требующий мультипроектного управления).
• Тип проекта определяется по основным сферам деятельности, в которых осуществляется проект. Можно выделить пять основных типов проекта:
– технический;
– организационный;
– экономический;
– социальный;
– смешанный.
Примечание.
Разработка информационных систем относится, скорее всего, к техническим проектам. У таких проектов две особенности. Во-первых, главная цель проекта четко определена, но отдельные цели должны уточняться по мере достижения частных результатов. Во-вторых, срок завершения и продолжительность проекта определены заранее, желательно их точное соблюдение, однако они также могут корректироваться в зависимости от полученных промежуточных результатов и общего прогресса проекта.
• Масштаб проекта определяется размером бюджета и количеством участников:
– мелкие проекты;
– малые проекты;
– средние проекты;
– крупные проекты.
21. Основные фазы проектирования информационной системы
• формирование концепции;
• подготовка технического задания;
• проектирование;
• разработка;
• ввод системы в эксплуатацию.
Рассмотрим каждую из них более подробно.
Вторую и частично третью фазы принято называть фазами системного проектирования, а последние две (иногда сюда включают и фазу проектирования) – фазами реализации.
Концептуальная фаза
• формирование идеи, постановку целей;
• формирование ключевой команды проекта;
• изучение мотивации и требований заказчика и других участников;
• сбор исходных данных и анализ существующего состояния;
• определение основных требований и ограничений, требуемых материальных, финансовых и трудовых ресурсов;
• сравнительную оценку альтернатив;
• представление предложений, их экспертизу и утверждение.
Подготовка технического предложения
• разработка основного содержания, базовой структуры проекта;
• разработка и утверждение технического задания;
• планирование, декомпозиция базовой структурной модели проекта;
• составление сметы и бюджета проекта, определение потребности в ресурсах;
• разработка календарных планов и укрупненных графиков работ;
• подписание контракта с заказчиком;
• ввод в действие средств коммуникации участников проекта и средств контроля за ходом работ.
Проектирование
• выполнение базовых проектных работ;
• разработка частных технических заданий;
• выполнение концептуального проектирования;
• составление технических спецификаций и инструкций;
• представление проектной разработки, экспертиза и утверждение.
Разработка
• выполнение работ по разработке программного обеспечения;
• подготовка к внедрению системы;
• контроль и регулирование основных показателей проекта.
Ввод системы в эксплуатацию
• комплексные испытания;
• подготовка кадров для эксплуатации создаваемой системы;
• подготовка рабочей документации, сдача системы заказчику и ввод ее в эксплуатацию;
• сопровождение, поддержка, сервисное обслуживание;
• оценка результатов проекта и подготовка итоговых документов;
• разрешение конфликтных ситуаций и закрытие работ по проекту;
• накопление опытных данных для последующих проектов, анализ опыта, состояния, определение направлений развития.
22.Процессы, протекающие на протяжение ЖЦ ИС
жизненного цикла основывается на трех группах процессов:
• основные процессы жизненного цикла (приобретение, поставка, разработка, эксплуатация, сопровождение);
• вспомогательные процессы, обеспечивающие выполнение основных процессов (документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, оценка, аудит, разрешение проблем);
• организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого жизненного цикла, обучение).
23. Методология и технология разработки ИС
Методология создания информационных систем заключается в организации процесса построения информационной системы и в управлении этим процессом для того, чтобы гарантировать выполнение требований как к самой системе, так и к характеристикам процесса разработки.
Основными задачами, решение которых должна обеспечивать методология создания корпоративных информационных систем (с помощью соответствующего набора инструментальных средств), являются:
• соответствие создаваемой информационной системы целям и задачам предприятия, а также предъявляемым к ней требованиям по автоматизации бизнес-процессов;
• гарантирование создания системы с заданными параметрами в течение заданного времени в рамках оговоренного заранее бюджета;
• простота сопровождения, модификации и расширения системы с целью обеспечения ее соответствия изменяющимся условиям работы предприятия;
• соответствие создаваемой корпоративной информационной системы требованиям открытости, переносимости и масштабируемости;
• возможность использования в создаваемой системе разработанных ранее и применяемых на предприятии средств информационных технологий (программного обеспечения, баз данных, средств вычислительной техники, телекоммуникаций).
Основное содержание технологии проектирования составляют технологические инструкции, состоящие из описания последовательности технологических операций, условий, в зависимости от которых выполняется та или иная операция, и описаний самих операций.
Технология проектирования может быть представлена как совокупность трех составляющих:
• заданной последовательности выполнения технологических операций проектирования;
• критериев и правил, используемых для оценки результатов выполнения технологических операций;
• графических и текстовых средств (нотаций), используемых для описания проектируемой системы.
Каждая технологическая операция должна обеспечиваться следующими материальными и информационными ресурсами:
• данными, полученными на предыдущей операции (или исходными данными), представленными в стандартном виде;
• методическими материалами, инструкциями, нормативами и стандартами;
• программными и техническими средствами;
• исполнителями.
Результаты выполнения операции должны представляться в некотором стандартном виде, обеспечивающем их адекватное восприятие при выполнении следующей технологической операции (на которой они будут использоваться в качестве исходных данных).
24. Методология RAD
Методология RAD – это комплекс специальных инструментальных средств, позволяющих оперировать с определенным набором графических объектов, функционально отображающих отдельные информационные компоненты приложений.
Под методологией быстрой разработки приложений обычно понимается процесс разработки информационных систем, основанный на трех основных элементах:
• небольшой команде программистов (обычно от 2 до 10 человек);
• тщательно проработанном производственном графике работ, рассчитанном на сравнительно короткий срок разработки (от 2 до 6 мес);
• итерационной модели разработки, основанной на тесном взаимодействии с заказчиком – по мере выполнения проекта разработчики уточняют и реализуют в продукте требования, выдвигаемые заказчиком.
Основные принципы методологии RAD можно свести к следующим:
• используется итерационная (спиральная) модель разработки;
• полное завершение работ на каждом из этапов жизненного цикла не обязательно;
• в процессе разработки информационной системы обеспечивается тесное взаимодействие с заказчиком и будущими пользователями;
• применяются CASE-средства и средства быстрой разработки приложений;
• применяются средства управления конфигурацией, облегчающие внесение изменений в проект и сопровождение готовой системы;
• используются прототипы, позволяющие полнее выяснить и реализовать потребности конечного пользователя;
• тестирование и развитие проекта осуществляются одновременно с разработкой;
• разработка ведется немногочисленной и хорошо управляемой командой профессионалов;
• обеспечиваются грамотное руководство разработкой системы, четкое планирование и контроль выполнения работ.
Средства RAD позволили реализовать совершенно иную по сравнению с традиционной технологию создания приложений: информационные объекты формируются как некие действующие модели (прототипы), чье функционирование согласуется с пользователем, а затем разработчик может переходить непосредственно к формированию законченных приложений, не теряя из виду общей картины проектируемой системы.
25. Фазы жизненного цикла в рамках методологии RAD
При использовании методологии быстрой разработки приложений жизненный цикл информационной системы состоит из четырех фаз:
• анализа и планирования требований;
• проектирования;
• построения;
• внедрения.
На фазе анализа и планирования требований определяются:
• функции, которые должна выполнять разрабатываемая информационная система;
• наиболее приоритетные функции, требующие разработки в первую очередь;
• информационные потребности;
На фазе проектирования необходимым инструментом являются CASE-средства, используемые для быстрого получения работающих прототипов приложений.
На этой же фазе происходит определение набора необходимой документации.
Результатами данной фазы являются:
• общая информационная модель системы;
• функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков;
• точно определенные с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами;
• построенные прототипы экранов, диалоговых окно и отчетов.
Фаза построения
На фазе построения выполняется собственно быстрая разработка приложения. На данной фазе разработчики производят итеративное построение реальной системы на основе полученных ранее моделей, а также требований нефункционального характера.
Фаза внедрения
Фаза внедрения в основном сводится к обучению пользователей разработанной информационной системы.
Так как фаза построения достаточно непродолжительна, планирование и подготовка к внедрению должны начинаться заранее, еще на этапе проектирования системы.
26. Ограничения методологии RAD
Несмотря на все свои достоинства, методология RAD (как, впрочем, и любая другая методология), не может претендовать на универсальность. Ее применение наиболее эффективно при создании сравнительно небольших систем, разрабатываемых для конкретного заказчика.
При разработке же типовых систем, не являющихся законченным продуктом, а представляющих собой совокупность типовых элементов информационной системы, большое значение имеют такие показатели проекта, как управляемость и качество, которые могут войти в противоречие с простотой и скоростью разработки. Это связано с тем, что типовые системы обычно централизованно сопровождаются и могут адаптироваться к различным программно-аппаратным платформам, системам управления базами данных, коммуникационным средствам, а также интегрироваться с существующими разработками. Поэтому для такого рода проектов необходим высокий уровень планирования и жесткая дисциплина проектирования, строгое следование заранее разработанным протоколам и интерфейсам, что снижает скорость разработки.
Методология RAD не подходит для создания не только типовых информационных систем, но и сложных расчетных программ, операционных систем и программ управления сложными инженерно-техническими объектами, то есть программ, требующих написания большого объема уникального кода.
Методология RAD не может быть использована для разработки приложений, в которых интерфейс пользователя является вторичным, то есть отсутствует наглядное определение логики работы системы. Примерами таких приложений могут служить приложения реального времени, драйверы или службы.
Совершенно неприемлема методология RAD для разработки систем, от которых зависит безопасность людей, например, систем управления транспортом или атомными электростанциями. Это обусловлено тем, что итеративный подход, являющийся одной из основ RAD, предполагает, что первые версии системы не будут полностью работоспособными, что в данном случае может привести к серьезнейшим катастрофам.
27. Унифицированный процесс разработки ПО
- это один из подходов к организации ЖЦ ПО хорошо сочетающийся с UML.
RUP (Rational Unified Process).
Цель RUP – обеспечить создание программного продукта высочайшего качества, соответствующего потребностям пользователя в заданные сроки и в пределах запланированного бюджета. RUP вобрал в себя лучший из существующих методов разработки ПО. С точки зрения управления проектом RUP предлагает упорядоченный подход к способам распределения заданий и обязанностей в организации, занимающийся разработкой ПО.
Характеристики:
1) итерационный процесс;
2) RUP- это конфигурируемый процесс.
Фазы RUP:
1) Начальная фаза – определение границ проекта, разработка концепции и начального плана проекта;
2) Разработка – это проектирование, реализация и тестирование стабильной архитектуры, завершение разработки плана проекта;
3) Конструирование – это построение первой эксплуатационной версии системы;
4) Внедрение – поставка системы конечным пользователям.
28. Профили открытых информационных систем
Профиль – это совокупность нескольких (или подмножество одного) базовых стандартов с четко определенными и гармонизированными подмножествами обязательных и факультативных возможностей, предназначенная для реализации заданной функции или группы функций.
Профиль формируется исходя из функциональных характеристик объекта стандартизации. В профиле выделяются и устанавливаются допустимые возможности и значения параметров каждого базового стандарта и/или нормативного документа, входящего в профиль.
Профиль не должен противоречить входящим в него базовым стандартам и нормативным документам. Применяемые в соответствии с профилем необязательные возможности и значения параметров, выбранные из альтернативных вариантов, должны оставаться в допустимых пределах.
Обычно рассматривают две группы профилей, регламентирующих:
• архитектуру и структуру информационной системы;
• процессы проектирования, разработки, применения, сопровождения и развития системы.
В зависимости от области применения профили могут иметь разные категории и соответственно разные статусы утверждения:
• профили конкретной информационной системы, определяющие стандартизованные проектные решения в пределах данного проекта;
• профили информационной системы, предназначенные для решения некоторого класса прикладных задач.
29. Принципы формирования профиля информационной системы
Профили информационных систем призваны решить следующие задачи:
• снижение трудоемкости проектов;
• повышение качества компонентов информационных систем;
• обеспечение расширяемости и масштабируемости разрабатываемых систем;
• обеспечение возможности функциональной интеграции в информационную систему задач, которые раньше решались раздельно;
• обеспечение переносимости прикладного программного обеспечения.
В зависимости от того, какие из указанных задач являются наиболее приоритетными, производится выбор стандартов и документов для формирования профиля.
Подходы к формированию профилей информационных систем могут быть различными.
Эталонная модель среды открытых систем определяет разделение любой информационной системы на две составляющие: приложения (прикладные программы и программные комплексы) и среду, в которой эти приложения функционируют. При использовании профилей важно обеспечить корректность их применения путем тестирования, испытаний и сертификации. Для этого требуется создание технологии контроля и тестирования в процессе применения профиля. Данная технология должна поддерживаться совокупностью методик, инструментальных средств, составом и содержанием оформляемых документов на каждом этапе выполнения проекта.
30. Структура профилей информационных систем
Разработка и применение профилей являются органической частью процессов проектирования, разработки и сопровождения информационных систем. Профили характеризуют каждую конкретную информационную систему на всех стадиях ее жизненного цикла, задавая согласованный набор базовых стандартов, которым должна соответствовать система и ее компоненты.
В профиль конкретной системы включаются спецификации компонентов, разработанных в составе данного проекта, и спецификации использованных готовых программных и аппаратных средств, если эти средства не специфицированы соответствующими стандартами. После завершения проектирования и испытаний системы, в ходе которых проверяется ее соответствие профилю, профиль применяется как основной инструмент сопровождения системы при эксплуатации, модернизации и развитии.
Формирование и применение профилей конкретных информационных систем выполняется на основе международных и национальных стандартов, ведомственных нормативных документов, а также стандартов де-факто при условии доступности соответствующих им спецификаций. Для обеспечения корректного применения профилей их описания должны содержать:
• определение целей использования профиля;
• точное перечисление функций объекта или процесса стандартизации, определяемого профилем;
• формализованные сценарии применения базовых стандартов и спецификаций, включенных в профиль;
• сводку требований к информационной системе или к ее компонентам, определяющих их соответствие профилю, и требований к методам тестирования соответствия;
• нормативные ссылки на конкретный набор стандартов и других нормативных документов, составляющих профиль, с точным указанием применяемых редакций и ограничений, способных повлиять на достижение корректного взаимодействия объектов стандартизации при использовании профиля;
• информационные ссылки на все исходные документы.
На стадиях жизненного цикла информационной системы выбираются и затем применяются следующие основные функциональные профили:
• прикладного программного обеспечения;
• среды информационной системы;
• защиты информации в информационной системе;
• инструментальных средств, встроенных в информационную систему.
31. Профиль прикладного программного обеспечения
Прикладное программное обеспечение всегда является проблемно-ориентированным и определяет основные функции информационной системы. Функциональные профили системы должны включать в себя согласованные базовые стандарты. При использовании функциональных профилей информационных систем следует еще иметь в виду согласование этих профилей между собой. Необходимость такого согласования возникает, в частности, при использовании стандартизованных интерфейсов API, в том числе интерфейсов приложений со средой их функционирования и со средствами защиты информации. При согласовании функциональных профилей возможны также уточнения профиля среды системы и профиля встраиваемых инструментальных средств создания, сопровождения и развития прикладного программного обеспечения.
32.Профиль среды информационной системы
Профиль среды информационной системы должен определять ее архитектуру в соответствии с выбранной моделью обработки данных.
Стандарты интерфейсов приложений со средой (API) должны быть определены по функциональным областям профилей информационной системы. Декомпозиция структуры среды функционирования системы на составные части, выполняемая на стадии эскизного проектирования, позволяет детализировать профиль среды информационной системы по следующим функциональным областям эталонной модели OSE/RM:
• графического пользовательского интерфейса;
• реляционных или объектно-ориентированных СУБД
• операционных систем с учетом сетевых функций, выполняемых на уровне операционной системы;
• телекоммуникационной среды в части услуг и служб прикладного уровня.
Профиль среды распределенной системы должен включать стандарты протоколов транспортного уровня, стандарты локальных сетей (например, стандарт Ethernet IEEE 802.3 или стандарт Fast Ethernet IEEE 802.3 u), а также стандарты средств сопряжения проектируемой информационной системы с сетями передачи данных общего назначения.
Выбор аппаратных платформ информационной системы связан с определением их параметров.
33. Профиль защиты информации
Профиль защиты информации должен обеспечивать реализацию политики информационной безопасности, разрабатываемой в соответствии с требуемой категорией безопасности и критериями безопасности, заданными в техническом задании на систему. Построение профиля защиты информации в распределенных системах клиент-сервер методически связано с точным определением компонентов системы, ответственных за те или иные функции, службы и услуги, и средств защиты информации, встроенных в эти компоненты.
Профиль защиты информации должен включать указания на методы и средства обнаружения в применяемых аппаратных и программных средствах недекларированных возможностей. Профиль должен также включать указания на методы и средства резервного копирования информации и восстановления информации при отказах и сбоях аппаратуры системы.
34. Профиль инструментальных средств
Профиль инструментальных средств, встроенных в информационную систему, должен отражать решения по выбору методологии и технологии создания, сопровождения и развития информационной системы. В этом профиле должны содержаться ссылки на описание выбранных методологии и технологии, выполненное на стадии эскизного проектирования системы.
Состав инструментальных средств определяется на основании решений и нормативных документов об организации сопровождения и развития информационной системы. При этом должны быть учтены правила и порядок, регламентирующие внесение изменений в действующие системы.
В этом профиле должны также содержаться ссылки на требования к средствам тестирования, которые необходимы для сопровождения и развития системы и должны быть в нее встроены. В число встроенных в информационную систему средств тестирования должны входить средства функционального тестирования приложений, тестирования интерфейсов, системного тестирования и тестирования серверов/клиентов при максимальной нагрузке.
35. Стандарты и методики
Одним из важных условий эффективного использования информационных технологий является внедрение корпоративных стандартов. Корпоративные стандарты представляют собой соглашение о единых правилах организации технологии или управления. При этом за основу корпоративных стандартов могут приниматься отраслевые, национальные и даже международные стандарты.
Однако динамика развития информационных технологий приводит к быстрому устареванию существующих стандартов и методик разработки информационных систем. Так, в связи со значительным прогрессом в области программного обеспечения и средств вычислительной техники наблюдается рост размеров и сложности информационных систем. При этом существенно меняются требования как к основным функциям и сервисным возможностям систем, так и к динамике изменения этих функций. В этих условиях применение классических способов разработки и обеспечения качества информационных систем становится малоэффективным и не приводит к уровню качества, адекватному реальным требованиям.
Полезны в этом отношении стандарты открытых систем (в первую очередь стандарты на интерфейсы различных видов, включая лингвистические, и на протоколы взаимодействия). Однако разработка систем в новых условиях требует также новых методов проектирования и новой организации проектных работ. Проектирование и методическая поддержка разработки информационных систем, включая программное обеспечение (ПО) и базы данных (БД), традиционно поддерживаются многими стандартами и фирменными методиками. Вместе с тем известно, что требуется адаптивное планирование разработки, в том числе в динамике процесса ее выполнения. Одним из способов адаптивного проектирования является разработка и применение профилей жизненного цикла информационных систем и программного обеспечения.
36. Состав и содержание ТЗ на ИС
1 ОБЩИЕ ПОЛОЖЕНИЯ
1.1 Полное наименование системы и ее условное обозначение
1.2 Номер договора (контракта)
1.3 Наименования организации-заказчика и организаций-участников работ
1.4 Перечень документов, на основании которых создается система
1.5 Плановые сроки начала и окончания работы по созданию системы
1.6 Источники и порядок финансирования работ
1.7 Порядок оформления и предъявления заказчику результатов работ по созданию системы
1.8 Перечень нормативно-технических документов, методических материалов, использованных при разработке ТЗ
1.9 Определения, обозначения и сокращения
2 НАЗНАЧЕНИЕ И ЦЕЛИ СОЗДАНИЯ СИСТЕМЫ
2.1 Назначение системы
2.2 Цели создания системы
3 ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ
4 ТРЕБОВАНИЯ К СИСТЕМЕ
4.1 Требования к системе в целом
4.2 Требования к функциям (задачам), выполняемым системой
4.3 Требования к видам обеспечения
5 СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО СОЗДАНИЮ (РАЗВИТИЮ) СИСТЕМЫ
6 ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ СИСТЕМЫ
6.1 Виды, состав, объем и методы испытаний системы
6.2 Общие требования к приемке работ по стадиям
6.3 Статус приемочной комиссии
7 ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ ПО ПОДГОТОВКЕ ОБЪЕКТА АВТОМАТИЗАЦИИ К ВВОДУ СИСТЕМЫ В ДЕЙСТВИЕ
8 ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ
9 ИСТОЧНИКИ РАЗРАБОТКИ
ПРИЛОЖЕНИЕ
37. Состав и содержание требований к ИС в целом
4 ТРЕБОВАНИЯ К СИСТЕМЕ
4.1 Требования к системе в целом
4.1.1 Требования к структуре и функционированию системы
4.1.1.1 Перечень подсистем, их назначение и основные характеристики
4.1.1.2 Требования к способам и средствам связи для информационного обмена между компонентами системы
4.1.1.3 Требования к характеристикам взаимосвязей создаваемой системы со смежными системами
4.1.1.4 Требования к режимам функционирования системы
4.1.1.5 Требования по диагностированию системы
4.1.1.6 Перспективы развития, модернизации системы
4.1.2 Требования к численности и квалификации персонала системы
4.1.3 Показатели назначения
4.1.4 Требования к надежности
4.1.5 Требования к безопасности
4.1.6 Требования к эргономике и технической эстетике
4.1.7 Требования к транспортабельности для подвижных АС
4.1.8 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы
4.1.9 Требования к защите информации от несанкционированного доступа
4.1.10 Требования по сохранности информации при авариях
4.1.11 Требования к защите от влияния внешних воздействий
4.1.12 Требования к патентной частоте
4.1.13 Требования по стандартизации и унификации
4.1.14 Дополнительные требования
4.2 Требования к функциям (задачам), выполняемым системой
4.3 Требования к видам обеспечения
4.3.1 Требования к математическому обеспечению системы
4.3.2 Требования информационному обеспечению системы
4.3.3 Требования к лингвистическому обеспечению системы
4.3.4 Требования к программному обеспечению системы
4.3.5 Требования к техническому обеспечению
4.3.6 Требования к метрологическому обеспечению
4.3.7 Требования к организационному обеспечению
4.3.8 Требования к методическому обеспечению
38. Требования к структуре и функционированию системы
В требованиях к структуре и функционированию системы приводят:
1) перечень подсистем, их назначение и основные характеристики, требования к числу уровней иерархии и степени централизации системы;
2) требования к способам и средствам связи для информационного обмена между компонентами системы;
3) требования к характеристикам взаимосвязей создаваемой системы со смежными системами, требования к ее совместимости, в том числе указания о способах обмена информацией (автоматически, пересылкой документов, по телефону и т.п.);
4) требования к режимам функционирования системы;
5) требования по диагностированию системы;
6) перспективы развития, модернизации системы
39. Требования к надежности
В требования к надежности включают:
1) состав и количественные значения показателей надежности для системы в целом или ее подсистем;
2) перечень аварийных ситуаций, по которым должны быть регламентированы требования к надежности, и значения соответствующих показателей;
3) требования к надежности технических средств и программного обеспечения;
4) требования к методам оценки и контроля показателей надежности на разных стадиях создания системы в соответствии с действующими нормативно-техническими документами.
40. Требования к безопасности
В требования по безопасности включают требования по обеспечению безопасности при монтаже, наладке, эксплуатации, обслуживании и ремонте технических средств системы (защита от воздействий электрического тока, электромагнитных полей, акустических шумов и т. п.), по допустимым уровням освещенности, вибрационных и шумовых нагрузок.
41. Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы
В требования к эксплуатации, техническому обслуживанию, ремонту и хранению включают:
1) условия и регламент (режим) эксплуатации, которые должны обеспечивать использование технических средств (ТС) системы с заданными техническими показателями, в том числе виды и периодичность обслуживания ТС системы или допустимость работы без обслуживания;
2) предварительные требования к допустимым площадям для размещения персонала и ТС системы, к параметрам сетей энергоснабжения и т. п.;
3) требования по количеству, квалификации обслуживающего персонала и режимам его работы;
4) требования к составу, размещению и условиям хранения комплекта запасных изделий и приборов;
5) требования к регламенту обслуживания.
42. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ
В разделе «Требования к документированию» приводят:
1) согласованный разработчиком и Заказчиком системы перечень подлежащих разработке комплектов и видов документов, соответствующих требованиям ГОСТ 34.201-89 и НТД отрасли заказчика;
перечень документов, выпускаемых на машинных носителях;
требования к микрофильмированию документации;
2) требования по документированию комплектующих элементов межотраслевого применения в соответствии с требованиями ЕСКД и ЕСПД;
3) при отсутствии государственных стандартов, определяющих требования к документированию элементов системы, дополнительно включают требования к составу и содержанию таких документов.
43. Требования к оформлению ТЗ на ИС
Техническое задание оформляют в соответствии с ГОСТ 19.106-78 на листах формата 11 и 12 по ГОСТ 2.301-68, как правило, без заполнения полей листа. Номера листов (страниц) проставляются в верхней части листа над текстом.
Лист утверждения и титульный лист оформляют в соответствии с ГОСТ 19.104-78.
Информационную часть (аннотацию и содержание), лист регистрации изменений допускается в документ не включать.
Для внесения изменений или дополнений в техническое задание на последующих стадиях разработки программы или программного изделия выпускают дополнение к нему. Согласование и утверждение дополнения к техническому заданию проводят в том же порядке, который установлен для технического задания.
Техническое задание должно содержать следующие разделы:
• введение;
• основания для разработки;
• назначение разработки;
• требования к программе или программному изделию;
• требования к программной документации;
• технико-экономические показатели;
• стадии и этапы разработки;
• порядок контроля и приемки;
• в техническое задание допускается включать приложения.
В зависимости от особенностей программы или программного изделия допускается уточнять содержание разделов, вводить новые разделы или объединять отдельные из них.
44- 45. Универсальный язык моделирования
История создания и развития
Универсальный язык моделирования (UML), разработка которого началась с середины 90-х годов прошлого века на базе нескольких объектно-ориентированных методов и нотаций описания информационных систем, в настоящее время является общепринятым стандартом документирования процесса создания информационных систем и программного обеспечения. В качестве стандарта UML принят консорциумом OMG, в который входят все ведущие производители программного обеспечения.
Наиболее весомый вклад в разработку языка внесли известные специалисты Грэди Буч (Grady Booch), Джим Румбах (Jim Rumbaugh) и Ивар Якобсон (Ivar Jacobson); за счет объединения методик каждого из них собственно и возник язык UML.
Язык UML постоянно совершенствуется. В настоящее время текущей спецификацией языка является версия 2.0. Кроме того, сам язык предоставляет пользователю возможности расширения ядра языка для нужд конкретного производителя, хотя это и не рекомендуется делать по причине достаточности возможностей языка.
Первоначально язык UML создавался, чтобы упростить описание информационных систем на базе объектно-ориентированной технологии. Сейчас средствами языка можно описывать также программное обеспечение, оперирующее в основном потоками данных и методами их обработки (процедурное, алгоритмическое проектирование).
Причиной, побудившей к созданию универсального языка описания программного обеспечения, явилась постоянно возрастающая сложность проектируемых информационных систем, которая в свою очередь диктуется усложнением решаемых задач.
46. Принципы моделирования
Моделирование имеет богатую историю во всех инженерных дисциплинах. Длительный опыт его использования позволил сформулировать четыре основных принципа.
Во-первых, выбор модели оказывает определяющее влияние на подход к решению проблемы и на то, как будет выглядеть это решение. Иначе говоря, подходите к выбору модели вдумчиво
Второй принцип формулируется так: каждая модель может быть воплощена с разной степенью абстракции.
Третий принцип: лучшие модели - те, что ближе к реальности.
Четвертый принцип заключается в том, что нельзя ограничиваться созданием только одной модели.Наилучший подход при разработке любой нетривиальной системы - использовать совокупность нескольких моделей, почти независимых друг от друга.
47. Объектно-ориентированный подход в моделирование
При разработке программного обеспечения тоже существует несколько подходов к моделированию. Важнейшие из них - алгоритмический и объектно-ориентированный.
Наиболее современным подходом к разработке программного обеспечения является объектно-ориентированный. Здесь в качестве основного строительного блока выступает объект или класс. В самом общем смысле объект - это сущность, обычно извлекаемая из словаря предметной области или решения, а класс является описанием множества однотипных объектов. Каждый объект обладает идентичностью (его можно поименовать или как-то по-другому отличить от прочих объектов), состоянием (обычно с объектом бывают связаны некоторые данные) и поведением (с ним можно что-то делать или он сам может что-то делать с другими объектами).
В Объектно-ориентированный подход к разработке программного обеспечения является сейчас преобладающим просто потому, что он продемонстрировал свою полезность при построении систем в самых разных областях любого размера и сложности. Кроме того, большинство современных языков программирования, инструментальных средств и операционных систем являются в той или иной мере объектно-ориентированными, а это дает веские основания судить о мире в терминах объектов. Объектно-ориентированные методы разработки легли в основу идеологии сборки систем из отдельных компонентов; в качестве примера можно назвать такие технологии, как JavaBeans и CQM+.
Визуализация, специфицирование, конструирование и документирование объектно-ориентированных систем - это и есть назначение языка UML.
48. Структура UML
В структуре универсального языка моделирования выделяют две основные составляющие:
• метамодель;
• правила построения диаграмм.
Метамодель представляет собой описание общей структуры языка, основных понятий объектно-ориентированного проектирования (класс, объект, событие, ассоциация, автомат, наследование и пр.), а также методов расширения ядра UML. Описания используемых терминов в общем совпадают с определениями, приводимыми в этой книге, поэтому мы не будем подробно на них останавливаться.
Основной интерес для проектировщика представляют правила построения UML-диаграмм, основными разновидностями которых являются диаграммы:
Qпрецедентов, или вариантов использования (use case diagram);
Qклассов (class diagram);
Qсостояний (statechart diagram);
Qактивности, или деятельности (activity diagram);
• взаимодействия (interaction diagrams), к которым относятся диаграммы последовательности (sequence diagram) и кооперации, или сотрудничества (collaboration diagram);
• компонентов (component diagram);
• развертывания (deployment diagram).
При проектировании информационной системы, как правило, составляется множество диаграмм одного и того же вида: множество диаграмм прецедентов, несколько диаграмм классов, множество диаграмм активности.
Не обязательно всегда составлять все диаграммы. Язык UML создан для облегчения процесса разработки, а не для утомительного документирования всех шагов разработки. Некоторые из диаграмм могут отсутствовать.
Последовательность построения диаграмм также свободна.
49. Связь в UML
Связь между объектами в информационной системе на уровне программирования на определенном языке осуществляется посредством передачи параметров (переменных) от одного объекта другому объекту. Например, объект Отдел продаж передает объекту Склад некоторый принятый в организации документ (переменную), в котором сообщает о необходимости выделения продукции той или иной номенклатуры. Значение передаваемых параметров является содержанием передаваемого посредством связи сообщения.
Сообщения на диаграммах сотрудничества изображаются стрелками вдоль связей. Порядок передачи сообщений может быть определен явным указанием номера сообщения возле стрелки. Вид сообщения несет дополнительную смысловую нагрузку в виде определения ролей взаимодействующих объектов. В зависимости от этого сообщения графически изображаются:
• сплошной линией с треугольной стрелкой – такое сообщение означает вызов процедуры (метода объекта) или вызов другого потока управления;
• сплошной линией с обычной стрелкой – такое сообщение означает простой поток управления, то есть просто передачу данных (рис. 3.37, б);
• сплошной линией с полустрелкой – такое сообщение не имеет заранее обусловленного времени передачи, являясь, как правило, асинхронным (рис. 3.37, в);
• пунктирной линией с обычной стрелкой – такое сообщение означает возврат значения из процедуры (рис. 3.37, г).
@настроение:
мля....не люблю экзамены..
@темы:
жизнь. плохая память.