Добавлен: 29.10.2023
Просмотров: 61
Скачиваний: 2
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
СОДЕРЖАНИЕ
ВВЕДЕНИЕ
1. ТЕОРЕТИЧЕСКАЯ ЧАСТЬ
1.1 Жизненный цикл программного продукта
1.2 Основные модели процесса разработки программного обеспечения
1.3 Организация процесса разработки программного обеспечения
1.4 Проектирование и разработка программного обеспечения
1.5 Интеграция системы
1.6 Среды разработки приложений
1.7 Язык SQL
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 Сертификация
2.4.1 Подготовка перечня документации для прохождения сертификации
2.4.2 Проверка соответствия требованиям
2.4.3 Подготовка к сертификационным испытаниям и их проведение
2.4.4 Приемка и эксплуатация программного обеспечения
2.4.5 Разработка пользовательской документации
2.4.6 Определение состава документации
2.4.7 Подготовка руководства пользователя
ЗАКЛЮЧЕНИЕ
СПИСОК ЛИТЕРАТУРЫ
ПРИЛОЖЕНИЕ
ВВЕДЕНИЕ
Главной целью производственной (по профилю специальности) практики является закрепление и совершенствование приобретенных в процессе обучения профессиональных умений обучающихся по изучаемой специальности, развитие общих и профессиональных компетенций
, освоение современных производственных процессов, адаптация обучающихся к конкретным условиям деятельности организация различных организационно-правовых форм.
В результате прохождения производственной (по профилю специальности) практики в рамках профессионального модуля обучающийся должен приобрести практический опыт работы:
− с проектной и технической документацией на уровне взаимодействия компонент программного обеспечения;
− выполнения интеграции модулей в программную среду;
− выполнения отладки программного продукта с использованием специализированных программных средств;
− разработки текстовых наборов и текстовых сценариев;
− проведения инспектирования компонент программного продукта на предмет соответствия стандартам кодирования.
1. ТЕОРЕТИЧЕСКАЯ ЧАСТЬ
1.1 Жизненный цикл программного продукта
Жизненный цикл программного продукта - период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации.
Эскизный, технический проекты и рабочая документация - это последовательное построение все более точных проектных решений. Допускается исключать стадию «Эскизный проект» и отдельные этапы работ на всех стадиях, объединять стадии «Технический проект» и «Рабочая документация» в «Технорабочий проект», параллельно выполнять различные этапы и работы, включать дополнительные.
1.2 Основные модели процесса разработки программного обеспечения
Модель кодирования и устранения ошибок.
Совершенно простая модель, характерная для студентов ВУЗов. Именно по этой модели большинство студентов разрабатывают лабораторные работы.
Данная модель имеет следующий алгоритм:
− постановка задачи;
− выполнение;
− проверка результата;
− при необходимости переход к первому пункту.
Модель ужасно устаревшая и характерна для 1960-1970 гг., поэтому преимуществ перед следующими моделями практически не имеет, а недостатки на лицо.
Каскадная модель жизненного цикла программного обеспечения
Преимущества:
− последовательное выполнение этапов проекта в строгом фиксированном порядке;
− позволяет оценивать качество продукта на каждом этапе.
Недостатки:
− отсутствие обратных связей между этапами;
− не соответствует реальным условиям разработки программного продукта.
Каскадная модель с промежуточным контролем (водоворот).
Данная модель является почти эквивалентной по алгоритму предыдущей модели, однако при этом имеет обратные связи с каждым этапом жизненного цикла, при этом порождает очень весомый недостаток: 10-ти кратное увеличение затрат на разработку.модель (разработка через тестирование).
Данная модель имеет более приближенный к современным методам алгоритм, однако все еще имеет ряд недостатков. Является одной из основных практик экстремального программирования.
Модель на основе разработки прототипа.
Прототипирование используется на ранних стадиях жизненного цикла программного обеспечения:
− Прояснить не ясные требования;
− Выбрать одно из ряда концептуальных решений;
− Проанализировать осуществимость проекта.
Классификация протопипов:
− Горизонтальные и вертикальные;
− Одноразовые и эволюционные;
− бумажные и раскадровки.
Горизонтальные прототипы - моделирует исключительно UI не затрагивая логику обработки и базу данных.
Вертикальные прототипы - проверка архитектурных решений.
Одноразовые прототипы - для быстрой разработки.
Эволюционные прототипы - первое приближение эволюционной системы.
Спиральная модель жизненного цикла программного обеспечения.
Спиральная модель представляет собой процесс разработки программного обеспечения, сочетающий в себе как проектирование, так и постадийное прототипирование с целью сочетания преимуществ восходящей и нисходящей концепции.
Преимущества:
Быстрое получение результата
Повышение конкурентоспособности
Изменяющиеся требования - не проблема
Недостатки:
Отсутствие регламентации стадий
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).
1.4 Проектирование и разработка программного обеспечения
Проектирование программного обеспечения - процесс создания проекта программного обеспечения, а также дисциплина, изучающая методы проектирования. Проектирование программного обеспечения является частным случаем проектирования продуктов и процессов.
Целью проектирования является определение внутренних свойств системы и детализации её внешних (видимых) свойств на основе выданных заказчиком требований к программному обеспечению (исходные условия задачи). Эти требования подвергаются анализу.
Первоначально программа рассматривается как чёрный ящик. Ход процесса проектирования и его результаты зависят не только от состава требований, но и выбранной модели процесса, опыта проектировщика.
Модель предметной области накладывает ограничения на бизнес-логику и структуры данных.
В зависимости от класса создаваемого программного обеспечения, процесс проектирования может обеспечиваться как «ручным» проектированием, так и различными средствами его автоматизации. В процессе проектирования программного обеспечения для выражения его характеристик используются различные нотации - блок-схемы, ER-диаграммы, UML-диаграммы, DFD-диаграммы, а также макеты.
Проектированию обычно подлежат:
− Архитектура программного обеспечения;
− Устройство компонентов программного обеспечения;
− Пользовательские интерфейсы.
В российской практике проектирование ведется поэтапно в соответствии со стадиями, регламентированными ГОСТ 2.103-68:
− техническое задание(по ГОСТ 2.103-68 к стадиям разработки не относится);
− техническое предложение;
− эскизный проект;
− технический проект;
− рабочий проект.
На каждом из этапов формируется свой комплект документов, называемый проектом (проектной документацией).
В зарубежной практике регламентирующими документами, например, являются Software Architecture Document, Software Design Document.
Разработка программного обеспечения (англ. software development) - деятельность по созданию нового программного обеспечения.
Разработка программного обеспечения как инженерная дисциплина является составной частью (областью) программной инженерии, наряду с дисциплинами, отвечающими за функционирование и сопровождение программных продуктов.
1.5 Интеграция системы
Интеграция информационных систем - это процесс установки связей между информационными системами предприятий и организаций для получения единого информационного пространства и организации поддержки сквозных бизнес-процессов предприятий и организаций.
Задача интеграции информационных и учетных систем состоит из двух взаимосвязанных частей: интеграция приложений и интеграция данных. Без интеграции данных невозможно провести интеграцию приложений.
Интеграция данных - процесс компоновки информации из различных информационных систем предприятий и организаций, установки ее однозначного соответствия в разных системах, синхронизация одинаковых информационных объектов в различных информационных систем.
Решая задачу интеграции данных, компания должна провести унификацию и стандартизацию нормативно-справочной информации. Нормативно-справочная информация - условно-постоянная составляющая общей корпоративной информации. Эта информация используется при регламентации деятельности компании, она обеспечивает «сшивку» данных, сопровождающих бизнес-процессы компании. Другими словами, нормативно-справочная информация - это набор справочников, словарей, классификаторов, стандартов, регламентов, используемых в деятельности компании. Нормативно-справочная информация является ядром информационного пространства компании. Наличие однозначной, структурированной, стандартизированной Нормативно-справочной информации, управление которой ведется в соответствии с продуманными правилами и алгоритмами, - базис, обязательное условие создания эффективных интеграционных решений.