ГБОУ СПО СТАПМ им. Д.И. Козлова
РАБОЧАЯ ПРОГРАММА ПРОФЕССИОНАЛЬНОГО МОДУЛЯ
ПМ 03. Участие в интеграции программных модулей
Профессиональные модули
программы подготовки специалистов среднего звена
по специальности 09.02.03 Программирование в компьютерных системах
(базовая подготовка)
ОДОБРЕНО
Цикловой комиссией
специальности 09.02.03
Председатель_____Инжеватова Г.В.
«___» _______________20___г.
Составители:
Ляпнев А.В., Кадацкая Р.Б., преподаватель ГБПОУ «СТАПМ им. Д.И. Козлова».
Эксперты:
Техническая экспертиза: ______________________________________
Рабочая программа разработана на основе Федерального государственного образовательного стандарта среднего профессионального образования по специальности 09.02.03 Программирование в компьютерных системах (утв.
приказом Министерства образования и науки РФ от 28 июля 2014 г. № 804) Рабочая программа разработана в соответствии с разъяснениями по формированию примерных программ учебных дисциплин начального профессионального и среднего профессионального образования на основе Федеральных государственных образовательных стандартов начального профессионального и среднего профессионального образования, утвержденными И.М. Реморенко, директором Департамента государственной политики и нормативно-правового регулирования в сфере образования Министерства образования и науки Российской Федерации от 27 августа 2009 года.
стр.
1. ПАСПОРТ РАБОЧЕЙ ПРОГРАММЫ ПРОФЕССИОНАЛЬНОГО 4
МОДУЛЯ
2. РЕЗУЛЬТАТЫ ОСВОЕНИЯ ПРОФЕССИОНАЛЬНОГО МОДУЛЯ 6
3. СТРУКТУРА И СОДЕРЖАНИЕ ПРОФЕССИОНАЛЬНОГО МОДУ- 7
ЛЯ4. УСЛОВИЯ РЕАЛИЗАЦИИ ПРОГРАММЫ ПРОФЕССИОНАЛЬНОГО 16
МОДУЛЯ
5. КОНТРОЛЬ И ОЦЕНКА РЕЗУЛЬТАТОВ ОСВОЕНИЯ ПРОФЕССИ- 20
ОНАЛЬНОГО МОДУЛЯ (ВИДА ПРОФЕССИОНАЛЬНОЙ ДЕЯТЕЛЬНОСТИ)
1. ПАСПОРТ РАБОЧЕЙ ПРОГРАММЫ
ПРОФЕССИОНАЛЬНОГО МОДУЛЯ
ПМ.03 Участие в интеграции программных модулей1.1. Область применения программы Рабочая программа профессионального модуля является частью основной профессиональной образовательной программы в соответствии с ФГОС по специальности СПО 09.2.03 Программирование в компьютерных системах (базовой подготовки) в части освоения основного вида профессиональной деятельности (ВПД): Участие в интеграции программных модулей и соответствующих профессиональных компетенций (ПК):
ПК 3.1. Анализировать проектную и техническую документацию на уровне взаимодействия компонент программного обеспечения.
ПК 3.2. Выполнять интеграцию модулей в программную систему.
ПК 3.3. Выполнять отладку программного продукта с использованием специализированных программных средств.
ПК 3.4. Осуществлять разработку тестовых наборов и тестовых сценариев.
ПК 3.5. Производить инспектирование компонент программного продукта на предмет соответствия стандартам кодирования.
ПК 3.6. Разрабатывать технологическую документацию.
Программа профессионального модуля может быть использована в дополнительном профессиональном образовании и профессиональной подготовке работников в области программирования компьютерных систем при наличии основного общего, среднего (полного) общего образования. Опыт работы не требуется.
1.2. Цели и задачи модуля – требования к результатам освоения модуля С целью овладения указанным видом профессиональной деятельности и соответствующими профессиональными компетенциями обучающийся в ходе освоения профессионального модуля должен:
иметь практический опыт:
Участия в выработке требований к программному обеспечению;
Участия в проектировании программного обеспечения с использованием специализированных программных пакетов;
Владеть основными методологиями процессов разработки программного обеспечения;
Использовать методы для получения кода с заданной функциональностью и степенью качества;
Пользоваться ремонтной и эксплуатационной технической документацией;
Производить техническое обслуживание, контроль, диагностику средств вычислительной техники, восстановление работоспособности вычислительной техники и компьютерных сетей;
Применять диагностические программы общего и специального назначения;
Проводить текущее техническое обслуживание вычислительной техники.
Модели процесса разработки программного обеспечения;
Основные принципы процесса разработки программного обеспечения;
Основные подходы к интегрированию программных модулей;
Основные методы и средства эффективной разработки;
Основы верификации и аттестации программного обеспечения;
Концепции и реализации программных процессов;
Принципы построения, структуры и приемы работы с инструментальными средствами, поддерживающими создание программного обеспечения;
Методы организации работы в коллективах разработчиков программного обеспечения;
Основные положения метрологии программных продуктов, принципы построения, проектирования и использования средств для измерений характеристик и параметров программ, программных систем и комплексов;
Стандарты качества программного обеспечения;
Методы и средства разработки программной документации.
всего – 684 часа, в том числе:
максимальной учебной нагрузки обучающегося – 441 час, включая:
обязательной аудиторной учебной нагрузки обучающегося – 295 часов;
самостоятельной работы обучающегося – 143 часа;
производственной практики (по профилю специальности)– 243 часа.
2. РЕЗУЛЬТАТЫ ОСВОЕНИЯ ПРОФЕССИОНАЛЬНОГО МОДУЛЯ
Результатом освоения программы профессионального модуля является овладение обучающимися видом профессиональной деятельности (ВПД) Участие в интеграции программных модулей, в том числе профессиональными (ПК) и общими (ОК) компетенциями:Код Наименование результата обучения ПК 3.1 Анализировать проектную и техническую документацию на уровне взаимодействия компонент программного обеспечения.
ПК 3.2 Выполнять интеграцию модулей в программную систему.
ПК 3.3 Выполнять отладку программного продукта с использованием специализированных программных средств.
ПК 3.4 Осуществлять разработку тестовых наборов и тестовых сценариев.
ПК 3.5 Производить инспектирование компонент программного продукта на предмет соответствия стандартам кодирования.
ПК 3.6 Разрабатывать технологическую документацию.
ОК 1 Понимать сущность и социальную значимость своей будущей профессии, проявлять к ней устойчивый интерес.
ОК 2 Организовывать собственную деятельность, определять методы и способы выполнения профессиональных задач, оценивать их эффективность и качество.
ОК 3 Принимать решения в стандартных и нестандартных ситуациях и нести за них ответственность.
ОК 4 Осуществлять поиск и использование информации, необходимой для эффективного выполнения профессиональных задач, профессионального и личностного развития.
ОК 5 Использовать информационно-коммуникационные технологии в профессиональной деятельности.
ОК 6 Работать в коллективе и в команде, эффективно общаться с коллегами, руководством, потребителями.
ОК 7 Брать на себя ответственность за работу членов команды (подчиненных), за результат выполнения заданий.
ОК 8 Самостоятельно определять задачи профессионального и личностного развития, заниматься самообразованием, осознанно планировать повышение квалификации.
ОК 9 Ориентироваться в условиях частой смены технологий в профессиональной деятельности.
– – –
2.2. Тематический план и содержание МДК 03.01 Технология разработки программного обеспечения
– – –
4. УСЛОВИЯ РЕАЛИЗАЦИИ ПРОГРАММЫ
ПРОФЕССИОНАЛЬНОГО МОДУЛЯ
4.1. Требования к минимальному материально-техническому обеспечению Реализация программы дисциплины требует наличия учебного кабинета и лабораторий ТСО.
Оборудование учебного кабинета:
посадочные места по количеству обучающихся;
компьютерный стол, интерактивная доска (или проектор) для преподавателя.
Технические и программные средства обучения:
персональные компьютеры, IBM-совместимые;
ОС с графическим интерфейсом пользователя;
Borland Delphi 7;
лицензионное программное обеспечение;
комплект учебно-методической документации;
мультимедийное оборудование.
Оборудование лаборатории и рабочих мест лаборатории:
компьютерные столы;
оборудование локальной сети.
4.2. Информационное обеспечение обучения Перечень рекомендуемых учебных изданий, Интернет-ресурсов, дополнительной литературы
Основные источники:
1. Рудаков А.В. Технология разработки программных продуктов. М.: ОИЦ «Академия», 2013.
2. Рудаков А.В. Технология разработки программных продуктов. Практикум.
М.: ОИЦ «Академия», 2013.
3. Благодатских В.А. и др. Стандартизация разработки программных средств, 2010.
4. Ермоленко, Д.Н. Метрология, стандартизация и сертификация программного обеспечения: учебное пособие. - Белгород: Изд-во БГТУ, 2008. – 83 с.
5. Вигерс К. Разработка требований к программному обеспечению. Издательско-торговый дом «Русская редакция», 2009.
6. Кравацкий Ю.П., Рамендик М.А. Выбор, сборка, апгрейд качественного компьютера. – М. 2008 г.
7. Крылов Е.В., Острейковский В.А., Типикин Н.Г. Техника разработки программ. Книга 2. Технология, надежность и качество программного обеспечения - М.: Высшая школа. – 2008.
8. Крылова Г.Д. Основы стандартизации, сертификации, метрологии:
Учебник для вузов. - 3-е изд.,- М.: ЮНИТИ-ДАНА, 2007. -671 с.
9. Л.Басс, П.Клементс, Р.Кацман. Архитектура программного обеспечения на практике. 2-е издание. СПб.: Питер, 2010.
10. Канер С., Д. Фолк, Е. Нгуен. Тестирование программного обеспечения.
Фундаментальные концепции менеджмента бизнес-приложений. «ДиаСофт»,
Дополнительные источники:
1. Бек К. Экстремальное программирование. С-Пб.:Питер, 2002, 224 с.
2. Благодатских В.А. и др. Стандартизация разработки программных средств:
Учеб.пособие / В.А. Благодатских, В.А.Волнин, К.Ф.Поскакалов; Под ред.
О.С.Разумова. – М.: Финансы и статистика, 2003. – 288 с.:ил.
3. Благодатских В.А., Волнин В.А., Поскакалов К.Ф. Стандартизация разработки программных средств. Под ред. Разумова О.С. М.: Финансы и статистика, 2006. -288 с.: ил.
4. Боэм Б.У. Инженерное проектирование программного обеспечения. М.:
Радио и связь, 1985. – 511 с.
5. Бутаков Е.А. Методы создания качественного программного обеспечения ЭВМ. – М.: Энергоатомиздат, 1984. – 457 с.
6. Ван-Тассел Д. Стиль, разработка, эффективность, отладка и испытание программ. – М.: Мир, 1981. – 578 с.
7. Вендров А.М. Практикум по проектированию программного обеспечения экономических информационных систем. – М.: Финансы и статистика, 2002.
8. Горчинская О.Ю. Designer/2000 - новое поколение CASE-продуктов фирмы ORACLE. "СУБД", 2005, №3.
9. ГОСТ 13377-75. Надежность в технике. Термины и определения. М.: Издво стандартов, 1975.
10. ГОСТ 27.002-89. Надёжность в технике. Основные понятия. Термины и определения. – М.: Издательство стандартов, 1990. – 37 с.
11. ГОСТ Р ИСО 9001-2001. Системы менеджмента качества. Требования.
М.: ИПК Изд-во стандартов, 2001, – 140 с.
12. Жоголев Е.А. Введение в технологию программирования: Конспект лекций. – М.: ДИАЛОГ-МГУ, 1994.
13. Зубкова Т.М. Технология разработки программного обеспечения:
Учебное пособие. - Оренбург: ГОУ ОГУ, 2004. – 101 с.
14. Иванова Г.С. Технология программирования: Учебник для вузов. – М.:
Изд-во МГТУ им. Н.Э.Баумана, 2006. – 336 с.
15. Калянов Г.Н. CASE – технологии: Консалтинг в автоматизации бизнеспроцессов - М.: Горячая линия-Телеком, 2002
16. Крылова Г.Д. Основы стандартизации, сертификации, метрологии. – М.:
ЮНИТИ-ДАНА, 2000. – 711 с.
17. Липаев В.В. Качество программного обеспечения. – М.:Финансы и статистика, 1983. – 263 с.
18. Липаев В.В. Отладка сложных программ: Методы средства, технология.
М.: Энергоатомиздат, 1993. – 384 с.
19. Липаев В.В. Процессы и стандарты жизненного цикла сложных программных средств. Справочник – М.: Изд-во СИНТЕГ, 2008 – 276 с.
21. Маклаков С.В.. BPwin, ERwin – CASE-средства разработки информационных систем. – М., «ДИАЛОГ-МИФИ», 2001.
22. Орлов В.В. Технологии разработки программных продуктов. – СПб.:
Питер, 2003. – 437 с.
23. Панащук С.А. Разработка информационных систем с использованием CASE-системы Silverrun. "СУБД", 1995, №3.
24. Платонов Ю.М., Гапеенков А.А. Ремонт зарубежных принтеров. – М.:
Солон – Р, 2005 г.
25. Платонов Ю.М., Уткин Ю.Г. Диагностика, ремонт и профилактика персональных компьютеров. – М. Горячая линия – Телеком, 2003 г.
26. Родин А.В., Тюнин Н.А., Воронов М.А. Ремонт мониторов. – М.: Солон
27. Фаулер Р. и др. Рефакторинг: улучшение существующего кода. М.: Символ-Плюс, 2009 – 432 с.
28. Черемных С.В., и др. Структурный анализ систем: IDEF-технологии. – М: Финансы и статистика, 2002.
Справочная и нормативная литература:
1. Система стандартов ЕСПД.
2. ГОСТ Р ИСО/МЭК 9126-93 Информационная технология. Оценка программной продукции. Характеристика качества и руководства по их применению.
3. ГОСТ 28195-89 Оценка качества программных средств. Общие положения
4. ГОСТ Р ИСО/МЭК 12207-99 Процессы жизненного цикла программных средств.
Периодические издания (отечественные журналы):
1. «Компьютер пресс»;
Интернет – ресурсы:
1. Образовательный портал: http\\www.edu. ru;
2. Интрернет университет информационных технологий http://www.intuit.ru;
3. Учебная мастерская:
Http\\www.edu.BPwin - Мастерская Dr_dimdim.ru;
4.3. Общие требования к организации образовательного процесса Обязательным условием допуска к учебной практике в рамках профессионального модуля «Участие в интеграции программных модулей»
является освоение учебной практики для получения первичных профессиональных навыков в рамках профессионального модуля «Разработка программных модулей программного обеспечения для компьютерных систем».
Перед изучением модуля обучающиеся изучают следующие дисциплины «Операционные системы», «Архитектура компьютерных систем», «Технические средства информатизации», «Информационные технологии», «Основы программирования», «Правовое обеспечение профессиональной деятельности», «Безопасность жизнедеятельности», «Теория алгоритмов», «Прикладное программирование», «Инфокоммуникационные системы и сети», «Технология разработки и защиты баз данных».
4.4. Кадровое обеспечение образовательного процесса Требования к квалификации педагогических (инженернопедагогических) кадров, обеспечивающих обучение по междисциплинарному курсу: наличие высшего профессионального образования, соответствующего профилю модуля «Участие в интеграции программных модулей»
и специальности «Программирование в компьютерных системах».
Требования к квалификации педагогических кадров, осуществляющих руководство практикой Инженерно-педагогический состав: дипломированные специалисты – преподаватели междисциплинарных курсов, а также общепрофессиональных дисциплин: «Информационные технологии»; «Технические средства информатизации»; «Основы программирования».
5. КОНТРОЛЬ И ОЦЕНКА РЕЗУЛЬТАТОВ ОСВОЕНИЯ
ПРОФЕССИОНАЛЬНОГО МОДУЛЯ (ВИДА ПРОФЕССИОНАЛЬНОЙ
ДЕЯТЕЛЬНОСТИ)
– – –
Формы и методы контроля и оценки результатов обучения должны позволять проверять у обучающихся не только сформированность профессиональных компетенций, но и развитие общих компетенций и обеспечивающих их умений.
АВТОНОМНАЯ НЕКОММЕРЧЕСКАЯ ОРГАНИЗАЦИЯ
ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ
ОКТЯБРЬСКИЙ ЭКОНОМИЧЕСКИЙ ТЕХНИКУМ
по производственной практике
ПМ.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 - поддержка жизненного цикла;