Министерство образования, науки и молодежи Республики Крым

Государственное бюджетное профессиональное образовательное учреждение

Республики Крым

«Феодосийский политехнический техникум»

Рег. № ___________ Утверждаю

Зам. директор по учебной работе

О.Г. Сердюкова

«___» ______________ 2015г.

РАБОЧАЯ ПРОГРАММа ПРОФЕССИОНАЛЬНОГО МОДУЛЯ

для специальности среднего профессионального образования

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

Рабочая программа профессионального модуля разработана на основе Федерального государственного образовательного стандарта среднего профессионального образования по специальности 09.02.03 Программирование в компьютерных системах

Организация-разработчик: Государственное бюджетное профессиональное образовательное учреждение Республики Крым «Феодосийский политехнический техникум»

Разработчик:

Джелялова Севиля Наримановна, преподаватель дисциплин профессионального цикла

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

Протокол № 1 от « 28 » августа 2015 года

Председатель цикловой комиссии ____________ Т.Н. Дворянова

Программа согласована ________________ Ю.С. Матвиенко

1. ПАСПОРТ рабочей ПРОГРАММЫ ПРОФЕССИОНАЛЬНОГО МОДУЛЯ

5. Контроль и оценка результатов освоения профессионального модуля (вида профессиональной деятельности )

1. ПАСПОРТ РАБОЧЕЙ ПРОГРАММЫ ПРОФЕССИОНАЛЬНОГО МОДУЛЯ

ПМ.03 УЧАСТИЕ В ИНТЕГРАЦИИ ПРОГРАММНЫХ МОДУЛЕЙ

1.1. Область применения программы

Рабочая программа профессионального модуля (далее программа ПМ) – является частью основной профессиональной образовательной программы в соответствии с ФГОС СПО 09.02.03 Программирование в компьютерных системах, укрупненная группа профессий, специальностей и направлений подготовки (УГС) 09.00.00 Информатика и вычислительная техника в части освоения основного вида профессиональной деятельности (ВПД): Участие в интеграции программных модулей и соответствующих профессиональных компетенций (ПК):

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

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

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

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

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

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

1.2. Цели и задачи модуля – требования к результатам освоения модуля

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

иметь практический опыт:

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

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

уметь:

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

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

знать:

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

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

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

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

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

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

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

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

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

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

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

всего – 474 час., в том числе:

максимальной учебной нагрузки обучающегося – 330 час., включая:

аудиторной учебной работы обучающегося – (обязательных учебных занятий) 220 час.;

внеаудиторной (самостоятельной) учебной работы обучающегося – 110 час.;

учебной и производственной практики – 144 час.

1.4. Распределение часов вариативной части ОПОП

ПК 3.7. Осуществлять работу над проектом в команде

Знать:

принципы управления проектами;

основные фазы процесса разработки ПО

методику оценивания трудозатрат и рисков

Уметь:

распределять роли в проектной команде;

проводить декомпозицию проекта на задачи,

составлять план проекта,

составлять отчетную документацию

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

Тема 2.3. Адаптация программных продуктов

Тема 4.1. Документирование

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

2. результаты освоения ПРОФЕССИОНАЛЬНОГО МОДУЛЯ

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

Код

Наименование результата обучения

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

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

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

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

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

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

Осуществлять командную разработку программного продукта

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

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

Принимать решения в стандартных и нестандартных ситуациях и нести за них ответственность

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

Использовать информационно-коммуникационные технологии в профессиональной деятельности

Работать в коллективе и в команде, эффективно общаться с коллегами, руководством, потребителями

Брать на себя ответственность за работу членов команды (подчиненных), за результат выполнения заданий

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

Ориентироваться в условиях частой смены технологий в профессиональной деятельности

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

3. СТРУКТУРА и содержание профессионального модуля

3.1. Тематический план профессионального модуля

Коды профессиональных компетенций

Наименования разделов профессионального модуля

Всего часов

Объем времени, отведенный на освоение междисциплинарного курса (курсов)

Практика

Аудиторная учебная работа обучающегося (обязательные учебные занятия)

Внеаудиторная (самостоятельная) учебная работа обучающегося,

Учебная,

часов

Производственная (по профилю специальности),

часов

Всего,

часов

в т.ч. лабораторные работы и практические занятия,

часов

часов

Всего,

часов

в т.ч., курсовая работа (проект),

часов

1

2

3

4

5

6

7

8

9

10

ПК 3.1

ПК 3.7

Раздел 1. Проектирование программного обеспечения

ПК 3.2

ПК 3.3

ПК 3.4

ПК 3.7

Раздел 2. Тестирование и отладка программного обеспечения

ПК 3.5

Раздел 3. Обеспечение качества программных продуктов

ПК 3.6

ПК 3.7

Раздел 4. Разработка технологической документации

4 4

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

7 2

7 2

Всего:

Наименование разделов профессионального модуля (ПМ), междисциплинарных курсов (МДК) и тем

Объем часов

Уровень освоения

1

2

3

4

Раздел 1. Проектирование программного обеспечения

333

МДК 03.01

66

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

Программная инженерия. Классификация процессов.

Жизненный цикл программных средств

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

Практические занятия

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

Выбор и адаптация модели жизненного цикла для конкретного проекта

Тема 1.2 Руководство программным проектом

Основные понятия руководством проекта. Этапы руководства.

Планирование программного продукта

Управление рисками

Оценка программного проекта

Тема 1.3 Формирование и анализ требований

Формирование и анализ требований. Спецификация требований.

Лабораторные занятия

Сбор и анализ требований

Тема 1.4 Методологии разработки программных средств

Структурное проектирование. Модульное проектирование

Методы нисходящего и восходящего проектирования.

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

Лабораторные и практические занятия

Шаблоны структурного проектирования

Создание и оценка пилотного проекта

МДК 03.02 Инструментальные средства разработки программного обеспечения

80

Тема 1.5 CASE-технологии структурного анализа и проектирования программных средств

Case-средства для моделирования деловых процессов.

Принципы построения модели IDEF0. Диаграммы IDEF0

Диаграммы потоков данных (Data Flow Diagramming)

Лабораторные и практические занятия

IDEF 0

IDEF 0

Разработка и создание контекстной диаграммы DFD

Разработка и создание декомпозиций диаграмм DFD

Тема 1.6 Методология объектно-ориентированного анализа и проектирования

UML- моделирование.

Диаграммы вариантов, классов, взаимодействия

Диаграммы состояний, компонентов, размещений

Взаимосвязи между диаграммами. Специальные диаграммы.

Лабораторные и практические занятия

Разработка и создание диаграммы вариантов

Разработка и создание диаграммы классов

Разработка и создание диаграммы взаимодействия

Разработка и создание диаграммы состояний

Разработка и создание диаграммы компонентов

Разработка и создание диаграммы размещений

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

Эволюционная модель прототипирования

Графическое представление структурированных схем алгоритмов

Метод JSP Джексона

Архитектурное проектирование

Метрики объектно-ориентированных программных систем

Этапы развития проектирования и CASE -средств

Проведение предпроектного обследования организации.

Изучение принципов работы с CASE -системами

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

Система моделирования Ramus

Средство UML моделирования ArgoUML

Учебная практика

Виды работ

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

Разработка технического задания

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

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

Проектирование ПО для решения прикладных задач организации

Раздел 2 Тестирование и отладка программного обеспечения

73

МДК 03.01 Технология разработки программного обеспечения

42

Тема 2.1 Тестирование программных продуктов

Понятие тестирования. Принципы тестирования.

Виды тестирования программных продуктов. Методы тестирования программных продуктов

Структурное тестирование. Понятие и принципы структурного тестирования.

Функциональное тестирование. Понятие и принципы функционального тестирования.

Оценочное тестирование. Виды оценочного тестирования. Принципы проведения оценочного тестирования

Критерии построения тестовых наборов и отладочных заданий.

Принцип построения тестового набора данных и составления отладочных заданий.

Организация процесса тестирования

Лабораторные и практические занятия

Определение количества ошибок в программном продукте и числа необходимых тестов

Тестирование программного продукта методом «белого ящика»

Тестирование программного продукта методом «чёрного ящика»

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

Тема 2.2 Отладка программных продуктов

Понятие отладки программных продуктов. Принципы отладки программных продуктов.

Классификация ошибок.

Точка нахождения и точка проявления ошибки.

Локализация ошибок

Методы отладки программного обеспечения.

Метод ручного тестирования.

Метод индукции. Метод дедукции.

Метод обратного прослеживания

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

Лабораторные и практические занятия

Ручная отладка программного обеспечения

Отладка программного обеспечения с помощью инструментальных средств

Тема 2.3 Адаптация программных продуктов

Понятие адаптации программных продуктов.

Определение требований программного обеспечения к среде функционирования.

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

Проведение интеграции программных комплексов в систему.

Проведение приёмо-сдаточных испытаний по результатам интеграции

Обеспечение качества программных систем

Практические занятия

Составление плана обеспечение качества ПО

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

Самостоятельная работа при изучении раздела

Объектно-ориентированное тестирование

Выполнение адаптации программного продукта к среде функционирования

Сравнительный анализ инструментальных средств отладки программных продуктов

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

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

Виды работ

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

Раздел 3. Обеспечение качества программных продуктов

24

МДК 03.03 Документирование и сертификация

1 4

Тема 3.1. Основы стандартизации

Принципы и методы стандартизации.

Международная стандартизация

Система стандартизации в РФ

Стандарты кодирования.

Тема 3.2. Основы сертификации

Процесс сертификации

Система сертификации

Обеспечение качества через стандартизацию и сертификацию

Лабораторные и практические занятия

Ознакомление с сертификатами на ПО.

Тема 3.3. Основы метрологии

Принципы и методы метрологии

Общие сведения об измерениях

Интегральные метрики оценки программного продукта

Измерительные методы анализа программного обеспечения

Тема 3.4. Качество программного продукта

Стандарты в области программного обеспечения (документация, программирование, интерфейсы)

Показатели и характеристики качества программного продукта

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

Аттестация программного продукта

Верификация программного продукта

Самостоятельная работа при изучении раздела

Задачи международного сотрудничества в области стандартизации.

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

Сущность и организация инспектирования программного продукта.

Обеспечение качества программных средств.

Стандартизация качества программного обеспечения.

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

1 0

Раздел 4. Разработка технологической документации

44

МДК 03.03 Документирование и сертификация

18

Тема 4.1. Документирование

Виды программных документов.

Документация и ее роль в обеспечении качества.

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

Состав Единой системы программной документации.

Лабораторные и практические занятия

Тема 4.2. Документация продукции

Учебные руководства

Справочные руководства и руководства пользователя

Руководства по сопровождению ПО

Лабораторные и практические занятия

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

Разработка руководства программиста

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

Самостоятельная работа при изучении раздела

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

Разработка технологического задания.

Разработка пояснительной записки и спецификации.

Состав документации технического проекта.

Брошюры и информационные листки, посвященные продукции

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

Виды работ

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

Всего

474

4. условия реализации программы ПРОФЕССИОНАЛЬНОГО МОДУЛЯ

4.1. Материально-техническое обеспечение

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

Оборудование учебного кабинета: места по количеству обучающихся; рабочее место преподавателя; комплект лекций-презентаций.

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

Оборудование лаборатории и рабочих мест лаборатории: методические указания для проведения лабораторных и практических занятий; рабочие станции с установленным специализированным программным обеспечением, доступ в Интернет.

4.2. Информационное обеспечение обучения

Основные источники:

Иванов Д., Новиков Ф. Моделирование на UML: Учебно-методическое пособие./Д. Иванов, Ф. Новиков - СПб.: СПбГУ ИТМО, 2010. - 200 с.

Колчков В.И.. Метрология, стандартизация и сертификация: Учебник. Для СПО / В.И. Колчков. – М.: ВЛАДОС, 2010. – 398 с.

Орлов С. А., Цилькер Б. Я. Технологии разработки программного обеспечения: Учебник для вузов. 4..е изд. Стандарт третьего поколения. СПб.: Питер, 2012. 608 С.: ил.

Дополнительные источники:

Бахтизин, В. В. Технология разработки программного обеспечения: учеб. пособие / В. В. Бахтизин, Л. А. Глухова. – Минск: БГУИР, 2010. – 267 с. : ил.

Дубовой Н.Д. Основы метрологии, стандартизации и сертификации: Учеб. пособие для СПО / Н.Д.Дубовой, Е.М. Портнов. – М.: ФОРУМ, 2012. – 256 с. (Профессиональное образование).

Канер С., Фолк Д., Кек Нгуен Е. Тестирование программного обеспечения: Пер. с англ./С. Канер [и др.]-Киев: ДиаСофт, 2000. – 544 с.

Мазур И.И. Управление качеством: Учеб. Пособие / И.И. Мазур, В.Д. Шапиро. Под. ред. И.И. Мазура. – М.: Высш. шк., 2003 – 334 с.

Рудаков А.В. Технология разработки программных продуктов: Практикум: учеб. пособие для студ. учреждений сред. проф. Образования / А.В. Рудаков, Г.Н. Федорова. – 4-е изд., стер. - М. : Издательский центр «Академия», 2014. – 192 с.

Управление качеством: Учебник для вузов / С.Д. Ильенкова, Н.Д. Ильенкова, В.С. Мунтарян и др.; Под. ред. С.Д. Ильенковой. – 2-е изд., перераб. и доп. – М.: ЮНИТ – ДАНА, 2003. – 334 с.

Фишман Л.И., Рогожкина Н.В., Чупина В.Н. Сам себе эксперт: Самодиагностика качества управленческой деятельности. / Л.И. Фишман [и др.]– Самара: РЦМО, 2002. – 68 с.

Хрусталева З.А.. Метрология, стандартизация и сертификация: Практикум: Учеб. пособие для СПО / З.А. Хрусталева. – М.: КноРус, 2011. – 276 с.

Интернет-источники

1. Тестирование программного обеспечения. Основные понятия и определения [Электронный ресурс]: - http://www.protesting.ru/testing/ (28 августа 2014)

   Основы программной инженерии [Электронный ресурс]: -http://swebok.sorlik.ru/4_software_testing.html (28 августа 2014)

4.3. Организация образовательного процесса

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

Образовательный процесс организуется строго по расписанию занятий, утвержденному заместителем директора по УР. График освоения ПМ предполагает параллельное освоение МДК 03.01 Технология разработки программного обеспечения, МДК 03.02 Инструментальные средства разработки программного обеспечения, МДК 03.03 Документирование и сертификация, включающих в себя как теоретические, так и лабораторно-практические занятия.

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

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

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

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

4.4. Кадровое обеспечение образовательного процесса

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

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

5. Контроль и оценка результатов освоения профессионального модуля (вида профессиональной деятельности)

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

зачтенные лабораторно-практические работы;

устные фронтальные опросы;

тестирование;

контрольные работы;

семинарские занятия;

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

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

Итоговой формой контроля является квалификационный экзамен.

Результаты

(освоенные профессиональные компетенции)

Основные показатели оценки результата

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

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

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

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

изложение основ верификации и аттестации программного обеспечения

правильность разработки требований к программному обеспечению

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

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

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

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

создание программного продукта по разработанному алгоритму

получение кода с заданной функциональностью и степенью качества

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

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

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

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

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

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

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

разработанный набор тестовых значений соответствует требованиям

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

решение об окончании тестирования принимается на основе анализа

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

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

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

правильность применения стандартов качества программного обеспечения

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

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

качество использования методов и средств при разработке программной документации в соответствии с ГОСТ

перечень необходимой документации определён согласно техническому заданию

документация соответствует разработанному ПО

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

ПК 3.7. Осуществлять работу над проектом в команде

составление и оформление плана-графика работ над проектом

распределение обязанностей между сотрудниками

выполнение общего руководства над проектом

оформление документации по промежуточным работам

оформление документации приема-передачи проекта

УП.03. Учебная практика

«Программирование в 1С 8.3»

Модуль 1 Основные объекты платформы «1С:Предприятие 8»

Занятие 1. Начало работы с платформой «1С:Предприятие 8»

• Установка платформы «1С:Предприятие 8. Учебная версия» - бесплатным и легальным способом. Установка учебной версии «1С:Бухгалтерии 8».
• Создание новой информационной базы.
• Базовые понятия: платформа, конфигурация, информационная база.
• Типы пользовательских интерфейсов на платформе «1С:Предприятие 8».
• Работа с интерфейсом обычных форм, который использовался на платформах «1С:Предприятие 8.0» и «1С:Предприятие 8.1».
• Интерфейс управляемых форм, который широко применялся на платформе «1С:Предприятие 8.2».
• Изучение интерфейса «Такси», который появился в последней версии платформы «1С:Предприятие 8.3».

Занятие 2 «Объекты справочной информации».

• Создание собственной конфигурации и информационной базы на платформе «1С:Предприятие 8.3».
• Функционал платформы на базовом уровне.
• Разработка конфигурации для предприятия оптовой торговли.
• Объекты конфигурации, хранящие справочную информацию (списки элементов). Продемонстрируем, как в разработанной конфигурации пользователь может создавать любое количество складов предприятия, произвольную номенклатуру (товары), а также вводить данные о поставщиках и покупателях.
• Принципы работы с иерархическими справочниками.
• Определение произвольного состава реквизитов для справочников. Таким образом, пользователь прикладного решения получит возможность вводить произвольное описание для товаров (где будут расшифровываться все свойства товара), а также указывать основных поставщиков для каждой номенклатуры.
• Создание объекта конфигурации «Перечисление», для классификации товаров по типам, указанным им в конфигурации.
• Объект конфигурации «Константа» - здесь будет храниться информация о названии нашей организации.

Занятие 3 «Документооборот торгового предприятия».

• Классическая схема документооборота предприятия оптовой торговли.
• Для закупки: заказ поставщику - поступление товаров по заказу - оплата поставщику.
• Для продажи: заказ клиента - отгрузка (продажа) товаров клиенту - прием оплаты от покупателя.
• Базовые термины, с которыми работают финансисты и руководители торговых предприятий: выручка, себестоимость, прибыль и рентабельность. На наглядных схемах и примерах покажем, как рассчитываются данные показатели.
• Создание первого документа «Заказ клиента», с помощью него пользователи смогут регистрировать желание клиента приобрести определенный товар по указанной цене.
• Создание документов по товарообороту: поступление товаров на склад компании и отгрузка (продажа) товаров клиенту.
• Объединение документов в общий журнал документов.
• Пример создания печатной формы для документа - таким образом, пользователи смогут на принтере распечатывать документы, ставить подписи, печати и передавать их клиентам.

Занятие 4 «Регистры накопления. Проведение документов» .

· Предназначение класса конфигурации - «Регистр».

· Регистры накопления.

· С помощью регистра накопления решение задачи учета данных о долгах перед поставщиками и долгах клиентов.

· Проведение документов.

· Разработка программного кода, который будет выполнять проведение документов «Поступление товаров» и «Реализация товаров».

· Создание документа «Выписка банка», с помощью которого будет регистрироваться поступление денежных средств от клиентов и оплата поставщикам.

Занятие 5 «Виды регистров накопления, регистры сведений. Интерфейс приложения».

· Виды регистров накопления - остатки и обороты.

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

· Принципы работы регистра сведений.

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

· Обеспечение учета цен на товары с помощью регистров сведений, при этом цена привязана к дате, т.е. со временем цены на товары могут изменяться.

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

· Объект конфигурации - «Подсистема».

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

Модуль 2. Программирование на платформе «1С:Предприятие 8»

Занятие 6 Первая программа на платформе «1С:Предприятие 8».

· Разбор аспектов программирования на платформе «1С:Предприятие 8», знакомство со встроенным языком, рассмотрение основных операторов программного кода.

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

· Рассмотрение понятие программного модуля, написание первой классической программы «Hello, world».

· Комментарии частей алгоритмов в программном коде.

· Разбор понятия переменные и как работает оператор присваивания.

· Операторы системы - условные и циклические.

· Циклы: по условию и по счетчику. Примеры их использования в программном коде.

Занятие 7. Программирование на встроенном языке «1С:Предприятие 8»

· Понятие типа данных, работа с основными примитивными типами данных системы.

· Встроенные функции платформы по работе с типами данных - число, строка, дата и булево.

· Логические операции - И, ИЛИ, НЕ.

· Сервисное средство программиста 1С - синтакс-помощник.

· Типовая структуру программного модуля.

Занятие 8 «События, процедуры и функции» .

· Понятие процедуры, их предназначение и возможности использования.

· Упрощение структуру написанного ранее программного кода с помощью процедур.

· Пример использования функций, передача параметров в функцию.

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

· События модуля управляемого приложения. С помощью них можно выполнять произвольные действия при старте и завершении работы приложения.

· События: «Перед записью», «Обработка проверки заполнения» и «Обработка проведения» для документа.

· Цикл по универсальным коллекциям - «Для каждого…»., с помощью этого цикла обход всех строк табличной части документа.

Занятие 9 «Типы данных. События элементов форм» .

· Помощник программиста 1С - отладчик и работа с ним. Основные этапы отладки: точка остановки, пошаговое выполнение команд, просмотр значений переменных и вычисление выражений.

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

· Типы данных, использующиеся для программной работы с регистрами, - регистр накопления «Набор записей» и регистр накопления «Запись».

· Процесс проведения документов.

· Понятие объекта и класса (типа данных) - эти понятия повсеместно используются при разработке в 1С.

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

Модуль 3. Получение информации из базы данных. Алгоритмы проведения документов

Занятие 10. «Чтение информации из базы данных, создание отчетов ».

· Получение информации из базы данных, для этого используются запросы.

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

· Разработка запросов к справочникам, документам и их табличным частям.

· Построение первых отчетов с помощью мощнейшего механизма - «Системы компоновки данных» (СКД).

· Создание с помощью СКД гибких отчетов, которые пользователь сможет настраивать и изменять в процессе работы с ними.

· Передача параметров в запросы и устанавливать их значения в пользовательском режиме.

· Настройка вариантов отчетов - выбирать выходные поля и настраивать группировку. С учетом того, что некоторые справочники являются иерархическими, выведем группы справочника в отчет.

Занятие 11. Получение данных из регистров

· Работа с запросами, - чтение данные из регистров накопления.

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

· С помощью виртуальной таблицы «Остатки» построение отчета по взаиморасчетами между нашей компанией и поставщиками, покупателями.

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

· Работа с виртуальной таблицей регистров «Обороты» на примере построения отчета по продажам.

· Работа с вложенными запросами (подзапросы). Построение отчета по продажам, который будет использовать подзапросы.

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

Занятие 12 . «Контроль остатков и расчет себестоимости» .

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

· Решение двух важнейших задач для торгового предприятия: контроль остатков товаров при продаже и обеспечение расчета себестоимости.

· Контроль остатков, для того, чтобы не уйти «в минус», то есть продать не существующий товар.

· Одновременная продажа. Представим, что 2 менеджера по продажам одновременно вводят для разных клиентов документы продажи. Может случиться так, что столов на складе 100 шт., а каждый из клиентов запросил по 60 шт. В итоге система должна сообщить, что для одного из клиентов товаров не хватает.

· Человеческий фактор. Все могут ошибаться, пользователь может случайно выбрать не тот товар (который уже давно отсутствует на складе), и система должна его об этом предупредить.

· Таким образом, если не делать контроля остатков, недовольства клиентов не избежать.

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

Занятие 12 . «Валовая прибыль. Создание сложных отчетов» .

· Вычисление валовой прибыли и сохранение ее в регистрах на основании рассчитанной ранее себестоимости.

· Построение отчета «Валовая прибыль», который покажет информации о выручке, валовой прибыли и рентабельности за выбранный пользователем период, отчет будет выводить данные в разрезе клиентов и номенклатуры.

· Создание отчетов, содержащих несколько вариантов представления данных: в одном отчете получение данных о продажах товаров, отдельно данные о продажах по клиентам и сводную таблицу «Продажи товаров по клиентам».

· Построение диаграммы в отчетах: гистограммы и круговые диаграммы, получение информации о продажах для наглядного вида. Построение графика продаж.

Модуль 4. Бухгалтерский учет.

Занятие 14 . Основы бухгалтерского учета

· Основные термины бухгалтерского учета.

· Основной принцип бухгалтерского учета - принцип двойной записи.

· Понятие счета бухгалтерского учета - активные и пассивные счета.

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

· Формирование проведения по счетам бухгалтерского учета на примерах: поступление товаров, реализация товаров и оплата долга поставщику.

· Основной бухгалтерский отчет - баланс, выполнение его построения для ряда хозяйственных операций.

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

· Создание объекта, где будут храниться все сделанные проведения - регистра бухгалтерии.

Занятие 15. «Проведение документов по бухгалтерскому учету» .

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

· Формирование конструктором документы по выписке банка.

· Документ реализации (продажи) товаров, — написание необходимого программного кода.

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

Занятие 16 . «Отчеты по бухгалтерскому учету. Закрытие месяца» .

· Построение отчетов по бухгалтерскому учету. Отчет «остатки по счетам бухгалтерского учета», особенность получения остатков на заданную дату (такая же особенность, как и регистров накопления).

· Отчет «Баланс» - основную форму бухгалтерской отчетности.

· Изменение баланса при выполнении различных проводок.

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

Модуль 5. Расчет заработной платы.

Занятие 17 . «Общие сведения о заработной плате. Создание объектов расчета» .

· выполнение подготовительных действий для расчета заработной платы - создание необходимых объектов и выполнение их настроек. Теоретические аспекты расчета зарплаты, понятие видов расчета (начисления и удержания).

· Учет отработанного времени методом отклонений.

· Объект конфигурации - план видов расчета. Создание начисления и настройка вытеснения видов расчетов.

· Настройка графика работы предприятия - какие дни являются выходными, а какие рабочими.

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

· Создание документа с помощью которого будет выполняться начисление зарплаты - «Начисление оклада», а также документ, фиксирующий прогул работника - «Невыход сотрудника».

Занятие 18 . День 18. Начисление заработной платы

· Непосредственный расчет заработной платы - все подготовительные действия уже выполнены.

· На заработную плату влияют прогулы сотрудников - чем больше сотрудник не работает (в прогуле), тем меньше получает зарплаты.

· В регистре расчета невыходы должны вытеснять оклад - добьемся этого с помощью разработки алгоритма проведения документа «Невыход сотрудника».

· Типовая технология расчета заработной платы - расчета в два этапа.

· Расчет оклада исходя из отработанного времени сотрудником.

· Понятие зависимости от базы. С помощью этого вида зависимости можно, например, вычислять премии, которые зависят от оклада.

· Расчет сотрудникам с помощью создания соответствующего документа.

Занятие 19 . «Универсальные механизмы расчета. Отчеты» .

· Универсальность расчета заработной платы в 1С. То есть пользователь может в определенных рамках настраивать систему под себя, не прибегая к программированию.

· Задачу выплаты заработной платы. Т.е. нужно помнить, сколько сотруднику было начислено, сколько выплачено (возможно была частичная выплата), какой остаток долга перед сотрудником - для этого потребуется ряд объектов системы.

· Разработка отчета, показывающего все начисления сотрудника за период - какие суммы по какому виду расчета были начислены.

· Построение наглядного отчета о деятельности сотрудника - какое время он работал, когда был в отгуле. Данный отчет будет построен в виде диаграммы Ганта.

Модуль 6. CRM-система

Занятие 20 . «Основы CRM-системы» .

· Создание объектов CRM-системы в рамках нашей конфигурации.

· Базовые понятия CRM, примеры таких систем.

· Объекты, необходимые для построения CRM-системы.

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

· Разработка отчета, который будет сегментировать клиентов по классам важности. Обычно используется 3 класса: наиболее важные, средние по важности и неважные клиенты. В качестве параметра, по которому будет проводиться классификация, используется прибыль или выручка по клиентам.

Занятие 21. «Воронка продаж. Бизнес-процессы и задачи».

· Разработка важнейшего инструмента для управленцев - воронки продаж. С помощью этого инструмента можно понять, каким образом увеличить продажи. А также можно спланировать рост выручки, например, при проведении рекламных компаний.

· Для построения воронки продаж разработка этапов продаж - создание необходимых для этого объектов.

· Работа с бизнес-процессами. Термины по бизнес-процессам и схемы.

· Создание простого бизнес-процесса. Отображение карты маршрута пользователю – так, чтобы можно было наглядно видеть текущее состояние бизнес-процесса.

· Разработка более сложного бизнес-процесса - циклического.

Приложение 1

Специальность 09.02.03

КУРСОВОЙ ПРОЕКТ

На тему

МДК 03.03 «Документирование и сертификация»

Подготовил обучающийся группы ПО-41 __________ М.А. Чудин

Руководитель курсового проекта __________ О.А. Комиссарова

Оценка _____________

Введение

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

В настоящее время для многих учреждений наступает время, когда без электронных приложении нельзя обойтись. И такое учреждение как «ЗАГС» не исключение. В век информационных технологий, когда население городов может достигать миллионов людей, учёт, сохранение и введение информации на бумажных носителях неэффективно. Поэтому для облегчения работы персонала, увеличению эффективности и уменьшению времени работы необходимо создать или приобрести электронную базу данных.

В ходе анализа уже созданных баз данных существующие аналоги были отбракованы из-за следующих причин:

1. Высокая цена программного продукта.

2. Неудобный или сложный интерфейс

3. Отсутствие необходимых функций

Поэтому базу данных «ЗАГС» следует разработать своими силами.

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

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

Для создания электронной базы данных будет использоваться инструмент разработки «Microsoft Access » из пакета программ «Microsoft Office». Было выбран данный программный продукт из-за приведенных ниже достоинств:

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

2. Хранит все данные в одном файле, хотя и распределяет их по разным таблицам, как и положено реляционной СУБД. К этим данным относится не только информация в таблицах, но и другие объекты базы данных.

3. Предлагает большое количество Мастеров, которые выполняют основную работу за пользователя при работе с данными и разработке приложений, помогают избежать рутинных действий и облегчают работу неискушенному в программировании пользователю.

4. Распространенность, которая обусловлена тем, что Access является продуктом компании Microsoft,

5. Постоянно обновляется производителем, поддерживает множество языков,

6. Полностью совместим с операционной системой Windows,

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

8. Широкие возможности по импорту/экспорту данных в различные форматы, от таблиц Excel и текстовых файлов, до практически любой серверной СУБД через механизм ODBC,

9. Наличие развитых встроенных средств разработки приложений. Большинство приложений, распространяемых среди пользователей, содержит тот или иной объем кода VBA (Visual Basic for Applications),

10. Наличие встроенного языка макрокоманд.

В сравнении с другими СУБД MS Acces является самой понятной и простой и это значительно снизит затраты на возможные ошибки при разработке приложения.

В ходе анализа предметной области были выявлены недостатки в существующем программном обеспечении. И было выбран инструмент разработки, а также выявлены его плюсы в сравнении с другими СУБД.

Краткое описание программного продукта

Планирование документации (ГОСТ Р ИСО/МЭК ТО 9294-93)

Документация разработки

База данных «загс»

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

Лист утверждения

РФ.0126644.410-01.ТЗ.01-лу

УТВЕРЖДЕНО

РФ.0126644.410-01.ТЗ.01-лу

База данных «загс»

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

РФ.0126644.410-01.ТЗ.01

Аннотация

В данном программном документе приведено техническое задание на разработку программы [[[ Базы данных ЗАГС.]]]

В данном программном документе, в разделе «Введение» указано наименование, краткая характеристика области применения программы (программного изделия).

В разделе «Основания для разработки» указаны документы, на основании которых ведется разработка, наименование и условное обозначение темы разработки.

В данном программном документе, в разделе «Назначение разработки» указано функциональное и эксплуатационное назначение программы (программного изделия).

Раздел «Требования к программе» содержит следующие подразделы:

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

· требования к надежности;

· условия эксплуатации;

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

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

• специальные требования.

В данном программном документе, в разделе «Требования к программной документации» указаны предварительный состав программной документации и специальные требования к ней.

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

В данном программном документе, в разделе «Стадии и этапы разработки» установлены необходимые стадии разработки, этапы и содержание работ.

В разделе «Порядок контроля и приемки» должны быть указаны виды испытаний и общие требования к приемке работы.

Оформление программного документа «Руководство оператора» произведено по требованиям ЕСПД (ГОСТ 19.101-77 1), ГОСТ 19.103-77 2), ГОСТ 19.104-78* 3), ГОСТ 19.105-78* 4), ГОСТ 19.106-78* 5), ГОСТ 19.201-78 6), ГОСТ 19.604-78* 7)).

АННОТАЦИЯ 2

1. ВВЕДЕНИЕ 5

1.1. Наименование программы 5

1.2. Краткая характеристика области применения программы 5

2. ОСНОВАНИЕ ДЛЯ РАЗРАБОТКИ 5

2.1. Основание для проведения разработки 5

2.2. Наименование и условное обозначение темы разработки 6

3. НАЗНАЧЕНИЕ РАЗРАБОТКИ 6

3.1. Функциональное назначение программы 6

3.2. Эксплуатационное назначение программы 6

4. ТРЕБОВАНИЯ К ПРОГРАММЕ 7

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

4.1.1. Требования к составу выполняемых функций 7

4.1.2. Требования к организации входных данных 7

4.1.3. Требования к организации выходных данных 7

4.1.4. Требования к временным характеристикам 8

4.2. Требования к надежности 8

4.2.1. Требования к обеспечению надежного (устойчивого) функционирования программы 8

4.2.2. Время восстановления после отказа 8

4.2.3. Отказы из-за некорректных действий оператора 9

4.3. Условия эксплуатации 9

4.3.1. Климатические условия эксплуатации 9

4.3.2. Требования к видам обслуживания 9

4.3.3. Требования к численности и квалификации персонала 9

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

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

4.5.1. Требования к информационным структурам и методам решения 10

4.5.2. Требования к исходным кодам и языкам программирования 10

4.5.3. Требования к программным средствам, используемым программой 11

4.5.4. Требования к защите информации и программ 11

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

5. ТРЕБОВАНИЯ К ПРОГРАММНОЙ ДОКУМЕНТАЦИИ 11

5.1. Предварительный состав программной документации 11

5.2. Специальные требования к программной документации 12

6. ТЕХНИКО-ЭКОНОМИЧЕСКИЕ ПОКАЗАТЕЛИ 12

6.1. Ориентировочная экономическая эффективность 12

6.2. Предполагаемая годовая потребность 12

6.3. Экономические преимущества разработки 13

7. СТАДИИ И ЭТАПЫ РАЗРАБОТКИ 13

7.1. Стадии разработки 13

7.2. Этапы разработки 13

7.4. Исполнители 14

8. ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ 15

8.1. Виды испытаний 15

8.2. Общие требования к приемке работы 15

ПРИЛОЖЕНИЕ 1 15

ПРИЛОЖЕНИЕ 2 15

Введение

Наименование программы

Наименование - «ЗАГС».

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

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

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

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

4.1.1. Требования к составу выполняемых функций

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

1. Регистрация данных о населении.

2. Учёт и формирование отчёты на основе зарегистрированных данных о населении.

3. Автоматизация формирования справок.

4. Создание статистик, на основе зарегистрированных данных о населении.

4.1.2. Требования к организации входных данных

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

4.1.3. Требования к организации выходных данных

Выходные данные программы должны быть организованы в виде структурированных таблиц, графиков, документов. В файле БД с расширением (.accdb)

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

4.1.4. Требования к временным характеристикам

Требования к временным характеристикам программы не предъявляются.

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

4.2.1. Требования к обеспечению надежного (устойчивого) функционирования программы

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

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

б) регулярным выполнением рекомендаций Министерства труда и социального
развития РФ, изложенных в Постановлении от 23 июля 1998 г. «Об утверждении
межотраслевых типовых норм времени на работы по сервисному обслуживанию
ПЭВМ и оргтехники и сопровождению программных средств»;

в) регулярным выполнением требований ГОСТ 51188-98. Защита информации.
Испытания программных средств на наличие компьютерных вирусов;

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

4.2.2. Время восстановления после отказа

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

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

4.2.3. Отказы из-за некорректных действий оператора

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

Условия эксплуатации

4.2.2. Климатические условия эксплуатации

Программа будет прекрасно работать от плюс 5 до плюс 35 °C при относительной влажности 90 % и атмосферном давлении 462 мм.рт.ст., поскольку такие условия приблизительно соответствуют условиям эксплуатации современных компьютеров непромышленного исполнения.

4.2.3. Требования к видам обслуживания

База данных не требует проведения каких-либо видов обслуживания.

4.2.4. Требования к численности и квалификации персонала

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

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

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

а) задача поддержания работоспособности технических средств;

б) задачи установки (инсталляции) и поддержания работоспособности системных
программных средств - операционной системы;

в) задача установки (инсталляции) программы.

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

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

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

В состав технических средств должен входить IBM-совместимый персональный компьютер (ПЭВМ), включающий в себя:

а) процессор Pentium - 4 с тактовой частотой, 1.2 ГГц, не менее;

б) оперативную память объемом, 128 Mб, не менее;

в) жесткий диск объемом 40 Гб, и выше;

г) оптический манипулятор типа «мышь»;

д) наличие 2 COM-портов;

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

4.4.1. Требования к информационным структурам и методам решения

Требования к информационным структурам (файлов) на входе и выходе, а также к методам решения не предъявляются.

4.4.2. Требования к исходным кодам и языкам программирования

Исходные коды программы должны быть реализованы на языке Sql. В качестве интегрированной среды разработки программы должна быть использована среда MS Acces.

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

Системные программные средства, используемые программой, должны быть представлены указанными ниже лицензионными локализованными версиями операционных систем Операционные системы Windows XP с пакетом обновления 3 (SP3) (32-разрядная), Windows Vista с пакетом обновления 1, Windows Server 2003 R2 с установленным MSXML 6.0, Windows Server 2008 (32- или 64-разрядная), Windows 7 или более поздних версий.

4.4.4. Требования к защите информации и программ

Требования к защите информации и программ не предъявляются.

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

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

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

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

Предварительный состав программной документации

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

1) техническое задание;

2) спецификация;

3) текст программы;

4) описание программы;

5) программу и методики испытаний;

6) пояснительная записка;

7) ведомость эксплуатационных документов;

8) формуляр;

9) описание применения;

10) руководство системного программиста;

11) руководство программиста;

12) руководство оператора;

5.2. Специальные требования к программной документации

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

Стадии и этапы разработки

Стадии разработки

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

1) разработка технического задания;

2) рабочее проектирование;

3) внедрение.

Этапы разработки

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

На стадии рабочего проектирования должны быть выполнены перечисленные ниже этапы работ:

1) разработка программы;

2) разработка программной документации;

3) испытания программы.

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

На этапе разработки технического задания должны быть выполнены перечисленные ниже работы:

1) постановка задачи;

2) определение и уточнение требований к техническим средствам;

3) определение требований к программе;

4) определение стадий, этапов и сроков разработки программы и документации на неё;

5) выбор языков программирования;

6) согласование и утверждение технического задания.

На этапе разработки программы должна быть выполнена работа по программированию и отладке программы.

На этапе разработки программной документации должна быть выполнена разработка программных документов в соответствии с требованиями ГОСТ 19.101-77 и требованием п. «Предварительный состав программной документации» настоящего технического задания.

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

1) разработка, согласование и утверждение программы и методики испытаний;

2) проведение приемо-сдаточных испытаний;

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

На этапе подготовки и передачи программы должна быть выполнена работа по подготовке и передаче программы и программной документации в эксплуатацию.

Исполнители

Руководитель курсового проекта Комиссарова О.А.

Ответственный исполнитель Чудин М.А.

Исполнитель

Вед. Инженер Чудин М.А.

Порядок контроля и приемки

Виды испытаний

Приемо-сдаточные испытания программы должны проводиться согласно разработанной и согласованной «Программы и методики испытаний».

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

8.2. Общие требования к приемке работы

После проведения испытаний в полном объеме, на основании «Протокола испытаний» утверждают «Свидетельство о приемке» и производят запись в программном документе «Формуляр».

Приложение 1

Приложение 2

Спецификации

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

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

1. Руководство программиста

2. Соглашение о требованиях:

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

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

Внешняя спецификация;

ОПИСАНИЕ ПРОГРАММНОГО ИЗДЕЛИЯ

Наименование и шифры ПО:

Наименование	шифр ПО

Краткое описание ПО

Спецификация

Лист утверждения

РФ.01266444.41004-01 01-лу

УТВЕРЖДЕНО

РФ.01266444.41004-01 01-лу

РФ.01266444.41004-01 01

Листов 3

Обозначение	Наименование	Примечание
	Документация
РФ.01266444.41004-01 13 01-ЛУ	Описание программы
	Лист утверждения
РФ.01266444.41004-01 13 01	Описание программы
РФ.01266444.41004-01 33 01-ЛУ	Руководство программиста
	Лист утверждения
РФ.01266444.41004-01 33 01	Руководство программиста
РФ.01266444.41004-01 34 01-ЛУ	Руководство пользователя
	Лист утверждения
РФ.01266444.41004-01 34 01	Руководство пользователя
	Компоненты
БД СУБД ACCESS	База данных “Автоматизация работы регистратора медицинского учреждения”

Лист регистрации изменений
Номера листов (страниц)	Всего листов (страниц) в докум	№ документа	Входящий № сопрово дительного документа и дата	Подп.	Дата
Изм	изменен ных	заме ненных	новых	анулиро ванных
	1,2,4					ПР 001.2017	РФ.01266444.41004-01 01-лу		13.03.17
	13,14					ТТ 001.2017	РФ.01266444.41004-01 01-лу		13.03.17

Документация продукции

Заключение

В ходе курсовой работы до документированию программного продукта были изучены государственные стандарты и приобретён опыт по их применению.

Список источников и литературы

1) ГОСТ 19.101-77 ЕСПД. Виды программ и программных документов

2) ГОСТ 19.103-77 ЕСПД. Обозначение программ и программных документов

3) ГОСТ 19.104-78* ЕСПД. Основные надписи

4) ГОСТ 19.105-78* ЕСПД. Общие требования к программным документам

5) ГОСТ 19.106-78* ЕСПД. Общие требования к программным документам, выполненным печатным способом

6) ГОСТ 19.201-78 ЕСПД. Техническое задание. Требования к содержанию и оформлению

7) ГОСТ 19.604-78* ЕСПД. Правила внесения изменений в программные документы, выполненные печатным способом

Приложение 1

Министерство образования Республики Башкортостан

ГАПОУ Стерлитамакский колледж строительства и профессиональных технологий

Специальность 09.02.03

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

КУРСОВОЙ ПРОЕКТ

На тему

«Документирование Базы данных «ЗАГС»»

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

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

ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

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

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

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

Выполнил

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

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

ВВЕДЕНИЕ

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

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

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

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

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

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

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

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).

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

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

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

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

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

В зависимости от класса создаваемого программного обеспечения, процесс проектирования может обеспечиваться как «ручным» проектированием, так и различными средствами его автоматизации. В процессе проектирования программного обеспечения для выражения его характеристик используются различные нотации - блок-схемы, ER-диаграммы, UML-диаграммы, DFD-диаграммы, а также макеты.

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

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

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

-Пользовательские интерфейсы.

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

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

-техническое предложение;

-эскизный проект;

-технический проект;

-рабочий проект.

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

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

Разработка программного обеспечения (англ. software development) - деятельность по созданию нового программного обеспечения.

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

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

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

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

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

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

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

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

Интегрированная среда разработки, ИСP/IDE (англ. Integrated development environment) - комплекс программных средств, используемый программистами для разработки программного обеспечения.

Первые IDE были созданы для работы через консоль или терминал, которые сами по себе были новинкой: до того программы создавались на бумаге, вводились в машину с помощью предварительно подготовленных бумажных носителей (перфокарт, перфолент) и т. д.BASIC был первым языком, который был создан с IDE, и был также первым, который был разработан для использования в консоли или терминале. Эта IDE (часть Dartmouth Time Sharing System) управлялась при помощи команд, поэтому существенно отличалась от более поздних, управляемых с помощью меню и горячих клавиш, и тем более графических IDE, распространённых в XXI веке. Однако она позволяла редактировать исходный код, управлять файлами, компилировать, отлаживать и выполнять программы способом, принципиально подобным современным IDE.I - продукт от Softlab Munich, был первой в мире интегрированной средой разработки для программного обеспечения в 1975 г. и, возможно, мировым лидером в этой рыночной нише в течение 1970-х и 1980-х годов. Он был установлен у 22000 программистов во всем мире. До 1989 года 6000 копий было установлено в Федеративной Республике Германия. Ныне Maestro I принадлежит истории и может быть найден разве что в Музее Информационной технологии в Арлингтоне.

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

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

-текстовый редактор;

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

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

-отладчик.

Иногда содержит также средства для интеграции с системами управления версиями и разнообразные инструменты для упрощения конструирования графического интерфейса пользователя. Многие современные среды разработки также включают браузер классов, инспектор объектов и диаграмму иерархии классов - для использования при объектно-ориентированной разработке программного обеспечения. IDE обычно предназначены для нескольких языков программирования - такие как IntelliJ IDEA, NetBeans, Eclipse, Qt Creator, Geany, Embarcadero RAD Studio, Code::Blocks, Xcode или Microsoft Visual Studio, но есть и IDE для одного определённого языка программирования - как, например, Visual Basic, Delphi, Dev-C++.

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

7 Язык SQL

SQL (Structured Query Language - Структурированный язык запросов) - язык управления базами данных для реляционных баз данных. Сам по себе SQL не является Тьюринг-полным языком программирования, но его стандарт позволяет создавать для него процедурные расширения, которые расширяют его функциональность до полноценного языка программирования.

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

Первый официальный стандарт языка был принят ANSI в 1986 году и ISO - в 1987. С тех пор были созданы еще несколько версий стандарта, некоторые из них повторяли предыдущие с незначительными вариациями, другие принимали новые существенные черты.

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

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 носят декларативный характер.

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

-SELECT (выбрать);

-INSERT (вставить);

-UPDATE (обновить);

-DELETE (удалить).

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

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

-GRANT (дать права)

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

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

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

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

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

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

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

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

-защита паролем;

-шифрование;

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

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

Защита паролем - это самый простой способ защиты базы данных от несанкционированного доступа.

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

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

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

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

-конфиденциальность;

-целостность;

-идентифицируемость.

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

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

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

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

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

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

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

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

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

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

Общие критерии оценки защищённости информационных технологий, Общие критерии, ОК (англ. Common Criteria for Information Technology Security Evaluation, Common Criteria, CC) - российский и международный стандарт по компьютерной безопасности. В отличие от стандарта FIPS 140, Common Criteria не приводит списка требований по безопасности или списка особенностей, которые должен содержать продукт. Вместо этого он описывает инфраструктуру (framework), в которой потребители компьютерной системы могут описать требования, разработчики могут заявить о свойствах безопасности продуктов, а эксперты по безопасности определить, удовлетворяет ли продукт заявлениям. Таким образом, Common Criteria позволяет обеспечить условия, в которых процесс описания, разработки и проверки продукта будет произведён с необходимой скрупулёзностью.

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

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

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

-FAU - аудит, безопасность (требования к сервису, протоколирование и аудит);

-FIA - идентификация и аутентификация;

-FRU - использование ресурсов (для обеспечения отказоустойчивости).

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

-FCO - связь (безопасность коммуникаций отправитель-получатель);

-FPR - приватность;

-FDP - защита данных пользователя;

-FPT - защита функций безопасности объекта оценки.

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

-FCS - криптографическая поддержка (обслуживает управление криптоключами и крипто-операциями);

-FMT - управление безопасностью;

-FTA - доступ к объекту оценки (управление сеансами работы пользователей);

-FTP - доверенный маршрут/канал;

Требования гарантии безопасности (доверия) - требования, предъявляемые к технологии и процессу разработки и эксплуатации объекта оценки. Разделены на 10 классов, 44 семейства, 93 компонента, которые охватывают различные этапы жизненного цикла.

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

-APE - оценка профиля защиты;

-ASE - оценка задания по безопасности.

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

-ADV - разработка, проектирование объекта;

-ALC - поддержка жизненного цикла;

-ACM - управление конфигурацией;

-AGD - руководство администратора и пользователя;

-ATE - тестирование;