Файл: Отчет по производственной практике пм. 03. Участие в интеграции программных модулей.docx
Добавлен: 07.11.2023
Просмотров: 179
Скачиваний: 8
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
АВТОНОМНАЯ НЕКОММЕРЧЕСКАЯ ОРГАНИЗАЦИЯ
ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ
ОКТЯБРЬСКИЙ ЭКОНОМИЧЕСКИЙ ТЕХНИКУМ
ОТЧЕТ
по производственной практике
ПМ.03. Участие в интеграции программных модулей
Выполнил
студент группы 4ПР1-13 Л.З. Каримов
Принял
преподаватель А.Ю. Рамазанова
СОДЕРЖАНИЕ
ВВЕДЕНИЕ
1. ТЕОРЕТИЧЕСКАЯ ЧАСТЬ
1.1 Жизненный цикл программного продукта
1.2 Основные модели процесса разработки программного обеспечения
.3 Организация процесса разработки программного обеспечения
.4 Проектирование и разработка программного обеспечения
.5 Интеграция системы
.6 Среды разработки приложений
.7 Язык SQL
.8 Защита информации в базах данных
.9 Стандартизация защищенности программ
.10 Сертификация и порядок её проведения
.11 Подготовка к эксплуатации
2. ПРАКТИЧЕСКАЯ ЧАСТЬ
2.1 Техническое задание
2.1.1 Основание для разработки
2.1.2 Назначение разработки
.1.3 Требования к программе
2.1.3.1 Требования к функциональным характеристикам
2.1.3.2 Требования к надежности
.1.3.3 Требования к составу и параметрам технических средств
.1.3.4 Требования к информационной и программной совместимости
.1.3.5 Требования к транспортированию и хранению
.1.3.6 Специальные требования
2.1.4 Требования к программной документации
2.2 Описание программы
2.2.1 Общие сведения о программе
2.2.2 Функциональное назначение
.2.3 Описание логической структуры
2.3 Руководство оператора
.3.1 Назначение программы
2.3.2 Условия выполнения программы
.3.3 Выполнение программы
.3.4 Сообщения оператору
2.4 Сертификация
.4.1 Подготовка перечня документации для прохождения сертификации
2.4.2 Проверка соответствия требованиям
.4.3 Подготовка к сертификационным испытаниям и их проведение
.4.4 Приемка и эксплуатация программного обеспечения
.4.5 Разработка пользовательской документации
.4.6 Определение состава документации
.4.7 Подготовка руководства пользователя
ЗАКЛЮЧЕНИЕ
СПИСОК ЛИТЕРАТУРЫ
ПРИЛОЖЕНИЕ А
ВВЕДЕНИЕ
История ОЗНА началась в начале 1950-х годов, в период послевоенного восстановления народного хозяйства и бурного развития нефтяной промышленности СССР. В марте 1953 года в г. Октябрьском (Башкирия) был построен ремонтно-механический завод, ставший основой Компании. Его продукция была востребована на нефтепромыслах республики, где шла интенсивная добыча черного золота.
В январе 1958 года в Октябрьском построен завод по производству приборов и средств автоматизации и диспетчеризации «Нефтеавтоматика». Эти два предприятия уверенно заняли положение лидеров в своей отрасли.
В 1950-1960 гг. оборудование ОЗНА поставлялось преимущественно нефтяникам Башкирии, показывавшим самый значительный рост нефтедобычи в стране, за что республика была удостоена почётного наименования «второе Баку».
С 1970-х гг. Компания начала серийные поставки блочных кустовых и нефтеперекачивающих насосных станций, блоков дозирования реагентов, замерных установок и другого нефтепромыслового оборудования. В число заказчиков продукции ОЗНА, помимо отечественных нефтяников, вошли предприятия стран Совета экономической взаимопомощи (СЭВ): Болгарии, Румынии, Югославии.
Трансформации 1990-х годов потребовали новых подходов к организации деятельности: 1990 год - создано арендное предприятие (АП) «ОЗАО и П»; 1991 год - внедрена блочная система управления производством; 1992 год - принято решение о приватизации путем акционирования; 1993 год - на базе АП «ОЗАО и П» образовано «Акционерное общество открытого типа «ОЗНА». 12 июля 1996 года создано ОАО «Акционерная компания ОЗНА».
Главной целью производственной (по профилю специальности) практики является закрепление и совершенствование приобретенных в процессе обучения профессиональных умений обучающихся по изучаемой специальности, развитие общих и профессиональных компетенций, освоение современных производственных процессов, адаптация обучающихся к конкретным условиям деятельности организация различных организационно-правовых форм.
В результате прохождения производственной (по профилю специальности) практики в рамках профессионального модуля обучающийся должен приобрести практический опыт работы:
с проектной и технической документацией на уровне взаимодействия компонент программного обеспечения;
выполнения интеграции модулей в программную среду;
выполнения отладки программного продукта с использованием специализированных программных средств;
разработки текстовых наборов и текстовых сценариев;
проведения инспектирования компонент программного продукта на предмет соответствия стандартам кодирования.
1. ТЕОРЕТИЧЕСКАЯ ЧАСТЬ
1.1 Жизненный цикл программного продукта
Жизненный цикл программного продукта - период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации.
Стандарт ГОСТ 34.601-90 предусматривает следующие стадии и этапы создания автоматизированной системы:
1. Формирование требований к автоматизированной системе
1.1. Обследование объекта и обоснование необходимости создания автоматизированной системы
1.2. Формирование требований пользователя к автоматизированной системе
.3. Оформление отчета о выполнении работ и заявки на разработку автоматизированной системы
2. Разработка концепции автоматизированной системы
2.1. Изучение объекта
2.2. Проведение необходимых научно-исследовательских работ
.3. Разработка вариантов концепции автоматизированной системы и выбор варианта концепции автоматизированной системы, удовлетворяющего требованиям пользователей
.4. Оформление отчета о проделанной работе
3. Техническое задание
3.1. Разработка и утверждение технического задания на создание автоматизированной системы
4. Эскизный проект
4.1. Разработка предварительных проектных решений по системе и её частям
4.2. Разработка документации на автоматизированную систему и её части
5. Технический проект
5.1. Разработка проектных решений по системе и её частям
5.2. Разработка документации на автоматизированную систему и её части
.3. Разработка и оформление документации на поставку комплектующих изделий
.4. Разработка заданий на проектирование в смежных частях проекта
6. Рабочая документация
6.1. Разработка рабочей документации на автоматизированную систему и её части
6.2. Разработка и адаптация программ
7. Ввод в действие
7.1. Подготовка объекта автоматизации
7.2. Подготовка персонала
.3. Комплектация автоматизированной системы поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями)
.4. Строительно-монтажные работы
.5. Пусконаладочные работы
.6. Проведение предварительных испытаний
.7. Проведение опытной эксплуатации
.8. Проведение приёмочных испытаний
8. Сопровождение автоматизированной системы
8.1. Выполнение работ в соответствии с гарантийными обязательствами
8.2. Послегарантийное обслуживание
Эскизный, технический проекты и рабочая документация - это последовательное построение все более точных проектных решений. Допускается исключать стадию «Эскизный проект» и отдельные этапы работ на всех стадиях
, объединять стадии «Технический проект» и «Рабочая документация» в «Технорабочий проект», параллельно выполнять различные этапы и работы, включать дополнительные.
1.2 Основные модели процесса разработки программного обеспечения
Модель кодирования и устранения ошибок.
Совершенно простая модель, характерная для студентов ВУЗов. Именно по этой модели большинство студентов разрабатывают лабораторные работы.
Данная модель имеет следующий алгоритм:
постановка задачи;
выполнение;
проверка результата;
при необходимости переход к первому пункту.
Модель ужасно устаревшая и характерна для 1960-1970 гг., поэтому преимуществ перед следующими моделями практически не имеет, а недостатки на лицо.
Каскадная модель жизненного цикла программного обеспечения представлена на рисунке 1.
Рисунок 1 Каскадная модель жизненного цикла программного обеспечения
Преимущества:
последовательное выполнение этапов проекта в строгом фиксированном порядке;
позволяет оценивать качество продукта на каждом этапе.
Недостатки:
отсутствие обратных связей между этапами;
не соответствует реальным условиям разработки программного продукта.
Каскадная модель с промежуточным контролем (водоворот).
Данная модель является почти эквивалентной по алгоритму предыдущей модели, однако при этом имеет обратные связи с каждым этапом жизненного цикла, при этом порождает очень весомый недостаток: 10-ти кратное увеличение затрат на разработку.модель (разработка через тестирование).
Данная модель имеет более приближенный к современным методам алгоритм, однако все еще имеет ряд недостатков. Является одной из основных практик экстремального программирования. Изображение представлено на рисунке 2.
Рисунок 2 V модель
Модель на основе разработки прототипа.
Прототипирование используется на ранних стадиях жизненного цикла программного обеспечения:
Прояснить не ясные требования;
Выбрать одно из ряда концептуальных решений;
Проанализировать осуществимость проекта.
Классификация протопипов:
Горизонтальные и вертикальные;
Одноразовые и эволюционные;
бумажные и раскадровки.
Горизонтальные прототипы - моделирует исключительно UI не затрагивая логику обработки и базу данных.
Вертикальные прототипы - проверка архитектурных решений.
Одноразовые прототипы - для быстрой разработки.
Эволюционные прототипы - первое приближение эволюционной системы.
Спиральная модель жизненного цикла программного обеспечения.
Спиральная модель представляет собой процесс разработки программного обеспечения, сочетающий в себе как проектирование, так и постадийное прототипирование с целью сочетания преимуществ восходящей и нисходящей концепции.
Преимущества:
Быстрое получение результата
Повышение конкурентоспособности
Изменяющиеся требования - не проблема
Недостатки:
Отсутствие регламентации стадий
Изображение модели представлено на рисунке 3.
.
Рисунок 3 Спиральная модель жизненного цикла
1.3 Организация процесса разработки программного обеспечения
Maturity Model - модель зрелости возможностей (модель полноты потенциала) создания программного обеспечения: эволюционная модель развития способности компании разрабатывать программное обеспечение.
В ноябре 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).