Файл: Отчет по производственной практике пм. 03. Участие в интеграции программных модулей.docx
Добавлен: 07.11.2023
Просмотров: 391
Скачиваний: 11
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
АВТОНОМНАЯ НЕКОММЕРЧЕСКАЯ ОРГАНИЗАЦИЯПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯОКТЯБРЬСКИЙ ЭКОНОМИЧЕСКИЙ ТЕХНИКУМОТЧЕТпо производственной практикеПМ.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. Послегарантийное обслуживаниеЭскизный, технический проекты и рабочая документация - это последовательное построение все более точных проектных решений. Допускается исключать стадию «Эскизный проект» и отдельные этапы работ на всех стадиях
Вертикальные прототипы - проверка архитектурных решений.Одноразовые прототипы - для быстрой разработки.Эволюционные прототипы - первое приближение эволюционной системы.Спиральная модель жизненного цикла программного обеспечения.Спиральная модель представляет собой процесс разработки программного обеспечения, сочетающий в себе как проектирование, так и постадийное прототипирование с целью сочетания преимуществ восходящей и нисходящей концепции.Преимущества:Быстрое получение результатаПовышение конкурентоспособностиИзменяющиеся требования - не проблемаНедостатки:Отсутствие регламентации стадийИзображение модели представлено на рисунке 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).
В январе 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).