осуществление интеграции программных модулей отчет по практике

По производственной практике

ОТЧЕТ

ПП 03.01 Участие в интеграции программных модулей

Специальность 09.02.03 Программирование в компьютерных системах

Студента 4 курса 4П группы

форма обучения очная

_________________________________________________________________
(Фамилия, имя, отчество)

Место прохождения практики _________________________________________________________________________

(Полное наименование организации и адрес)

практики от организации ______________________________________

(отлично, хорошо, удовлетворительно, зачет)

от организации _________________ ____________/________________

(должность) (роспись, фамилия, инициалы)

практики от колледжа ___________________________________________

(отлично, хорошо, удовлетворительно, зачет)

от колледжа преподаватель ____________/Синцова Т.П. (Бобкова К.С.)

Программа производственной практики является частью программы подготовки специалистов среднего звена в соответствии с ФГОС по специальности СПО 09.02.03 Программирование в компьютерных системах в части освоения основного вида профессиональной деятельности: Участие в интеграции программных модулей

и соответствующих профессиональных компетенций (ПК):

1. Анализировать проектную и техническую документацию на уровне взаимодействия компонент программного обеспечения.

2. Выполнять интеграцию модулей в программную систему.

3. Выполнять отладку программного продукта с использованием специализированных программных средств.

4. Осуществлять разработку тестовых наборов и тестовых сценариев.

5. Производить инспектирование компонент программного продукта на предмет соответствия стандартам кодирования.

6. Разрабатывать технологическую документацию.

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

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

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

— модели процесса разработки программного обеспечения;

— основные принципы процесса разработки программного обеспечения;

— основные подходы к интегрированию программных модулей;

— основные методы и средства эффективной разработки;

— основы верификации и аттестации программного обеспечения;

— концепции и реализации программных процессов;

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

— методы организации работы в коллективах разработчиков программного обеспечения;

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

— стандарты качества программного обеспечения;

— методы и средства разработки программной документации.

Студенты при прохождении производственной практики обязаны:

— полностью выполнять задания, предусмотренные программой практики;

— вести ежедневно дневник;

— соблюдать действующие правила внутреннего распорядка;

— изучать и строго соблюдать нормы и правила пожарной безопасности;

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

Форма отчетности студентов:

— дневник, подписанный руководителем практики от предприятия;

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

— характеристика с места прохождения практики, заверенная печатью и подписью руководителя практики;

— аттестационный лист, подписанный руководителем практики от предприятия,

— командировочное удостоверение, подписанное и заверенное печатью организации.

1 ИЗУЧЕНИЕ И СБОР ОБЩИХ СВЕДЕНИЙ О ПРЕДПРИЯТИИ (ОРГАНИЗАЦИИ).

Название предприятия (организации), год регистрации, место нахождения

Юридический статус, учредительные документы

Характеристика продукции, выпускаемой предприятием или описание оказываемых услуг.

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

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

2 ОПИСАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ, ИСПОЛЬЗУЕМОЙ НА ПРЕДПРИЯТИИ

2.1 Общее описание информационной системы

Название автоматизированной системы, конфигурация.

2.2 Основные документы, заполняемые в программе (скрин списка документов)

2.3 Основные отчеты, получаемые в программе (скрин заполненных отчетов)

2.4 Диаграмма классов информационной системы (не более 10 классов и их отношения)

3 РАЗРАБОТКА ИНФОРМАЦИОННОЙ СИСТЕМЫ

3.1 Техническое задание на разработку информационной системы

3.2 Диаграмма вариантов использования

3.3 Диаграмма классов

3.4 Диаграмма последовательности

3.5 Диаграмма деятельности

3.6 Разработка теста с использованием стратегии «белого ящика»

3.7 Руководство пользователя

Министерство образования и науки Удмуртской Республики

БПОУ УР «Сарапульский политехнический колледж»

ДНЕВНИК

по производственной практике (по профилю специальности)

03.01 Участие в интеграции программных модулей

Специальность09.02.03 Программирование в компьютерных системах

Фамилия, имя, отчество

форма обучения очная

Руководитель практики от колледжа Синцова Т.П. (Бобкова К.С.)

Руководитель практики от предприятия

Полное наименование организации и адрес

Фамилия, имя, отчество, должность

Срок практики с 07.11 2016г. по 17.12.2016г.

Задание

на производственную практику(по профилю специальности)

ПМ.03 Участие в интеграции программных модулей

Выдано обучающемуся БПОУ УР «СПК»

по специальности 09.02.03 Программирование в компьютерных системах

Для прохождения практики на:

(полное наименование предприятия(организации) прохождения практики)

Дата начала практики 07.11.2016г.

Дата окончания практики 17.12.2016г.

Дата сдачи отчёта по практике 19.12.2016г.

Теоретическая часть задания:

1. Повторить раздел Моделирование информационных систем на языке UML.

2. Повторить раздел Создание объектов конфигурации в системе 1С:Предприятие.

3. Повторить раздел Техническая и эксплуатационная документация.

Источник

Отчет по практике на тему «Интеграция программных модулей»

Отчет по практике на тему «Интеграция программных модулей»

Тип. Отчет по производственной практике

Направление. Участие в интеграции программных модулей

Год написания. 2016

Отчет по производственной практике на тему «Интеграция программных модулей»

Описание

История ОЗНА началась в начале 1950-х годов, в период послевоенного восстановления народного хозяйства и бурного развития нефтяной промышленности СССР. В марте 1953 года в г. Октябрьском (Башкирия) был построен ремонтно-механический завод, ставший основой Компании. Его продукция была востребована на нефтепромыслах республики, где шла интенсивная добыча черного золота.

В январе 1958 года в Октябрьском построен завод по производству приборов и средств автоматизации и диспетчеризации «Нефтеавтоматика». Эти два предприятия уверенно заняли положение лидеров в своей отрасли.

В 1950—1960 гг. оборудование ОЗНА поставлялось преимущественно нефтяникам Башкирии, показывавшим самый значительный рост нефтедобычи в стране, за что республика была удостоена почётного наименования «второе Баку».

С 1970-х гг. Компания начала серийные поставки блочных кустовых и нефтеперекачивающих насосных станций, блоков дозирования реагентов, замерных установок и другого нефтепромыслового оборудования. В число заказчиков продукции ОЗНА, помимо отечественных нефтяников, вошли предприятия стран Совета экономической взаимопомощи (СЭВ): Болгарии, Румынии, Югославии.

Трансформации 1990-х годов потребовали новых подходов к организации деятельности: 1990 год — создано арендное предприятие (АП) «ОЗАО и П»; 1991 год — внедрена блочная система управления производством; 1992 год — принято решение о приватизации путем акционирования; 1993 год — на базе АП «ОЗАО и П» образовано «Акционерное общество открытого типа «ОЗНА». 12 июля 1996 года создано ОАО «Акционерная компания ОЗНА».

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

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

Источник

Участие в интеграции программных модулей

Жизненный цикл программного продукта. Современные среды разработки приложений. Защита информации в базах данных. Особенности разработки приложения с помощью среды Delphi 7. Проверка программного модуля на предмет соответствия стандартам кодирования.

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http: //www. allbest. ru/

АВТОНОМНАЯ НЕКОММЕРЧЕСКАЯ ОРГАНИЗАЦИЯ

ОКТЯБРЬСКИЙ ЭКОНОМИЧЕСКИЙ ТЕХНИКУМ

по производственной практике

ПМ.03. Участие в интеграции программных модулей

студент группы 4ПР1-13 Л.З. Каримов

преподаватель А.Ю. Рамазанова

1. ТЕОРЕТИЧЕСКАЯ ЧАСТЬ

1.1 Жизненный цикл программного продукта

1.2 Основные модели процесса разработки программного обеспечения

1.3 Организация процесса разработки программного обеспечения

1.4 Проектирование и разработка программного обеспечения

1.5 Интеграция системы

1.6 Среды разработки приложений

1.8 Защита информации в базах данных

1.9 Стандартизация защищенности программ

1.10 Сертификация и порядок её проведения

1.11 Подготовка к эксплуатации

2. ПРАКТИЧЕСКАЯ ЧАСТЬ

2.1 Техническое задание

2.1.1 Основание для разработки

2.1.2 Назначение разработки

2.1.3 Требования к программе

2.1.3.1 Требования к функциональным характеристикам

2.1.3.2 Требования к надежности

2.1.3.3 Требования к составу и параметрам технических средств

2.1.3.4 Требования к информационной и программной совместимости

2.1.3.5 Требования к транспортированию и хранению

2.1.3.6 Специальные требования

2.1.4 Требования к программной документации

2.2 Описание программы

2.2.1 Общие сведения о программе

2.2.2 Функциональное назначение

2.2.3 Описание логической структуры

2.3 Руководство оператора

2.3.1 Назначение программы

2.3.2 Условия выполнения программы

2.3.3 Выполнение программы

2.3.4 Сообщения оператору

2.4.1 Подготовка перечня документации для прохождения сертификации

2.4.2 Проверка соответствия требованиям

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

2.4.4 Приемка и эксплуатация программного обеспечения

2.4.5 Разработка пользовательской документации

2.4.6 Определение состава документации

2.4.7 Подготовка руководства пользователя

История ОЗНА началась в начале 1950-х годов, в период послевоенного восстановления народного хозяйства и бурного развития нефтяной промышленности СССР. В марте 1953 года в г. Октябрьском (Башкирия) был построен ремонтно-механический завод, ставший основой Компании. Его продукция была востребована на нефтепромыслах республики, где шла интенсивная добыча черного золота.

В январе 1958 года в Октябрьском построен завод по производству приборов и средств автоматизации и диспетчеризации «Нефтеавтоматика». Эти два предприятия уверенно заняли положение лидеров в своей отрасли.

В 1950—1960 гг. оборудование ОЗНА поставлялось преимущественно нефтяникам Башкирии, показывавшим самый значительный рост нефтедобычи в стране, за что республика была удостоена почётного наименования «второе Баку».

С 1970-х гг. Компания начала серийные поставки блочных кустовых и нефтеперекачивающих насосных станций, блоков дозирования реагентов, замерных установок и другого нефтепромыслового оборудования. В число заказчиков продукции ОЗНА, помимо отечественных нефтяников, вошли предприятия стран Совета экономической взаимопомощи (СЭВ): Болгарии, Румынии, Югославии.

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

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

— с проектной и технической документацией на уровне взаимодействия компонент программного обеспечения;

— выполнения интеграции модулей в программную среду;

— выполнения отладки программного продукта с использованием специализированных программных средств;

— разработки текстовых наборов и текстовых сценариев;

— проведения инспектирования компонент программного продукта на предмет соответствия стандартам кодирования.

1. ТЕОРЕТИЧЕСКАЯ ЧАСТЬ

1.1 Жизненный цикл программного продукта

Стандарт ГОСТ 34.601-90 предусматривает следующие стадии и этапы создания автоматизированной системы:

1. Формирование требований к автоматизированной системе

1.1. Обследование объекта и обоснование необходимости создания автоматизированной системы

1.2. Формирование требований пользователя к автоматизированной системе

1.3. Оформление отчета о выполнении работ и заявки на разработку автоматизированной системы

2. Разработка концепции автоматизированной системы

2.1. Изучение объекта

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

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

2.4. Оформление отчета о проделанной работе

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

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

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

4.2. Разработка документации на автоматизированную систему и её части

5. Технический проект

5.1. Разработка проектных решений по системе и её частям

5.2. Разработка документации на автоматизированную систему и её части

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

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

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

6.1. Разработка рабочей документации на автоматизированную систему и её части

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

7.1. Подготовка объекта автоматизации

7.2. Подготовка персонала

7.3. Комплектация автоматизированной системы поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями)

7.4. Строительно-монтажные работы

7.5. Пусконаладочные работы

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

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

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

8. Сопровождение автоматизированной системы

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

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

1.2 Основные модели процесса разработки программного обеспечения

Модель кодирования и устранения ошибок.

Совершенно простая модель, характерная для студентов ВУЗов. Именно по этой модели большинство студентов разрабатывают лабораторные работы.

Данная модель имеет следующий алгоритм:

— при необходимости переход к первому пункту.

Модель ужасно устаревшая и характерна для 1960-1970 гг., поэтому преимуществ перед следующими моделями практически не имеет, а недостатки на лицо.

Каскадная модель жизненного цикла программного обеспечения представлена на рисунке 1.

Рисунок 1 Каскадная модель жизненного цикла программного обеспечения

— последовательное выполнение этапов проекта в строгом фиксированном порядке;

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

— отсутствие обратных связей между этапами;

— не соответствует реальным условиям разработки программного продукта.

Каскадная модель с промежуточным контролем (водоворот).

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

V модель (разработка через тестирование).

Данная модель имеет более приближенный к современным методам алгоритм, однако все еще имеет ряд недостатков. Является одной из основных практик экстремального программирования. Изображение представлено на рисунке 2.

Рисунок 2 V модель

Модель на основе разработки прототипа.

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

— Прояснить не ясные требования;

— Выбрать одно из ряда концептуальных решений;

— Проанализировать осуществимость проекта.

— Горизонтальные и вертикальные;

— Одноразовые и эволюционные;

— бумажные и раскадровки.

Спиральная модель жизненного цикла программного обеспечения.

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

Быстрое получение результата

Отсутствие регламентации стадий

Изображение модели представлено на рисунке 3.

Рисунок 3 Спиральная модель жизненного цикла

1.3 Организация процесса разработки программного обеспечения

В ноябре 1986 года американский институт Software Engineering Institute (SEI) совместно с Mitre Corporation начали разработку обзора зрелости процессов разработки программного обеспечения, который был предназначен для помощи в улучшении их внутренних процессов.

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

В сентябре 1987 года SEI выпустил краткий обзор процессов разработки программного обеспечения с описанием их уровней зрелости, а также опросник, предназначавшийся для выявления областей в компании, в которых были необходимы улучшения. Однако, большинство компаний рассматривало данный опросник в качестве готовой модели, вследствие чего через 4 года вопросник был преобразован в реальную модель, Capability Maturity Model for Software (CMM). Первая версия СММ (Version 1.0), вышедшая в 1991 году, в 1992 году была пересмотрена участниками рабочей встречи, в которой принимали участие около 200 специалистов в области программного обеспечения, и членами общества разработчиков.

Использование модели на практике выявило неоднозначность в подходах к достижению более высоких уровней организации процессов разработки программного обеспечения. Поэтому к 2002 году разрабатываются рекомендации по улучшению процесса разработки, которые получают название CMMI (Capability Maturity Model Integration).

1.4 Проектирование и разработка программного обеспечения

Целью проектирования является определение внутренних свойств системы и детализации её внешних (видимых) свойств на основе выданных заказчиком требований к программному обеспечению (исходные условия задачи). Эти требования подвергаются анализу.

Первоначально программа рассматривается как чёрный ящик. Ход процесса проектирования и его результаты зависят не только от состава требований, но и выбранной модели процесса, опыта проектировщика.

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

Проектированию обычно подлежат:

— Архитектура программного обеспечения;

— Устройство компонентов программного обеспечения;

В российской практике проектирование ведется поэтапно в соответствии со стадиями, регламентированными ГОСТ 2.103-68:

— техническое задание(по ГОСТ 2.103-68 к стадиям разработки не относится);

На каждом из этапов формируется свой комплект документов, называемый проектом (проектной документацией).

В зарубежной практике регламентирующими документами, например, являются Software Architecture Document, Software Design Document.

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

1.5 Интеграция системы

Задача интеграции информационных и учетных систем состоит из двух взаимосвязанных частей: интеграция приложений и интеграция данных. Без интеграции данных невозможно провести интеграцию приложений.

1.6 Среды разработки приложений

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

Dartmouth BASIC был первым языком, который был создан с IDE, и был также первым, который был разработан для использования в консоли или терминале. Эта IDE (часть Dartmouth Time Sharing System) управлялась при помощи команд, поэтому существенно отличалась от более поздних, управляемых с помощью меню и горячих клавиш, и тем более графических IDE, распространённых в XXI веке. Однако она позволяла редактировать исходный код, управлять файлами, компилировать, отлаживать и выполнять программы способом, принципиально подобным современным IDE.

Одной из первых IDE с возможностью подключения плагинов была Softbench.

Среда разработки включает в себя:

— компилятор и/или интерпретатор;

— средства автоматизации сборки;

Язык был создан в 1970х годах под названием “SEQUEL” для системы управления базами данных System R. Позднее он был переименован в “SQL” во избежание конфликта торговых марок. В 1979 году SQL был впервые опубликован в виде коммерческого продукта Oracle V2.

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

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

SQL состоит из четырех отдельных частей:

1. Язык определения данных (DDL) используется для определения структур данных, хранящихся в базе данных. Операторы DDL позволяют создавать, изменять и удалять отдельные объекты в базе данных. Допустимые типы объектов зависят от используемой системы управления базами данных и обычно включают базы данных, пользователей, таблицы и ряд более мелких вспомогательных объектов, например, роли и индексы.

Основными его командами являются:

— CREATE DATABASE (создать базу данных);

— CREATE TABLE (создать таблицу);

— CREATE VIEW (создать виртуальную таблицу);

— CREATE INDEX (создать индекс);

— CREATE TRIGGER (создать триггер);

— CREATE PROCEDURE (создать сохраненную процедуру);

— ALTER DATABASE (модифицировать базу данных);

— ALTER TABLE (модифицировать таблицу);

— ALTER VIEW (модифицировать виртуальную таблицу);

— ALTER INDEX (модифицировать индекс);

— ALTER TRIGGER (модифицировать триггер);

— ALTER PROCEDURE (модифицировать сохраненную процедуру);

— DROP DATABASE (удалить базу данных);

— DROP TABLE (удалить таблицу);

— DROP VIEW (удалить виртуальную таблицу);

— DROP INDEX (удалить индекс);

— DROP TRIGGER (удалить триггер);

— DROP PROCEDURE (удалить сохраненную процедуру.

2. Язык манипуляции данными (DML) используется для извлечения и изменения данных в базе данных. Операторы DML позволяют извлекать, вставлять, изменять и удалять данные в таблицах. Иногда операторы select извлечения данных не рассматриваются как часть DML, поскольку они не изменяют состояние данных. Все операторы DML носят декларативный характер.

Основными его командами являются:

3. Язык определения доступа к данным (DCL) используется для контроля доступа к данным в базе данных. Операторы DCL применяются к привилегиям и позволяют выдавать и отбирать права на применение определенных операторов DDL и DML к определенным объектам базы данных.

Основными его командами являются:

— REVOKE (забрать права)

4. Язык управления транзакциями (TCL) используется для контроля обработки транзакций в базе данных. Обычно операторы TCL включают commit для подтверждения изменений, сделанных в ходе транзакции, rollback для их отмены и savepoint для разбиения транзакции на несколько меньших частей.

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

1.8 Защита информации в базах данных

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

Методы защиты баз данных в различных системах управления базами данных условно делятся на две группы (анализ современных фирм Borland и Microsoft): основные и дополнительные.

К основным средствам защиты относится:

— разделение прав доступа к объектам базы данных;

— защита полей и записей таблиц базы данных.

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

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

Шифрование обеспечивает три состояния безопасности информации:

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

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

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

К дополнительным средствам защиты баз данных можно отнести следующие средства:

— встроенные средства контроля значений данных в соответствии с типами:

— повышение достоверности вводимых данных:

— обеспечения целостности связей таблиц:

— организации совместного использования объектов базы данных в сети.

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

1.9 Стандартизация защищенности программ

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

Функциональные требования сгруппированы на основе выполняемой ими роли или обслуживаемой цели безопасности, всего 11 функциональных классов (в трёх группах), 66 семейств, 135 компонентов.

Первая группа определяет элементарные сервисы безопасности:

Вторая группа описывает производные сервисы, реализованные на базе элементарных:

Третья группа классов связана с инфраструктурой объекта оценки:

Первая группа содержит классы требований, предшествующих разработке и оценке объекта:

Вторая группа связана с этапами жизненного цикла объекта аттестации:

1.10 Сертификация и порядок её проведения

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

— определения соответствия или несоответствия элементов

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

— определения эффективности внедренной системы качества

предприятия с точки зрения соответствия поставленным целям для

— обеспечения качества продукции;

— обеспечения возможности предприятию улучшить свою сис-

— определения соответствия системы качества производства

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

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

Порядок проведения сертификации в России установлен постановлением Госстандарта России от 21 сентября 1994 г. № 15 по отношению к обязательной сертификации (в том числе и импортируемой продукции), но может применяться и при добровольной сертификации. Для систем сертификации однородной продукции с учетом ее особенностей допускается разработка соответствующего порядка.

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

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

Этап оценки системы качества на предприятии начинается с подготовки в органе по сертификации. При подготовке к проверке и оценке системы качества выполняют следующие работы:

— составляют программу проверки;

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

— подготавливают рабочие документы;

— согласуют программы проверки с проверяемой организацией.

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

На этом этап практической оценки соответствия при сертификации систем качества заканчивается.

3. Этап анализа практической оценки соответствия объекта сертификации установленным требованиям заключается в рассмотрении результатов испытаний, экзамена или проверки системы качества в органе по сертификации.

При сертификации систем качества анализ результатов оценки соответствия проводится на основании акта о проверке. Выводы по акту сводятся к одному из трех вариантов:

1) система полностью соответствует заявленному стандарту;

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

3) система содержит значительные несоответствия.

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

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

1.11 Подготовка к эксплуатации

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

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

2. ПРАКТИЧЕСКАЯ ЧАСТЬ

2.1 Техническое задание

2.1.1 Основание для разработки

Основанием для разработки является задание на производственную практику ПМ.03. Участие в интеграции программных модулей от 30 января 2017 года.

Наименование работы: Автоматизированная информационная система “Учет работы ОЗНА”.

2.1.2 Назначение разработки

Автоматизированная информационная система “Учёт работы «АК ОЗНА»” предназначена для сбора сведений о выполненной работе за определённый промежуток времени и ведения статистики. Пользователями программы выступают бухгалтера компании, отдел учёта, отдел приема и оформления заявок. Выполнение заявок осуществляется на основании договоров о сотрудничестве, в которых оговариваются условия и стоимость работ. Менеджер ведёт учёт полученных заявок, где указывается номер по порядку, срок выполнения, наименование заявки или поломки, фамилия заказчика.

2.1.3 Требования к программе

2.1.3.1 Требования к функциональным характеристикам

Автоматизированная информационная система “Учет работы ОЗНА” должна обеспечивать выполнение функций:

— ввод, хранение, поиск и обработку информации по производству;

— ввод, хранение, поиск и обработку информации по заказам на предприятии;

— ввод, хранение, поиск и обработку информации по работникам, должностям на предприятии;

2.1.3.2 Требования к надежности

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

— возможность самовосстановления после сбоев (отключения электропитания, сбои в операционной системе и т.д.);

— ограничение несанкционированного доступа к данным;

— возможность резервного копирования информационной базы.

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

2.1.3.3 Требования к составу и параметрам технических средств

Системные требования для работы программного продукта должны быть следующими:

— тактовая частота процессора 1.2 ГГц;

— объём оперативной памяти 64 Мб;

— объём свободного дискового пространства 50 Мб;

— разрешение монитора 1024 x 768;

— наличие устройства чтения компакт-дисков.

2.1.3.4 Требования к информационной и программной совместимости

Программа должна работать в операционных системах Windows XP и выше. Все формируемые отчёты должны иметь возможность экспортирования в редактор электронных таблиц MS Office Access 2003 и выше.

2.1.3.5 Требования к транспортированию и хранению

Программа поставляется на лазерном носителе информации. Программная документация поставляется в электронном и печатном виде.

2.1.3.6 Специальные требования

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

Ввиду объемности проекта задачи предполагается решать поэтапно. При этом модули программного обеспечения ПО, сделанные в разное время, должны быть совместимы друг с другом, поэтому документация на принятое эксплуатационное ПО должна содержать полную информацию, необходимую для работы с ним программистов. Язык программирования определяется выбором исполнителя, при этом должен обеспечивать возможность поддержки программного обеспечения с пакетом MS Office 2003 и выше.

2.1.3.7 Требования к программной документации

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

Экономический эффект от внедрения автоматизированной информационной системы “Учет работы ОЗНА” ожидается за счёт сокращения времени на выполняемые менеджерами операции, исключения ошибок при формировании отчётов, увеличения времени на анализ хозяйственной деятельности и т.д.

2.2 Описание программы

2.2.1 Общие сведения о программе

Программа “Учет работы ОЗНА” предназначена для хранения, изменения, добавления информации об изделиях на предприятии.

Исходными данными является информация о заказчиках, заявках, о специалистах ОЗНА с которым пользователь будет осуществлять работу.

Ввод и редактирование данных в программе происходит путем перехода на нужную таблицу после выбора таблицы в меню с названием “Таблицы”. Просмотр данных соответствующих запросов происходит путем выбора нужного запроса в меню с названием “Запросы”.

2.2.2 Функциональное назначение

Функциональным назначением программы “Учет работы ОЗНА” является:

— переход на следующую/предыдущую строку;

— переход в начало/конец списка;

— просмотр различных запросов.

2.2.3 Описание логической структуры

Работы программы начинается с запуска “Учет работы ОЗНА.exe”. Осуществляется переход на первую форм.

На первой форме расположены:

Макет первой формы представлен на рисунке 5.

Рисунок 5 Макет первой формы

При нажатии в меню на кнопку “Выход” происходит полное закрытие программы. Для этого используется процедура:

procedure TForm1.N10Click(Sender: TObject);

Для открытия одной из таблиц необходимо выбрать в меню с названием “Таблицы”, после этого в списке отобразится выбранная таблица с подстроенным размером колонок. Для этого используется процедура:

procedure TForm1.N2Click(Sender: TObject);

ADOQuery1.SQL.Add(‘SELECT * FROM Заявки’);

do DBGrid1.Columns.Items[i].Width := 101;

procedure TForm1.N3Click(Sender: TObject);

ADOQuery1.SQL.Add(‘SELECT * FROM Заказчики);

do DBGrid1.Columns.Items[i].Width := 87;

procedure TForm1.N7Click(Sender: TObject);

ADOQuery1.SQL.Add(‘SELECT * FROM [Исполнение заявок]’);

do DBGrid1.Columns.Items[i].Width := 114;

procedure TForm1.N4Click(Sender: TObject);

ADOQuery1.SQL.Add(‘SELECT * FROM [Специалисты ОЗНА]’);

do DBGrid1.Columns.Items[i].Width := 114;

procedure TForm1.N5Click(Sender: TObject);

ADOQuery1.SQL.Add(‘SELECT * FROM [Список предприятий]’);

do DBGrid1.Columns.Items[i].Width := 146;

Для выбора одного из заданных запросов необходимо выбрать один из запросов в меню “Запросы”, после этого в списке отобразится выбранный запрос. Для этого используется процедура:

procedure TForm1.N12Click(Sender: TObject);

ADOQuery1.SQL.Add(‘SELECT * FROM Заказ’);

do DBGrid1.Columns.Items[i].Width := 100;

procedure TForm1.N13Click(Sender: TObject);

ADOQuery1.SQL.Add(‘SELECT * FROM Предприятия’);

do DBGrid1.Columns.Items[i].Width := 100;

На третьей форме расположены:

— выпадающий список для ввода информации.

Макет третьей формы представлен на рисунке 6.

Рисунок 6 Макет третьей формы

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

procedure TForm3.FormActivate(Sender: TObject);

При нажатии на кнопку “Добавить” третья форма закроется, после этого на первой форме в списке отобразится информация по выбранным критериям. Для этого используется процедура:

procedure TForm3.Button1Click(Sender: TObject);

Источник