Добавлен: 29.10.2023
Просмотров: 264
Скачиваний: 2
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
СОДЕРЖАНИЕВВЕДЕНИЕ1. ТЕОРЕТИЧЕСКАЯ ЧАСТЬ1.1 Жизненный цикл программного продукта1.2 Основные модели процесса разработки программного обеспечения1.3 Организация процесса разработки программного обеспечения1.4 Проектирование и разработка программного обеспечения1.5 Интеграция системы1.6 Среды разработки приложений1.7 Язык SQL1.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 Подготовка руководства пользователяЗАКЛЮЧЕНИЕСПИСОК ЛИТЕРАТУРЫПРИЛОЖЕНИЕ ВВЕДЕНИЕГлавной целью производственной (по профилю специальности) практики является закрепление и совершенствование приобретенных в процессе обучения профессиональных умений обучающихся по изучаемой специальности, развитие общих и профессиональных компетенций
− не соответствует реальным условиям разработки программного продукта.Каскадная модель с промежуточным контролем (водоворот).Данная модель является почти эквивалентной по алгоритму предыдущей модели, однако при этом имеет обратные связи с каждым этапом жизненного цикла, при этом порождает очень весомый недостаток: 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 Интеграция системыИнтеграция информационных систем - это процесс установки связей между информационными системами предприятий и организаций для получения единого информационного пространства и организации поддержки сквозных бизнес-процессов предприятий и организаций.Задача интеграции информационных и учетных систем состоит из двух взаимосвязанных частей: интеграция приложений и интеграция данных. Без интеграции данных невозможно провести интеграцию приложений.Интеграция данных - процесс компоновки информации из различных информационных систем предприятий и организаций, установки ее однозначного соответствия в разных системах, синхронизация одинаковых информационных объектов в различных информационных систем.Решая задачу интеграции данных, компания должна провести унификацию и стандартизацию нормативно-справочной информации. Нормативно-справочная информация - условно-постоянная составляющая общей корпоративной информации. Эта информация используется при регламентации деятельности компании, она обеспечивает «сшивку» данных, сопровождающих бизнес-процессы компании. Другими словами, нормативно-справочная информация - это набор справочников, словарей, классификаторов, стандартов, регламентов, используемых в деятельности компании. Нормативно-справочная информация является ядром информационного пространства компании. Наличие однозначной, структурированной, стандартизированной Нормативно-справочной информации, управление которой ведется в соответствии с продуманными правилами и алгоритмами, - базис, обязательное условие создания эффективных интеграционных решений.
, освоение современных производственных процессов, адаптация обучающихся к конкретным условиям деятельности организация различных организационно-правовых форм.
В результате прохождения производственной (по профилю специальности) практики в рамках профессионального модуля обучающийся должен приобрести практический опыт работы:
− с проектной и технической документацией на уровне взаимодействия компонент программного обеспечения;
− выполнения интеграции модулей в программную среду;
− выполнения отладки программного продукта с использованием специализированных программных средств;
− разработки текстовых наборов и текстовых сценариев;
− проведения инспектирования компонент программного продукта на предмет соответствия стандартам кодирования.
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 Интеграция системыИнтеграция информационных систем - это процесс установки связей между информационными системами предприятий и организаций для получения единого информационного пространства и организации поддержки сквозных бизнес-процессов предприятий и организаций.Задача интеграции информационных и учетных систем состоит из двух взаимосвязанных частей: интеграция приложений и интеграция данных. Без интеграции данных невозможно провести интеграцию приложений.Интеграция данных - процесс компоновки информации из различных информационных систем предприятий и организаций, установки ее однозначного соответствия в разных системах, синхронизация одинаковых информационных объектов в различных информационных систем.Решая задачу интеграции данных, компания должна провести унификацию и стандартизацию нормативно-справочной информации. Нормативно-справочная информация - условно-постоянная составляющая общей корпоративной информации. Эта информация используется при регламентации деятельности компании, она обеспечивает «сшивку» данных, сопровождающих бизнес-процессы компании. Другими словами, нормативно-справочная информация - это набор справочников, словарей, классификаторов, стандартов, регламентов, используемых в деятельности компании. Нормативно-справочная информация является ядром информационного пространства компании. Наличие однозначной, структурированной, стандартизированной Нормативно-справочной информации, управление которой ведется в соответствии с продуманными правилами и алгоритмами, - базис, обязательное условие создания эффективных интеграционных решений.