Файл: Техническое задание на создание автоматизирован ной системы гост 34. 60389 Виды испытаний автоматизированных систем.docx

ВУЗ: Не указан

Категория: Не указан

Дисциплина: Не указана

Добавлен: 18.03.2024

Просмотров: 16

Скачиваний: 0

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

  • Системный подход к проектированию информационных систем

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

Методологическая специфика системного подхода определяется тем, что он ориентирует исследование на:

  • раскрытие целостности объекта и обеспечивающих его механизмов;

  • выявление многообразных типов связей сложного объекта;

  • сведение этих связей в единую теоретическую картину.




  • Основные нормативно-правовые документы и стандарты в области информационных систем.




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

– ГОСТ 34.201-91 Виды, комплектность и обозначения документов при создании автоматизированных систем;

– ГОСТ 34.601-90 Автоматизированные системы. Стадии создания;

– ГОСТ34.602-89 Техническое задание на создание автоматизирован-

ной системы;

– ГОСТ 34.603-89 Виды испытаний автоматизированных систем;

– ГОСТ 28195-89 Оценка качества программных средств. Общие по-

ложения;

– ГОСТ 28806-90 Качество программных, средств. Термины и опреде-

ления;

– РД 50-34.698-90 Методические указания. Автоматизированные сис-

темы. Требования к содержанию документов;

– ГОСТ Р ИСО/МЭК 12207-99 Информационная технология. Процессы жизненного цикла программных средств.


  • Назначение и основные положения модели процессов управления CobiT (“Задачи управления для информационных и смежных технологий”)

COBIT представляет собой пакет открытых документов, около 40 международных и национальных стандартов и руководств в области управления IT, аудита и IT-безопасности.

Основные положения:
1. Информационная безопасность;
2. Управление Рисками;
3. Управление непрерывностью бизнеса;


4.Управление качеством;
5. Обеспечение соответствия требованиям регуляторов;
6. Защита интеллектуальной собственности
Основной целью COBIT является управление информационными технологиями. Управление информационными технологиями в свою очередь является неотъемлемой частью корпоративного управления. Корпоративное управление – комплекс управленческих решений и практик, применяемых высшим руководством с целью:

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

·         обеспечения достижения целей;

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

  • эффективного использования корпоративных ресурсов.

Основные принципы COBIT:

‒ цели ИТ должны соответствовать целям бизнеса;

‒ использование процессного подхода;

‒ система контроля ИТ должна быть избирательной, то есть определять основные ресурсы ИТ и работать с ними;

‒ цели контроля должны быть четко определены.

  • Области знаний международного стандарта SWEBOK (“Сумма знаний по программной инженерии”).




Текущая опубликованная версия SWEBOK V3 включает 15 областей знаний в сфере программной инженерии:

  • software requirements — требования к ПО;

  • software design — проектирование ПО;

  • software construction — конструирование ПО;

  • software testing — тестирование ПО;

  • software maintenance — сопровождение ПО;

  • software configuration management — управление конфигурацией;

  • software engineering management — управление IT проектом;

  • software engineering process — процесс программной инженерии;

  • software engineering models and methods — модели и методы разработки;

  • software quality — качество ПО;

  • software engineering professional practice — описание критериев профессионализма и компетентности;

  • software engineering economics — экономические аспекты разработки ПО;

  • computing foundations — основы вычислительных технологий, применимых в разработке ПО;

  • mathematical foundations — базовые математические концепции и понятия, применимые в разработке ПО;

  • engineering foundations — основы инженерной деятельности.

  • Процессы жизненного цикла программных средств в соответствии со стандартом ГОСТ Р ИСО/МЭК 12207 – 2010.




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



a) процессы соглашения - два процесса

b) процессы организационного обеспечения проекта - пять процессов

c) процессы проекта - семь процессов

d) технические процессы - одиннадцать процессов

e) процессы реализации программных средств - семь процессов

f) процессы поддержки программных средств - восемь процессов

g) процессы повторного применения программных средств - три процесса



  • Каскадная, поэтапная и спиральная модели жизненного цикла информационных систем.

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



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



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




  • Методологии проектирования сложных систем.




Методология RAD

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

Жизненный цикл ИС методологии RAD состоит из четырех фаз: фаза анализа и планирования требований; фаза проектирования; фаза реализации; фаза внедрения.

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

1) разработка приложений итерациями;

2) необязательность полного завершения работ на каждом из этапов жизненного цикла;

3) обязательное вовлечение пользователей в процесс разработки ИС;

4) необходимое применение CASE-средств, обеспечивающих целостность проекта;

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

6) необходимое использование генераторов кода;

7) использование прототипов, позволяющих полнее выяснить и удовлетворить потребности конечного пользователя;

8) тестирование и развитие проекта, осуществляемые одновременно с разработкой;

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

10) грамотное руководство разработкой системы, четкое планирование и контроль выполнения работ.
Методология DATARUN

В соответствии с методологией DATARUN ЖЦ ИС разбивается на стадии, которые связываются с результатами выполнения основных процессов, определяемых стандартом ISO 12207. Каждую стадию кроме ее результатов должен завершать план работ на следующую стадию.

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

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

Подход DATARUN преследует две цели:

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

2) спроектировать ИС на основании модели данных.


  • Этапы процесса канонического проектирования информационных систем.




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

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

1. Формирование требований к ИС. Этапы работ: обследование объекта и обоснование необходимости создания ИС; формирование требований пользователей к ИС; оформление отчета о выполненной работе и тактико-технического задания на разработку.

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

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

4. Эскизный проект: разработка предварительных проектных решений по системе и ее частям; разработка эскизной документации на ИС и ее части (архитектура проекта: структура входных и выходных данных, предварительная схема БД, общая архитектура ИС (структура, информ.потоки, модель управления ИС))

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

6. Рабочая документация: разработка рабочей документации на ИС и ее части; разработка и адаптация программ.

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

8. Сопровождение АС: выполнение работ в соответствии с гарантийными обязательствами, послегарантийное обслуживание.


  • Технико-экономическое обоснование ИТ-проекта.

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

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

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

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


  • Особенности процесса разработки устава проекта.

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

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

  • Обоснование выполнения уникальной задачи развития.

  • Цели, задачи и результаты.

  • Имя и фамилию PM, границы его ответственности и полномочия.

  • Определение и структуру продукта.

  • Интересы и ожидания участников.

  • Критерии успеха.

  • Принципы организации и управления проектом.

  • Управление требованиями ИТ-проекта.

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

В соответствии с Глоссарием терминов программной инженерии IEEE, являющимся общепринятым международным стандартным глоссарием, требование это:

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

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

Документированное представление условий или возможностей для пунктов 1 и 2.

Требование должно обладать следующими характеристиками:

Единичность — требование описывает одну и только одну вещь.

Завершенность — требование полностью определено в одном месте и вся необходимая информация присутствует.

Последовательность — требование не противоречит другим требованиям и полностью соответствует документации.

Атомарность — требование нельзя разделить на более мелкие.

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

Актуальность — требование не стало устаревшим с течением времени.

Выполнимость — требование может быть реализовано в рамках проекта.

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

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

Проверяемость — реализованность требования может быть проверена.

  • Особенности процессов реализации ИТ-проектов

· зачастую в компании заказчика одновременно выполняются несколько ИТ-проектов;

· приоритеты выполнения проектов постоянно корректируются;

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

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

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

· налицо трудности планирования творческой деятельности, отсутствуют единые нормативы и стандарты;

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

· происходит постоянное совершенствование технологии выполнения работ.

13.Критические факторы успеха проекта.

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

Критические факторы успеха (КФУ проекта). Успех любого проекта может быть оценён по состоянию 10 критических факторов: 1 - ясность целей проекта 2 - поддержка руководства 3 - четкость планов 4 - взаимодействие с заказчиком 5 - наличие необходимых ресурсов 6 - наличие необходимьк технологий 7 - приёмка результатов заказчиком 8 - контроль выполнения проекта 9 - обеспечение необходимыми данными 10 - возможность управления непредвиденными ситуациями.

14. Методики идентификации рисков проекта

Обзор документации проекта

Анализ предположений

SWOT – анализ проекта

Метод «мозгового штурма»

Метод «Дельфи»

Интервью

Контрольные таблицы и диаграммы




15. Принципы построения функциональной модели в методологии IDEF0.


Под моделью в IDEF0 понимают описание системы (текстовое и графи­ческое), которое должно дать ответ на некоторые заранее определенные вопросы.

Центральным элементом модели IDEF0 является функция, которая на схеме отображается в виде функционального блока – прямоугольника, внутри которого указано действие в форме отглагольного существительного


16.Принципы построения информационной модели в методологии IDEF1X.

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

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

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

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

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

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

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

18.Задачи сопровождения информационных систем.

Сопровождение информационных систем (ИС) состоит из двух больших и разноплановых задач.

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

Вторая задача — внесение изменений в информационную систему. Изменения могут включать донастройки тиражируемого ПО или доработки заказного ПО.

19. CASE-средства проектирования информационных систем.

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

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

20. Основные виды информационных систем, их достоинства и недостатки.

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

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

21.Современные системы управления базами данных.

Среди наиболее ярких представителей систем управления базами данных можно отметить: Lotus Approach, Microsoft Access, Borland dBase, Borland Paradox, Microsoft Visual FoxPro, Microsoft Visual Basic, а также баз данных Microsoft SQL Server и Oracle, используемые в приложениях, построенных по технологии «клиент-сервер».

1. Lotus Approach- Approach предоставляет мощные, хотя и простые в использовании, инструментальные средства формирования запросов и отчетов, возможности связи с большим количеством разнообразных баз данных и высокую производительность при выполнении запроса. Достоинства: Простота использования при формировании запроса и отчета для разнообразных баз данных; лучшие в своем классе инструментальные средства построения отчетов по «живым» данным; возможность доступа к широкому разнообразию форматов баз данных с использованием технологии PowerKey.

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

2. Microsoft Access- реляционная система управления базами данных (СУБД) корпорации Microsoft. Входит в состав пакета Microsoft Office. Имеет широкий спектр функций, включая связанные запросы, связь с внешними таблицами и базами данных. Благодаря встроенному языку VBA, в самом Access можно писать приложения, работающие с базами данных.

3. Microsoft Visual FoxPro- среда разработки систем баз данных, включающая объектно-ориентированную реляционную СУБД, объектно-ориентированный язык программирования для разработки приложений баз данных и систему построения отчётов.

4. Microsoft SQL Server- система управления реляционными базами данных (РСУБД), разработанная корпорацией Microsoft. Основной используемый язык запросов — Transact-SQL, создан совместно Microsoft и Sybase. Transact-SQL является реализацией стандарта ANSI/ISO по структурированному языку запросов (SQL) с расширениями. Используется для работы с базами данных размером от персональных до крупных баз данных масштаба предприятия; конкурирует с другими СУБД в этом сегменте рынка.

22. Принципы построения баз данных BASE и ACID




23.Угрозы безопасности информационных систем и их классификация.

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




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