Презентация на тему Стандарты создания информационных систем

процессы жизненного цикла ИС
Взаимосвязь стадий и процессов жизненного цикла

автоматизированные системы. Автоматизированные системы. Стадии создания.
ГОСТ 34.602-89 Информационные технологии.

Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.
ГОСТ 34.201-89 Виды, комплектность и обозначение документов при создании автоматизированных систем
ГОСТ Р ИСО/МЭК 12207-2010 Информационная технология. Программная и системная инженерия. Процессы жизненного цикла программных средств.
ГОСТ Р ИСО/МЭК 15288 Процессы жизненного цикла систем
В.Н. Гусятников, А.И. Безруков. Стандартизация и разработка программных систем. – М.: Финансы и статистика, 2010.
Н.Н. Заботина. Проектирование информационных систем. – М.: Инфра-М, 2011
А.Е. Сатунина, Л.А. Сысоева. Управление проектом корпоративной информационной системы предприятия. – М.: Финансы и статистика; Инфра-М, 2009
Вендров А.М. Проектирование программного обеспечения экономической информационной системы. – М.: Финансы и статистика, 2000.
Вендров А.М. Практикум по проектированию программного обеспечения экономической информационной системы. – М.: Финансы и статистика, 2002.
Г.Н. Смирнова, А.А. Сорокин, Ю.Ф. Тельнов. Проектирование экономических информационных систем. - М.: Финансы и статистика, 2003

создания ИС
Стадия создания ИС – этап (часть) общего процесса

создания системы, ограниченный некоторыми временными рамками и заканчивающийся выпуском конкретного продукта (моделей, программных компонентов, документации). Например, для стадии проектирования – это логическая модель системы.
Процесс определяется как совокупность взаимосвязанных действий, преобразующих некоторые входные данные в выходные
Каждый процесс характеризуется определенными задачами и методами их решения, исходными данными, полученными от других процессов, и результатами
Отношение Стадий и Процессов = M:N.
Стадия – это «анатомия», структура, состав элементов, описание продукта.
Процесс – это «физиология», поведение, последовательность действий по переводу объекта автоматизации из одного состояния в другое

«О техническом регулировании»:
«Стандарт – документ, в котором в целях

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

работ различных проектных групп
Интеграция с внешними системами
Повторное использование (Повторное

использование кода (англ. code reuse) — методология проектирования компьютерных и других систем, заключающаяся в том, что система (компьютерная программа, программный модуль) частично либо полностью должна составляться из частей, написанных ранее компонентов и/или частей другой системы. Повторное использование — основная методология, которая применяется для сокращения трудозатрат при разработке сложных систем.)
«Унаследованные» системы (перевод унаследованных информационных подсистем, реализующих существующие бизнес-процессы, на новые технологии)

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

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

цикла
систем
(ISO/IEC 15288)
Категории услуг Software Engineering Environment, ориентированные на выполнение

конкретных видов деятельности (Activities), установленных разделом 5 (ISO/IEC 12207)

Стадии жизненного цикла (ГОСТ 34.601; ГОСТ 19.102; ГОСТ 2.103)

Hardware

Firmware

Software

ГОСТы на создание ИС

ГОСТу 34.601 - 90
Стадия 1. Формирование требований к ИС
Обследование

объекта и обоснование необходимости создания ИС
Формирование требований пользователей к ИС
Оформление отчета и тактико-технического задания на разработку
Стадия 2. Разработка концепции ИС
Изучение объекта автоматизации
Проведение необходимых НИР
Разработка вариантов концепции ИС, удовлетворяющих требованиям пользователей
Оформление отчета и утверждение концепции
Стадия 3. Техническое задание
Разработка и утверждение технического задания на создание ИС в соответствии с ГОСТ 34.602 -89
Стадия 4. Эскизный проект
Разработка предварительных проектных решений по системе и ее частям
Разработка эскизной документации

34.601 - 90
Стадия 5. Технический проект
Разработка проектных решений по

ИС и ее частям (функциональной и обеспечивающей)
Разработка документации по ИС и ее частям
Разработка и оформление документации на поставку комплектующих изделий (функциональных и обеспечивающих компонентов ИС)
Разработка заданий на проектирование в смежных частях проекта
Стадия 6 . Рабочая документация
Разработка рабочей документации на ИС и ее части
Разработка и адаптация программного обеспечения
Стадия 7. Ввод в действие
Подготовка объекта автоматизации
Подготовка персонала
Комплектация ИС поставляемыми компонентами
Строительно-монтажные и пуско-наладочные работы
Проведение предварительных испытаний
Проведение опытной эксплуатации
Проведение приемочных испытаний
Стадия 8. Проведение работ по гарантийному и послегарантийному обслуживанию

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

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

системный контекст для работы с автономным программным продуктом или

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

требований правообладателей
Цель процесса определения требований правообладателей (заказчиков) состоит

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

требований
Идентификация правообладателей (участников процесса создания ИС)
Идентификация требований ( из

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

проектирования архитектуры системы
Цель процесса проектирования архитектуры системы заключается в

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

6.4.4 Процесс реализации
Цель процесса реализации заключается в создании заданных элементов системы.

системы
Цель процесса комплексирования системы заключается в объединении системных элементов

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

приемки программных средств
Цель процесса поддержки приемки программных средств заключается

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

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

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

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

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

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

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

стандарту ИСО/МЭК 12207, требования к процессам

Процессы