2.Классификация ис по характеру обработки данных. Характерные отличия и задачи систем.

По характеру обработки данных:

-Информационно-поисковые

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

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

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

Управляющие ИС

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

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

Советующие ИС

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

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

3.Понятие «жизненный цикл» ис. Модели жц и их этапы. Соответствие моделей жц методикам разработки ис.

Понятие жизненного цикла (ЖЦ) является одним из ключевых понятий методологии проектирования информационных систем. Жизненный цикл информационной системы – это непрерывный процесс, начинающийся с момента принятия решения о создании информационной системы и заканчивающийся в момент полного изъятия ее из эксплуатации [4].

Основным стандартом, определяющим структуру жизненного цикла, является ГОСТ Р ИСО/МЭК 12207-02 [5]. Согласно стандарту структура жизненного цикла основывается на трех группах процессов:

· основные процессы (заказ, поставка, разработка, эксплуатация, сопровождение);

· вспомогательные процессы (обеспечивают выполнение основных процессов):

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

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

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

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

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

- совместный анализ – работы по оценке состояния или результатов какой-либо работы (системы);

- аудит – работы независимых (по отношению к проекту) экспертов по определению соответствия деятельности субъекта принятым требованиям, планам и условиям договора;

- разрешение проблем – работы по анализу и устранению проблем, обнаруженных при реализации проекта;

· организационные:

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

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

- усовершенствование – работы по оценке, контролю и улучшению процессов жизненного цикла;

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

Стадии жизненного цикла ПО ИС

Классический ЖЦ	ИСО / МЭК 12207	ГОСТ 34.601-90 и ОРММ ИСЖТ 5.03-00
		Стадия		Основные этапы (работы)
Системный анализ	Заказ	Формирование требований к ИС	Технико- экономическое обоснование (ТЭО)	1. Обследование объекта и обоснование необходимости создания ИС. 2. Формирование требований Заказчика к ИС. 3. Оформление договора между Разработчиком и Заказчиком.
Анализ требований	Разработка	Разработка концепции ИС (для комплексных многоуровневых и интегрированных систем)		Поиск путей удовлетворения требований Заказчика на уровне концепции создаваемой системы (структура, функции,программно-техническая платформа, режимы). 2. Рассмотрение альтернативных вариантов концепции системы, их анализ и выбор лучшей концепции.
Проектирование		Техническое задание (ТЗ)		Разработка, согласование и утверждение ТЗ на создание ИС.
		Эскизный проект (для комплексных многоуровневых и интегрированных систем)		Разработка предварительных проектных решений по системе и ее частям.
		Пилот-проект (макетирование3, прототипирование) (при необходимости)		1.Разработка частей проекта для испытаний в реальных, но ограниченных условиях функционирования с целью проверки предварительно принятых решений. Проведение испытаний на головном объекте или стенде и анализ результатов испытаний.
		Технический проект		1. Разработка проектных решений по системе и ее частям. 2. Разработка документации на ИС и ее части. 3. Разработка документации на поставку изделий для комплектования ИС и/или технических заданий на их разработку. 3.Разработка заданий на проектирование в смежных частях проекта объекта автоматизации (строительство, монтаж, наладка и др.).
Кодирование (реализация)		Рабочая документация		1. Разработка рабочей документации на систему и ее части. 2. Разработка программных и технических средств и/или адаптация приобретаемых. 3. Тестирование средств.
Тестирование		Интеграция и тестирование		1. Загрузка БД типовыми исходными данными и тестами. 2. Интеграция программ и тестирование в имитированной среде. 3. Интеграция программных средств с аппаратными в реальной операционной и внешней среде. 4. Тестирование в реальной среде. 5. Разработка комплекта документации для пользователей
Внедрение и сопровождение	Разработка и эксплуатация	Ввод в действие на головном объекте (ввод в эксплуатацию, внедрение)		1. Подготовка объекта автоматизации к вводу ИС в действие. 2. Подготовка персонала. 3. Комплектация ИС поставляемыми изделиями. 4. Проведение предварительных испытаний4 и передача ИС для опытной эксплуатации5. 5. Проведение опытной эксплуатации. 6. Проведение приемочных испытаний6 по сдаче ИС в постоянную эксплуатацию.
		Тиражирование (при внедрении на нескольких объектах)		1.Передача эталона загрузочных модулей ПО и эксплуатационной документации в группу сопровождения или ОФАП7 ОАО «РЖД». 2. Тиражирование документации. 3. Обучение и консультации пользователей. 4. Поставка ПО и документации на объекты внедрения.
	Сопровождение и эксплуатация	Сопровождение (авторский надзор)		1. Выполнение работ в соответствии с гарантийными обязательствами. 2. Оказание научно-технических услуг в послегарантийный период. 3. Разработка методики оформления отчетов об ошибках и предложениях на изменение версий. 4. Учет состояния конфигураций ИС.

Модели жизненного цикла: каскадная, модель с промежуточным контролем, спиральная

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

Известны следующие базовые модели жизненного цикла.

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

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

Рис. 1. Каскадная схема разработки ПО.

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

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

Для преодоления этих проблем предложена поэтапная модель с промежуточным контролем (рис. 2).Модель с промежуточным тестированием

Рис. 2. Поэтапная схема разработки ПО.

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

Затем появилась спиральная модель ЖЦ (рис. 3), в которой на начальных этапах ЖЦ осуществляются анализ и проектирование.

Рис 3. Спиральная модель.

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

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

Сравнительная характеристика моделей жизненного цикла.

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

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

 

Таблица 3.1. Сравнение моделей жизненного цикла

 

Характеристика проекта	Модель (стратегия)
	Каскадная	Поэтапная модель с промежуточным контролем	Спиральная
Новизна разработки и обеспеченность ресурсами	Типовой. Хорошо проработаны технология и методы решения задачи		Нетиповой (новаторский). Нетрадиционный для разработчика
	Ресурсов заказчика и разработчика хватает для реализации проекта в сжатые сроки	Ресурсов заказчика или разработчика не хватает для реализации проекта в сжатые сроки
Масштаб проекта	Малые и средние проекты	Средние и крупные проекты	Любые проекты
Сроки выполнения проекта	До года	До нескольких лет. Разработка одной версии может занимать срок от нескольких недель до года
Заключение отдельных договоров на отдельные версии	Заключается один договор. Версия и есть итоговый результат проекта	На отдельную версию или несколько последовательных версий обычно заключается отдельный договор
Определение основных требований в начале проекта	Да	Да	Нет
Изменение требований по мере развития проекта	Нет	Незначительное	Да
Разработка итерациями	Нет	Да	Да
Распространение промежуточного ПО	Нет	Может быть	Да

 

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

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

 ревизию (исправительную или опытную) – любые оперативные изменения программного и информационного обеспечения, а также БД,  необязательные в данный момент к передаче на объекты внедрения и связанные с устранением ошибок и усовершенствованием;

 модификацию – любые оперативные изменения программного и информационного обеспечения, а также БД, обязательные для передачи на объекты внедрения и обусловливающие изменение эксплуатационных характеристик без изменения функций (предусмотренных ТЗ), а также изменения, связанные с устранением ошибок, усовершенствованием;

 версию – любые изменения программного и информационного обеспечения, а также БД, обязательные для передачи на объекты внедрения, позволяющие выполнять заявленные или дополнительные функции, а также обеспечивающие переход на новые операционные системы и информационную среду;

 развитие (очередь) – плановые изменения информационной системы, связанные с введением новых функций и улучшением эксплуатационных характеристик, переходом на новую информационную среду, внедрением новых комплексов технических средств, новых информационных технологий и пр.

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

4.Состав команды разработчиков ИС

5. Работы, выполняемые на стадии технического проектирования ИС.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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