Учебно-методический комплекс дисциплины «Технология программирования» (стр. 2 )

1.7. Тематика самостоятельной работы

№ раздела и темы самостоятельного изучения	Содержание вопросов и заданий для самостоятельного изучения	Сроки выполнения (неделя, месяц, и т. п.)	Количество часов
Раздел 3 , лекции 3-5	Подготовка лабораторных 1-2	4 неделя	2
Раздел 4, лекции 6-8	Подготовка лабораторных 3-4	8 неделя	1
Раздел 4, лекции 6-8	Подготовка лабораторной 5	12 неделя	2
Раздел 3-5, лекции 3-15	Подготовка лабораторной 6	16 неделя	2
		ИТОГО:	7

1.8. Тематика рефератов.

Программой не предусмотрено.

1.9. Тематика курсовых проектов (работ).

Программой не предусмотрено.

1.10. Формы текущего контроля

Формы контроля (тесты, контрольные работы, опрос и т. п.)	Сроки проведения	Раздел, тема
Сдача лабораторных 1-2	4 неделя	Разделы 3, лекции 3-5
Сдача лабораторных 3-4	8 неделя	Раздел 4, лекции 6-8
Сдача лабораторной 5	12 неделя	Раздел 4, лекции 6-8
Сдача лабораторной 6	16 неделя	Раздел 4, лекции 6-8

1.11. Вопросы к экзамену

1. Цикл жизни программного обеспечения (ПО).

2. Показатели качества ПО.

3. Надежность ПО.

4. Критерии надежности ПО. Сбой отказ, восстановление ПО.

5.Перестановки символов, чисел. Операции над перестановками.

6. Обратные перестановки. Циклическая и каноническая формы перестановки.

7. Рекурсия. Примеры применения рекурсии. Программы.

8. Внутренняя и внешняя сортировки данных. Их особенности.

9. Алгоритм сортировки простыми вставками. Код основной части программы.

10. Алгоритм сортировки Хоора. Код основной части программы.

11. Алгоритм сортировки Шелла. Код основной части программы.

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

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

14. Алгоритм последовательного поиска. Код основной части программы.

15. Алгоритм индексно - последовательного поиска. Код основной части

программы.

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

17. Алгоритм хеширования для организации поиска данных.

18. Процедура разрешения коллизий при хешировании. Код основной части

программы.

19. ООП. Изоморфизм. Примеры программ.

20. ООП. Полиморфизм. Примеры использования.

21. ООП. Наследование. Примеры программ.

22. Логическое программирование. Технология программирования на Прологе.

23. Функциональное программирование. Технология программирования на Лиспе.

1.12. Перечень технических средства обеспечения дисциплины

·  Лекционная аудитория, оборудованная мультимедиа;

·  Лаборатория - класс ПК (не менее 1 ПК на 1‑го студента);

1.13. Перечень программных средств для обучения студентов

·  операционная система Windows

·  MS Office

·  Visual Studio 2008 C++

1.14. Учебно-методические обеспечение дисциплины

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

1.   Кнут Искусство программирования. Т. 1. Основные

алгоритмы: Уч. пос. — М.: Издательский дом «Вильямс», 20с. – 5 экз.

2.   Кнут Искусство программирования. Т. 2. Получисленные алгоритмы: Уч. пос. - М.: Издательский дом «Вильямс», 2011.-828 с. – 5 экз.

3.   Алгоритмы на С++. – М.: Издательский дом «Вильямс», 2011.-1056 с. – 3 экз.

4.   С++: методики программирования Шилдта. - М.: Издательский дом «Вильямс», 2009.-480 с. – 5 экз.

5.   С\С++ в задачах и приложениях. СПб.: BHV - СПб,2012.-349 с. – 5 экз.

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

1. , , . Математические основы информатики.

Изд-во: БИНОМ, Лаборатория знаний., 2007. – 328 с.

2. Прохорова программирования. Курс лекций. Учебное пособие.

Йошкар – Ола: МОСУ, 2007. – 178 с.

3. С++. Освой на примерах. – СПб.: БВХ – Петербург, 2006. – 384 с.

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

1. Прохорова программирования. Методические указания. Йошкар-

Ола: МОСУ, 20с.

2. Прохорова программирования. Курс лекций. Учебное пособие.

Йошкар – Ола: МОСУ, 2007. – 178 с.

(на кафедре есть все методические материалы в электронном виде)

Интернет-ресурсы, используемые при изучении дисциплины (сайты).

www. *****

1.15. Методы преподавания ИННОВАЦИОННЫЕ

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

·  Электронная рабочая программа и журнал преподавателя в Интернет.

·  Интернет-система мониторинга НИРС.

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

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

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

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

·  Авторские презентации к лекциям.

Методические рекомендации преподавателю дисциплины

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

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

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

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

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

Методические указания для студентов

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

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

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

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

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

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

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

.

3.  КОНСПЕКТ ЛЕКЦИЙ

2.1. Цикл жизни ПО

Одним из базовых понятий методологии проектирования информационных систем (ИС) является понятие жизненного цикла ее программного обеспечения, что представляет собой непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации. Основным нормативным документом [1], регламентирующим жизненный цикл ПО, является международный стандарт ISO/IEC 12207 (ISO - International Organization of Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике). Он определяет структуру жизненного цикла, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания программного обеспечения. Структура жизненного цикла по стандарту ISO/IEC 12207 базируется на трех группах процессов:

·  основные процессы: приобретение, поставка, разработка, эксплуатация, сопровождение;

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

·  обеспечение качества, верификация, аттестация, оценка, аудит, решение проблем;

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

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

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

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

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

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

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

Начальные этапы разработки ПО

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

·  каскадная модель (70-85 гг.);

·  спиральная модель (86-90 гг.).

В изначально существовавших однородных ИС каждое приложение представляло собой единое целое. Для разработки такого типа приложений применялся каскадный способ. Его основной характеристикой является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем этапе (Рис.2.1.1). Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.

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

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

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

Рис.2.1.1. Каскадная схема разработки ПО

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

Рис. 2.1.2. Реальный процесс разработки ПО по каскадной схеме

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

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

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

Рис. 2.1.3. Спиральная модель жизненного цикла

Общие требования к методологии и проектированию ПО

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

·  пошаговой процедуры, определяющей последовательность технологических операций проектирования (Рис. 2.1.4);

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

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

Рис. 2.1.4. Представление технологической операции проектирования

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

Технология проектирования, разработки и сопровождения ИС должна удовлетворять следующим общим требованиям:

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

·  обеспечивать гарантированное достижение целей разработки ИС с заданным качеством и в установленное время;

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

·  обеспечивать возможность ведения работ по проектированию отдельных подсистем небольшими группами (3-7 человек). Это обусловлено принципами управляемости коллектива и повышения производительности за счет минимизации числа внешних связей;

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

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

·  обеспечивать независимость выполняемых проектных решений от средств реализации ИС (систем управления базами данных (СУБД), операционных систем, языков и систем программирования);

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

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

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

·  стандарт оформления проектной документации;

·  стандарт пользовательского интерфейса.

Стандарт проектирования должен устанавливать:

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

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

·  требования к конфигурации рабочих мест разработчиков, включая настройки операционной системы, настройки CASE-средств, общие настройки проекта;

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

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

·  комплектность, состав и структуру документации на каждой стадии проектирования;

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

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

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

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

Стандарт интерфейса пользователя должен устанавливать:

·  правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления;

·  правила использования клавиатуры и мыши;

·  правила оформления текстов помощи;

·  перечень стандартных сообщений;

·  правила обработки реакции пользователя.

2.2. Качество и надежность программного обеспечения

Показатели качества

Критерии качества программного обеспечения [2] представляют собой измеряемые численные показатели в виде показателей целевой функции, характеризующие степень выполнения программами своего назначения. Принципиальной особенностью требований качества комплекса программ является невозможность выделения единственного критерия качества. В ходе анализа выделяется приоритетный критерий, удовлетворяющий следующим требованиям:

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

·  критерий должен обеспечивать возможность определения затрат, необходимых для достижения его значений, а также степени влияния на показатель качества различных внешних факторов и параметров;

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

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

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

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

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

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

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

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