Файл: Техническое задание на создание автоматизирован ной системы гост 34. 60389 Виды испытаний автоматизированных систем.docx
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 18.03.2024
Просмотров: 15
Скачиваний: 0
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
| Методологическую основу проектирования ПО составляет системный подход. Системный подход — это методология специального научного познания и социальной практики, а также объяснительный принцип, в основе которого лежит исследование объектов как систем. Методологическая специфика системного подхода определяется тем, что он ориентирует исследование на:
|
| основные стандарты и руководящие документы: – ГОСТ 34.201-91 Виды, комплектность и обозначения документов при создании автоматизированных систем; – ГОСТ 34.601-90 Автоматизированные системы. Стадии создания; – ГОСТ34.602-89 Техническое задание на создание автоматизирован- ной системы; – ГОСТ 34.603-89 Виды испытаний автоматизированных систем; – ГОСТ 28195-89 Оценка качества программных средств. Общие по- ложения; – ГОСТ 28806-90 Качество программных, средств. Термины и опреде- ления; – РД 50-34.698-90 Методические указания. Автоматизированные сис- темы. Требования к содержанию документов; – ГОСТ Р ИСО/МЭК 12207-99 Информационная технология. Процессы жизненного цикла программных средств. |
| COBIT представляет собой пакет открытых документов, около 40 международных и национальных стандартов и руководств в области управления IT, аудита и IT-безопасности. Основные положения: 1. Информационная безопасность; 2. Управление Рисками; 3. Управление непрерывностью бизнеса; 4.Управление качеством; 5. Обеспечение соответствия требованиям регуляторов; 6. Защита интеллектуальной собственности Основной целью COBIT является управление информационными технологиями. Управление информационными технологиями в свою очередь является неотъемлемой частью корпоративного управления. Корпоративное управление – комплекс управленческих решений и практик, применяемых высшим руководством с целью: · определения стратегического направления; · обеспечения достижения целей; · адекватного управления рисками;
Основные принципы COBIT: ‒ цели ИТ должны соответствовать целям бизнеса; ‒ использование процессного подхода; ‒ система контроля ИТ должна быть избирательной, то есть определять основные ресурсы ИТ и работать с ними; ‒ цели контроля должны быть четко определены. |
| Текущая опубликованная версия SWEBOK V3 включает 15 областей знаний в сфере программной инженерии:
|
| Настоящий стандарт группирует различные виды деятельности, которые могут выполняться в течение жизненного цикла программных систем, в семь групп процессов. Каждый из процессов жизненного цикла в пределах этих групп описывается в терминах цели и желаемых выходов, списков действий и задач, которые необходимо выполнять для достижения этих результатов. 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), ответственные лица за ключевые блоки. В приказе, как правило, отражается укрупненный план проекта в одной из первых его редакций. Структурная схема устава приводится далее. Он разрабатывается итерационно и может иметь несколько редакций, постепенно уточняющих основные положения, которые включают следующие аспекты.
|
| Управление требованиями — процесс, включающий идентификацию, выявление, документацию, анализ, отслеживание, приоретизацию требований, достижение соглашений по требованиям и затем управление изменениями и уведомление заинтересованных лиц. Управление требованиями — непрерывный процесс на протяжении всего жизненного цикла продукта. В соответствии с Глоссарием терминов программной инженерии 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. Современный рынок аппаратно-программных средств и информационных сервисов. | |
| | |
