| |
Методологическую основу проектирования ПО составляет системный подход. Системный подход — это методология специального научного познания и социальной практики, а также объяснительный принцип, в основе которого лежит исследование объектов как систем.
Методологическая специфика системного подхода определяется тем, что он ориентирует исследование на:
раскрытие целостности объекта и обеспечивающих его механизмов;
выявление многообразных типов связей сложного объекта;
сведение этих связей в единую теоретическую картину.
|
Основные нормативно-правовые документы и стандарты в области информационных систем.
|
основные стандарты и руководящие документы:
– ГОСТ 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. Современный рынок аппаратно-программных средств и информационных сервисов.
|
|
|
| |
Скачать 0.9 Mb.