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

МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ КОЛЛЕДЖ ЭЛЕКТРОМЕХАНИКИ И ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ

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

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

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

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

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

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

2017

ОДОБРЕНО Предметной (цикловой) комиссией специальных дисциплин

Составлен в соответствии с Государственными требованиями к минимуму содержания и уровню подготовки выпускника по специальности 09.02.03

Председатель: ________________

Заместитель директора по учебной работе ___________

Автор:

Сборник содержит описание лабораторных и практических работ профессионального модуля «Участие в интеграции программных модулей», раздел 1 «Технология разработки программного обеспечения», раздел 2 «Инструментальные средства разработки программного обеспечения», раздел 3 «Документирование и сертификация». Разработан в соответствии с рабочей программой и предназначен для студентов 3-го и 4-ого курсов специальности «Программирование в компьютерных системах».

Тематика лабораторных и практических занятий охватывает весь курс и включает темы: «Процессы создания программного обеспечения», «Тестирование и отладка ПО», «Интеграция системы», «Коллективная разработка ПО», «Инструментальные средства разработки ПО», «Документирование», «Сертификация программного обеспечения».

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

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

Содержание

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

Практическое занятие №1 Анализ предметной области ПО.        4

Практическое занятие №2 Оформление спецификации требований к ПО.        6

Практическое занятие №3 Проектирование модулей ПО.        12

Практическое занятие №4 Разработка модулей ПО.        14

Лабораторное занятие №1 Визуальное моделирование.        15

Лабораторное занятие №2 Разработка тестов. Автоматическая генерация тестов на основе формального описания.        17

Лабораторное занятие №3 Средства автоматизации тестирования.        19

Лабораторное занятие №4 Тестирование и отладка программы.        20

Лабораторное занятие №5 Оформление документации, сопровождающей процесс верификации и тестирования.        22

Практическое занятие №5 Подходы к проектированию тестов.        24

Практическое занятие №6 Разработка тестов ПО.        27

Практическое занятие №7 Выполнение отладки с помощью инструментария.        28

Лабораторная работа № 6. Интеграция системы.        31

Лабораторная работа № 7. Технические командные роли.        38

Лабораторная работа № 8. Типы совместной деятельности.        42

Лабораторная работа № 9. Разработка программного модуля коллективом разработчиков        45

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

Практическое занятие №1 Обоснованный выбор среды и языка программирования.        46

Практическое занятие №2 Интеграция программных модулей.        47

Практическое занятие №3 Тестирование и отладка ПО.        48

Практическое занятие №4 Создание справочной системы. Создание инсталляционного пакета.        50

Практическое занятие №5 Защита ПО от несанкционированного доступа.        57

Лабораторная работа №1 Криптография. Защита от несанкционированного доступа.        58

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

Практическое занятие №1 Работа с ЕСПД.        60

Практическое занятие №2 Работа со стандартами.        60

Практическое занятие №3 Порядок проведения сертификации информационно-программных средств.        61

Практическое занятие №4 Разработка технологической документации на программное средство.        62

Практическое занятие №5 Разработка эксплуатационной документации на программное средство.        63

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

Практическое занятие №1
Анализ предметной области ПО.

Практическая работа рассчитана на 2 академических часа.

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

Теоретическая часть.

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

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

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

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

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

• диаграммы "сущность-связь" (Entity - Relationship Diagrams);
• определения сущностей;
• уникальные идентификаторы сущностей;
• определения атрибутов сущностей;
• отношения между сущностями;
• супертипы и подтипы.

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

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

Функциональная модель в виде иерархии функций способствует пониманию поведения субъекта моделирования.

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

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

• вариантов использования (use case diagram);
• классов (class diagram);
• кооперации (collaboration diagram);
• последовательности (sequence diagram);
• состояний (statechart diagram);
• деятельности (activity diagram);
• компонентов (component diagram);
• развертывания (deployment diagram).

В качестве примера можно привести диаграмму классов предметной области компьютерной обучающей системы:

Рис. 1 Диаграмма классов обучающей системы.

Задание.

1. Построить диаграмму классов предметной области задачи.
2. Построить диаграмму вариантов использования предметной области задачи.
3. Составить отчет по практической работе.

Отчет по практической работе должен включать:

1. Анализ предметной области задачи.
2. Диаграмму вариантов использования.
3. Диаграмму классов.

Задача: составить список учебной группы, включающей 25 человек. Для каждого учащегося указать дату рождения, год поступления в колледж, курс, группу, оценки каждого года обучения.

Назначение задачи: получить значение определённого критерия и упорядочить список студентов по нему.

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

Практическое занятие №2
Оформление спецификации требований к ПО.

Практическая работа рассчитана на 2 академических часа.

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

Теоретическая часть.

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

Основными вопросами, которые должны рассматривать составитель (-ли) спецификации требований, являются следующие:

• Функциональные возможности.

Каковы предполагаемые функции программного обеспечения?

• Внешние интерфейсы.

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

• Рабочие характеристики.

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

• Атрибуты.

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

• Проектные ограничения, налагаемые на реализацию изделия.

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

Спецификация требований к ПО:

а)        Должна правильно определять все требования к программному обеспечению. Причиной существования какого-либо требования к программному обеспечению может являться характер решаемой задачи или особая характеристика проекта.

б)        Не должна описывать детали разработки или реализации. Они должны быть описаны на этапе разработки проекта.

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

Правильно составленная спецификация требований к ПО должна быть:

а)        Корректной;

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

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

б)        Однозначной;

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

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

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

в)        Полной;

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

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

г)        Непротиворечивой;

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

д)        Упорядоченной по ее значимости и/или устойчивости;

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

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

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

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

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

е)        Проверяемой;

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

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

Примером проверяемого утверждения является следующее:

Выходные данные программы должны вырабатываться в пределах 20 секунд в течение 60 % временного интервала события; и должны вырабатываться в пределах 30 секунд в течение 100 % временного интервала события.

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

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

ж)        Модифицируемой;

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

1) Имела связанную и легкую в использовании структуру с оглавлением, алфавитным указателем и явно выраженными перекрестными ссылками;

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

3) Выражала каждое требование раздельно, не смешивая его с другими требованиями.

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

з)        Отслеживаемой.

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

1. Обратная отслеживаемость (то есть, к предыдущим стадиям разработки).

Зависит от каждого требования, которое в явном виде ссылается на его источник в более ранних документах.

2. Прямая отслеживаемость (то есть, ко всем документы, порождаемым спецификацией требований.

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

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

Задание.

1. Оформить внешнюю спецификацию к задаче.
2. Составить в виде блок-схемы алгоритм  решения задачи.
3. Создать программу решения задачи на любом алгоритмическом языке программирования.
4. Отладить программу.
5. Составить отчет по практической работе.

Отчет по практической работе должен включать:

1. Внешнюю спецификацию.
2. Алгоритм решения задачи.
3. Текст программы на языке программирования.
4. Набор тестов для отладки программы.

Задача: Составить алгоритм и написать программу нахождения экстремального значения и/или его порядкового номера для заданных одномерных массивов (A[N], B[M], где N и M – размер массивов).

Варианты индивидуальных заданий.

1. Определить наименьшую среди сумм , (K=1,.., N) соответствующий номер K.
2. Определить две наибольшие по абсолютной величине разности Ai-Ai-1, где i=2..N, и соответствующие значения индекса i.
3. Определить наибольшее из отношений , где i=1,...,N и соответствующий индекс i.
4. Определить наименьшее и наибольшее значения разности Ai - BN-i+1, где i=1..N, и соответствующий индекс i.
5. Определить наибольшую среди сумм , , (K=1,..,N) и соответствующий номер  K.
6. Определить два наименьших из значений , (K=1,..,M) и соответствующие номера K.
7. Определить наименьшее из значений , (K=1,..,N) и соответствующий номер K.
8. Определить наименьшую среди сумм , , (K=1,..,N) и соответствующий номер  K.
9. Определить наибольшее из произведений , .
10. Определить наибольшее из произведений  и соответствующий номер K.
11. Определить наименьшее среди произведений , (K=1,..,M) и соответствующий номер K.
12.  Определить наименьшую среди сумм  и , (K=1,..,N) и соответствующий номер  K.
13. Определить два наибольших из абсолютных значений ,   , (K=1,..,M) и соответствующие номера K.
14.  Определить наименьшее из значений , (K=1,.., M) и соответствующий номер K.
15.  Определить наибольшее по абсолютной величине из отношений ,(K=1,..,N) и соответствующий номер K.
16.  Определить наименьшее из значений , (i=1,.., N) и соответствующий индекс i.
17. Определить два наибольших из произведений , (K=1,…,N) и соответствующий номер K.
18.  Определить наименьшее из значений , (i=1,.., N) и номер соответствующего индекса i.
19.  Определить наибольшее среди произведений , (K=1,..,M) и соответствующий номер K.
20. Определить наименьшее из значений , , (K=1,..,M) и соответствующий номер K.
21. Определить два наибольших из произведений  , (i=1,.., N) и соответствующие значения индекса i.
22. Определить наименьшее по абсолютной величине из значений    и  , (K=1,..,N) и соответствующие номера K.
23. Определить наибольшее по абсолютной величине из значений      , (K=1,..,N), и соответствующее значение K.
24. Определить два наименьших по абсолютной величине из значений , (K=1,..,M) и соответствующее значение K.
25. Определить наименьшее и наибольшее из произведений , (K=1,..,N)  и соответствующие значения K.

Практическое занятие №3
Проектирование модулей ПО.

Практическая работа рассчитана на 2 академических часа.

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

Задание.

1. Описать этапы проектирования модулей программы.
2. Составить в виде блок-схемы алгоритм  решения задачи.
3. Составить отчет по практической работе.

Отчет по практической работе должен включать:

1. Алгоритм решения задачи.
2. Набор тестов для отладки программы.

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

Варианты индивидуальных заданий.

1. Даны два двумерных массива вещественных элементов. Размер исходных массивов не превосходит 10х10 элементов. Для каждого из массивов указать номера столбцов, содержащих только положительные элементы. Если таковых столбцов в массиве нет, то вывести соответствующее сообщение. Проверку столбца на положительность элементов оформить в виде процедуры с передачей в нее всех элементов текущего столбца.
2. Даны два двумерных массива натуральных элементов. Размер исходных массивов не превосходит 10х10 элементов. Для каждого из массивов указать номера столбцов, содержащих только кратные 5 или 7 элементы. Если таких столбцов в массиве нет, то вывести соответствующее сообщение. Проверку столбца на наличие указанных элементов оформить в виде процедуры с передачей в нее всех элементов текущего столбца.
3. Даны пять одномерных массива вещественных элементов. Размер каждого массива не превосходит 100 элементов. Для каждого из массивов определить, составляют ли его элементы знакочередующуюся последовательность. Если да, то указать порядковый номер такого массива, в противном случае вывести отрицательный ответ. Проверку массива на выполнение условия оформить в виде процедуры с передачей в нее всех элементов рассматриваемого массива.
4. Даны два двумерных массива символьных (буквы русского алфавита) элементов. Размер исходных массивов не превосходит 10х10 элементов. Для каждого из массивов указать номера строк, содержащих элементы только строчных букв, если таких строк нет ни для какого массива, то вывести соответствующее сообщение. Проверку строки на наличие указанных элементов оформить в виде процедуры с передачей в нее всех элементов текущей строки.
5. Даны два двумерных массива вещественных элементов. Размер исходных массивов не превосходит 10х10 элементов. Для каждого из массивов указать количество столбцов, содержащих только не положительные элементы. Если таких столбцов нет ни для одного из массивов, то вывести соответствующее сообщение. Проверку столбца на наличие указанных элементов оформить в виде процедуры с передачей в нее всех элементов текущего столбца.
6. Даны пять одномерных массива вещественных элементов. Размер каждого массива не превосходит 100 элементов. Для каждого из массивов определить, составляют ли его элементы одного знака. Если да, то указать порядковый номер такого массива, в противном случае вывести отрицательный ответ. Проверку массива на выполнение условия оформить в виде процедуры с передачей в нее всех элементов рассматриваемого массива.
7. Даны два двумерных массива целочисленных элементов. Размер исходных массивов не превосходит 10х10 элементов. Для каждого из массивов указать количество строк, содержащих элементы, четность которых чередуется, а вторым в четных строках является нечетный элемент. Если таких строк нет ни для одного из массивов, то вывести соответствующее сообщение. Проверку строки на наличие указанных элементов оформить в виде процедуры с передачей в нее всех элементов текущего столбца.
8. Даны пять одномерных массива символьных (только латинские буквы) элементов. Размер каждого массива не превосходит 100 элементов. Для каждого из массивов определить, чередуются ли в нем буквы строчные и прописные. Если да, то указать порядковый номер такого массива, в противном случае вывести отрицательный ответ. Проверку массива на выполнение условия оформить в виде процедуры с передачей в нее всех элементов рассматриваемого массива.
9. Даны два двумерных массива целочисленных элементов. Размер исходных массивов не превосходит 10х10 элементов. Для каждого из массивов указать количество строк, для которых сумма элементов, стоящих на нечетных местах в строке, является положительным числом. Если таких строк нет ни для одного из массивов, то вывести соответствующее сообщение. Проверку строки на выполнение условия и расчет оформить в виде процедуры с передачей в нее всех элементов текущей строки.
10. Даны два двумерных массива вещественных элементов. Размер исходных массивов не превосходит 10х10 элементов. Для каждого из массивов указать номера столбцов, произведение отрицательных элементов которых является положительным числом. Если таких столбцов нет ни для одного из массивов, то вывести соответствующее сообщение. Проверку столбца на выполнение условия и расчет оформить в виде процедуры с передачей в нее всех элементов текущего столбца.
11. Даны пять одномерных массива символьных (только латинские буквы) элементов. Размер каждого массива не превосходит 100 элементов. Для каждого из массивов определить, расположены ли в нем строчные буквы в алфавитном порядке. Если да, то указать порядковый номер такого массива, в противном случае вывести отрицательный ответ. Проверку массива на выполнение условия оформить в виде процедуры с передачей в нее всех элементов рассматриваемого массива.
12. Даны два двумерных массива целочисленных элементов. Размер исходных массивов не превосходит 10х10 элементов. Для каждого из массивов проверить выполнение условия: все четные строки массива таковы, что суммы их элементов образуют возрастающую последовательность. Вывести соответствующее сообщение. Вычисление суммы элементов массива и проверку последовательности чисел на выполнение условия оформить в виде процедуры с передачей в нее всех необходимых элементов.
13. Даны два двумерных массива вещественных элементов. Размер исходных массивов не превосходит 10х10 элементов. Преобразовать все нечетные строки каждого массива так, чтобы элементы составляли возрастающую по абсолютной величине последовательность. Вывести преобразованные массивы. Упорядочивание элементов оформить в виде процедуры с передачей в нее всех необходимых элементов.
14. Даны два двумерных массива целочисленных элементов. Размер исходных массивов не превосходит 10х10 элементов. Для каждого столбца массивов вычислить суммы и количества элементов, значения которых находятся в заданном диапазоне. Если чисел, удовлетворяющих этому условию нет, то вывести соответствующее сообщение. Вычисление для элементов столбца массива оформить в виде процедуры с передачей в нее всех необходимых элементов.
15. Даны пять одномерных массива символьных (только латинские буквы) элементов. Размер каждого массива не превосходит 100 элементов. Преобразовать все массивы так, чтобы все строчные буквы были расположены по алфавиту. При этом переставлять только строчные буквы, оставив прописные буквы на своих местах. Преобразование каждого массива оформить в виде процедуры с передачей в нее всех необходимых элементов. Если перестановка элементов не потребовалась, то есть исходные массивы удовлетворяют требуемому условию, то вывести соответствующее сообщение.

Практическое занятие №4
Разработка модулей ПО.

Практическая работа рассчитана на 4 академических часа.

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

Задание.

1. Разработать модули программы, спроектированные во время практического занятия №3.
2. Отладить программу с использованием тестов, составленных во время практического занятия №3.
3. Составить отчет по практической работе.

Отчет по практической работе должен включать:

1. Текст программы на языке программирования.
2. Отчёт о тестировании программы.

Лабораторное занятие №1
Визуальное моделирование.

Лабораторная работа рассчитана на 6 академических часов.

Цель работы. Освоить процесс визуального моделирования программы на языках Delphi, C++.

Теоретическая часть.

Среда программирования Delphi предназначена для разработки приложений на языке Object Pascal для ОС Windows.

Среда программирования C++ Builder предназначена для разработки приложений на языке C++ для ОС Windows.

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

Задание.

1. Создать интерфейс программы решения задачи с использованием любой визуальной среды программирования.
2. Отладить программу.
3. Составить отчет по лабораторной работе.

Отчет по лабораторной работе должен включать:

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

Варианты заданий: 

1. Создать приложение, которое состоит из двух форм. Первая форма располагается в центре экрана. Из первой формы вызывается вторая (модальная) форма координаты расположения которой заданы. При попытке закрытия второй формы выдать запрос-подтверждение о необходимости закрытия формы.
2. Создать приложение, состоящее из одной формы. Расположить на форме текстовое поле и кнопку. При изменении размеров формы компоненты должны перемещаться и всегда находиться в видимой области формы. При попытке закрытия формы выдать запрос-подтверждение о необходимости закрытия формы.
3. Создать приложение, состоящее из двух форм. Первая форма должна выполнять роль заставки и всегда находиться поверх других окон. Разместить на первой форме какое-либо изображение и кнопку, при нажатии на которую отображается вторая форма. При попытке закрытия второй формы выдать запрос-подтверждение о необходимости закрытия формы.
4. Создать приложение, которое состоит из одной формы. На форме расположить компонент StringGrid, размер которого задается с помощью двух текстовых полей. Таблицу заполнить случайными целыми числами от –100 до 100. Найти в таблице максимальный по модулю элемент и выделить контрастным цветом все столбцы и все строки, в которых встречается этот элемент.
5. Создать приложение, состоящее из одной формы. Расположить на ней два однострочных редактора и один многострочный. В однострочные редакторы вводятся Фамилия и Телефон клиента (заполнение полей контролируется либо программно, либо по маске). Оба значения объединяются в одну строку и добавляются очередной записью в многострочный редактор.
6. Создать приложение, состоящее из четырех форм. Разместить на главной форме три переключателя, при выборе каждого из которых активизируется соответствующая ему форма. В заголовке каждой формы подсчитывается число открытий данной формы.
7. Создать приложение, состоящее из одной формы, на которой размещено текстовое поле и список. Список заполняется с помощью текстового поля. По окончании заполнения динамически создать набор переключателей, состоящий из тех элементов, которые были занесены в список.

Контрольные вопросы.

1. Что такое спецификация программного обеспечения?

2. Что означает полнота спецификации?

3. Что означает требование точности для спецификации?

4. Как оформляется внешняя спецификация программного обеспечения?

5. Как устанавливаются ограничения на входные данные?

Лабораторное занятие №2
Разработка тестов. Автоматическая генерация тестов на основе формального описания.

Лабораторная работа рассчитана на 4 академических часа.

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

Теоретическая часть.

Практически все программные системы предусматривают интерфейс с оператором. Практически всегда этот интерфейс – графический (GUI – Graphical User’s Interface). Соответственно, актуальна и задача тестирования создаваемого графического интерфейса.

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

Для решения задачи тестирования программ с программным интерфейсом (API – Application Program Interface: вызовы методов или процедур, пересылки сообщений) известны подходы – методы и инструменты – хорошо зарекомендовавшие себя в индустрии создания программного обеспечения. Основа этих подходов следующая: создается формальная спецификация программы, и по этой спецификации генерируются как сами тесты, так и тестовые оракулы – программы, проверяющие правильность поведения тестируемой программы. Спецификации, как набор требований к создаваемой программе, существовали всегда, Ключевым словом здесь является формальная спецификация. Формальная спецификация – это спецификация в форме, допускающей её формальные же преобразования и обработку компьютером. Это позволяет анализировать набор требований с точки зрения их полноты, непротиворечивости и т.п. Для задачи автоматизации тестирования эта формальная запись должна также обеспечивать возможность описания формальной связи между понятиями, используемыми в спецификации, и сущностями языка реализации программы.

Правильность функционирования системы определяется соответствием реального поведения системы эталонному поведению. Для того чтобы качественно определять это соответствие, нужно уметь формализовать эталонное поведение системы. Распространённым способом описания поведения системы является описание с помощью диаграмм UML (Unified Modeling Language). Стандарт UML предлагает использование трех видов диаграмм для описания графического интерфейса системы:

• Диаграммы сценариев использования (Use Case).
• Диаграммы конечных автоматов (State Chart).
• Диаграммы действий (Activity).

С помощью UML/Use Case diagram можно описывать на высоком уровне наборы сценариев использования, поддерживаемых системой. Данный подход имеет ряд преимуществ и недостатков по отношению к другим подходам, но существенным с точки зрения автоматизации генерации тестов является недостаточная формальная строгость описания.

Широко распространено использование UML/State Chart diagram для спецификации поведения системы, и такой подход очень удобен с точки зрения генерации тестов. Но составление спецификации поведения современных систем с помощью конечных автоматов есть очень трудоёмкое занятие, так как число состояний системы очень велико. С ростом функциональности системы спецификация становится всё менее и менее наглядной.

Перечисленные недостатки этих подходов к описанию поведения системы преодолеваются с помощью диаграмм действий (Activity). С одной стороны нотация UML/Activity diagram является более строгой, чем у сценариев использования, а с другой стороны предоставляет более широкие возможности по сравнению с диаграммами конечных автоматов.

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

Для прогона сгенерированных по диаграмме состояний тестов используется инструмент Rational Robot. Из возможностей инструмента в работе мы использовали следующие:

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

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

• Наличие и состояние окон (заголовок, активность, доступность, статус).
• Наличие и состояние таких объектов, как PushButton, CheckBox, RadioButton, List, Tree и др. (текст, доступность, размер).
• Значение буфера обмена.
• Наличие в оперативной памяти запущенных процессов.
• Существование файлов.

Рис. 2 Общая схема генерации и прогона тестов

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

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

Генератор тестов есть программа (script), написанная на языке ‘Rational Rose Scripting language’ (расширение к языку Summit BasicScriptLanguage). В Rational Rose есть встроенный интерпретатор инструкций, написанных на этом языке, посредством которого можно обращаться ко всем объектам модели (диаграммы состояний).

• Спецификация автоматически интерпретируется (тем самым она проверяется и компилируется в набор тестов).
• Если какая-то функциональность системы изменилась, то диаграмму состояний достаточно изменить в соответствующем месте, и затем сгенерировать новый тестовый набор. Фактически, это снимает большую часть проблем, возникающих при организации регрессионного тестирования.
• Гарантия тестового покрытия. Эта гарантия даётся соответствующим алгоритмом обхода графа состояний.

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

Задание.

1. Сформировать диаграмму вариантов использования для задачи лабораторной работы № 1.
2. Сгенерировать набор тестов.
3. Составить отчет по лабораторной работе.

Отчет по лабораторной работе должен включать:

1. Диаграмму вариантов использования.
2. Файл с тестовым набором.

Лабораторное занятие №3
Средства автоматизации тестирования.

Лабораторная работа рассчитана на 2 академических часа.

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

Теоретическая часть.

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

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

В качестве прогонщика тестов мы используем Rational Robot, который выполняет сгенерированные наборы инструкций. В случае удачного выполнения всех инструкций выносится вердикт – тест прошёл. В противном случае, если на каком-то этапе выполнения теста, поведение системы не соответствует требованиям, Robot прекращает его выполнение, вынося соответствующий вердикт – тест не прошёл.

Задание.

1. Выполнить тестовый набор лабораторной работы № 2.
2. Проанализировать отчёт о прохождении тестов.
3. Составить отчет по лабораторной работе.

Отчет по лабораторной работе должен включать:

1. Отчёт о прохождении тестов.
2. Анализ отчёта о прохождении тестов.

Лабораторное занятие №4
Тестирование и отладка программы.

Лабораторная работа рассчитана на 6 академических часов.

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

Теоретические основы. Тестирование – процесс выполнения программы на наборе тестов с целью выявления ошибок.

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

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

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

• ручного тестирования;
• индукции;
• дедукции;
• обратного прослеживания.

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

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

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

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

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

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

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

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

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

Задание.

1. Составить в виде блок-схемы алгоритм  решения задачи.
2. Создать программу решения задачи на любом алгоритмическом языке программирования.
3. Отладить программу.
4. Составить отчет по лабораторной работе.

Отчет по лабораторной работе должен включать:

1. Алгоритм решения задачи.
2. Текст программы на языке программирования.
3. Набор тестов для отладки программы.

Задача: составить список учебной группы, включающей 25 человек. Для каждого учащегося указать дату рождения, год поступления в колледж, курс, группу, оценки каждого года обучения.

Назначение задачи: получить значение определённого критерия и упорядочить список студентов по нему.

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

Лабораторное занятие №5
Оформление документации, сопровождающей процесс верификации и тестирования.

Лабораторная работа рассчитана на 4 академических часа.

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

Теоретические основы. Тестирование – процесс выполнения программы на наборе тестов с целью выявления ошибок.

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

• административное описание дефекта (дата обнаружения, сотрудник, сообщивший о дефекте, номер сборки программы, дата исправления);
• полное описание проблемы;
• действия, предпринятые для воспроизведения проблемы;
• предложенные способы решения проблемы;
• родственные дефекты;
• тяжесть проблемы (например, критическая проблема, «неприятная» или косметическая);
• источник дефекта: выработка требований, проектирование, кодирование или тестирование;
• вид дефекта кодирования: ошибка занижения или завышения на 1, ошибка присваивания, недопустимый индекс массива, неправильный вызов метода и т. д.;
• классы и методы, измененные при исправлении дефекта;
• число строк, затронутых дефектом;
• время, ушедшее на нахождение дефекта;
• время, ушедшее на исправление дефекта.

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

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

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

Задание.

1.        Выполнить тестирование программы, разработанной в лабораторной работе № 4.

2.        Оформить протоколы тестирования.

3.        Оформить отчет по лабораторной работе.

Отчет по лабораторной работе должен включать:

1.        Внешнюю спецификацию.

2.        Набор тестов.

3.        Текст программы на языке программирования.

4.        Протоколы тестирования программы.

Практическое занятие №5
Подходы к проектированию тестов.

Практическая работа рассчитана на 2 академических часа.

Цель работы. Изучить основные подходы к проектированию тестов.

Теоретическая часть.

Рассмотрим два основных подхода к проектированию тестов.

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

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

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

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

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

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

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

Рассмотрим пример тестирования оператора:

if A and В then…

при использовании разных критериев полноты тестирования.

При критерии покрытия условий требовались бы два теста: А = true, В = false и А = false, В = true. Но в этом случае не выполняется then-предложение оператора if.

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

Недостатком критерия покрытия решений/условий является невозможность его применения для выполнения всех результатов всех условий. Часто подобное выполнение имеет место вследствие того, что определенные условия скрыты другими условиями. Например, если условие AND есть ложь, то никакое из последующих условий в выражении не будет выполнено. Аналогично, если условие OR есть истина, то никакое из последующих условий не будет выполнено. Следовательно, критерии покрытия условий и покрытия решений/условий недостаточно чувствительны к ошибкам в логических выражениях.

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

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

Легко видеть, что набор тестов, удовлетворяющий критерию комбинаторного покрытия условий, удовлетворяет также и критериям покрытия решений, покрытия условий и покрытия решений/условий.

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

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

Деление алгоритма на типовые стандартные структуры позволяет минимизировать усилия программиста, затрачиваемые им на тестирование. Запрет на вложенные структуры как раз и объясняется излишними затратами на тестирование. Использование цепочки простых альтернатив с одним действием или структуры ВЫБОР вместо вложенных простых АЛЬТЕРНАТИВ значительно сокращает число тестов!

Задание.

1.        Оформить внешнюю спецификацию.

2.        Составить в виде блок-схемы алгоритм решения задачи.

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

4.        Составить набор тестов и провести тестирование созданной программы с помощью методов «белого ящика» (покрытия операторов, покрытия решений, покрытия условий, комбинаторного покрытия условий).

5.        Оформить отчет по лабораторной работе.

Отчет по лабораторной работе должен включать:

1.        Внешнюю спецификацию.

2.        Алгоритм решения задачи.

3.        Текст программы на языке программирования.

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

Задача. «Нахождение характерных точек функции». Составить алгоритм и написать программу последовательного вычисления значений заданной функции Y(X) до тех пор, пока не будет пройдена некоторая характерная точка графика функции. Значения аргумента X составляют возрастающую последовательность с шагом h. Начальное значение X0 и шаг изменения аргумента h задаются пользователем.

Варианты индивидуальных заданий.

Практическое занятие №6
Разработка тестов ПО.

Практическая работа рассчитана на 2 академических часа.

Цель работы. Получить практические навыки разработки тестов на основе внешней спецификации программы.

Теоретические основы.

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

- эквивалентное разбиение;

- анализ граничных значений;

- анализ причинно-следственных связей;

- предположение об ошибке.

Эквивалентное разбиение.

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

Граничные значения.

Граничные значения - это значения на границах классов эквивалентности входных значений или около них.

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

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

Предположение об ошибке.

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

Задание.

1. На основе внешней спецификации задачи Практического занятия №5 составить набор тестов на основе подхода «чёрного ящика».
2. Провести тестирование программы.
3. Оформить отчет по лабораторной работе.

Отчет по лабораторной работе должен включать:

1.        Внешнюю спецификацию.

2.        Алгоритм решения задачи.

3.        Текст программы на языке программирования.

4.        Набор тестов на основе подхода «чёрного ящика» для отладки программы.

Практическое занятие №7
Выполнение отладки с помощью инструментария.

Практическая работа рассчитана на 4 академических часа.

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

Теоретические основы.

Отладка — это процесс определения и устранения причин ошибок. Этим она отличается от тестирования, направленного на обнаружение ошибок. В некоторых проектах отладка занимает до 50% общего времени разработки. Многие программисты считают отладку самым трудным аспектом программирования.

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

Классический научный подход включает следующие этапы:

1.        Сбор данных при помощи повторяющихся экспериментов.

2.        Формулирование гипотезы, объясняющей релевантные данные.

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

4.        Подтверждение или опровержение гипотезы.

5.        Повторение процесса в случае надобности.

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

1.        Стабилизация ошибки.

2.        Определение источника ошибки.

a.        Сбор данных, приводящих к дефекту.

b.        Анализ собранных данных и формулирование гипотезы, объясняющей дефект.

c.        Определение способа подтверждения или опровержения гипотезы, основанного или на тестировании программы, или на изучении кода.

d.        Подтверждение или опровержение гипотезы при помощи процедуры, определенной в п. 2(c).

3.        Исправление дефекта.

4.        Тестирование исправления.

5.        Поиск похожих ошибок.

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

1. сокращение подозрительной области кода;
2. проверка классов и методов, в которых дефекты обнаруживались ранее;
3. проверка кода, который изменялся недавно.

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

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

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

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

Инструменты отладки значительно облегчают разработку ПО. Найдите их и используйте. Большинство современных сред программирования (Delphi, C++ Builder, Visual Studio и т.д.) включают средства отладки, которые обеспечивают максимально эффективную отладку. Они позволяют:

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

Задание.

1. Составить в виде блок-схемы алгоритм  решения задачи.
2. Создать программу решения задачи на любом алгоритмическом языке программирования.
3. Отладить программу с использованием инструментальных средств.
4. Составить отчет по лабораторной работе.

Отчет по лабораторной работе должен включать:

1. Алгоритм решения задачи.
2. Текст программы на языке программирования.
3. Набор тестов для отладки программы.

Задача: Имеется матрица размера N*M. Определить в какой строке количество положительных элементов наибольшее.

Контрольные вопросы.

1. Что такое тестирование программы?
2. Что такое отладка программы?
3. Какие стадии тестирования выделяют при разработке программного обеспечения?
4. Какие различают подходы в формировании тестовых наборов?
5. В чем суть тестирования методом “покрытия операторов”?
6. В чем суть тестирования методом “покрытия решений”?
7. В чем суть тестирования методом “покрытия условий”?
8. В чем суть тестирования методом “комбинаторного покрытия условий”?

9. В чём суть метода эквивалентных разбиений?
10. В чём суть метода анализа граничных значений?
11. В чём суть метода анализа причинно-следственных связей?

Лабораторная работа № 6.
Интеграция системы.

Лабораторная работа рассчитана на 14 академических часов.

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

Теоретические сведения Термин «интеграция» относится к такой операции в процессе разработки ПО, при которой вы объединяете отдельные программные компоненты в единую систему. В небольших проектах интеграция может занять одно утро и заключаться в объединении горстки классов. В больших — могут потребоваться недели или месяцы, чтобы связать воедино весь набор программ. Независимо от размера задач в них применяются одни и те же принципы.

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

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

Аккуратная интеграция обеспечивает:

• упрощенную диагностику дефектов;
• меньшее число ошибок;
• меньшее количество «лесов»;
• раннее создание первой работающей версии продукта;
• уменьшение общего времени разработки;
• лучшие отношения с заказчиком;
• улучшение морального климата;
• увеличение шансов завершения проекта;
• более надежные оценки графика проекта;
• более аккуратные отчеты о состоянии;
• лучшее качество кода;
• меньшее количество документации.

Интеграция программ выполняется посредством поэтапного или инкрементного подхода.

Поэтапная интеграция состоит из этапов, перечисленных ниже:

1. «Модульная разработка»: проектирование, кодирование, тестирование и отладка каждого класса.
2. «Системная интеграция»: объединение классов в одну огромную систему.
3. «Системная дезинтеграция»: тестирование и отладка всей системы.

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

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

Поэтому поэтапную интеграцию называют еще «интеграцией большого взрыва»

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

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

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

1. Разрабатываете небольшую, функциональную часть системы. Это может быть наименьшая функциональная часть, самая сложная часть, основная часть или их комбинация. Тщательно тестируете и отлаживаете ее. Она послужит скелетом, на котором будут наращиваться мускулы, нервы и кожа, составляющие остальные части системы.
2. Проектируете, кодируете, тестируете и отлаживаете класс.
3. Прикрепляете новый класс к скелету. Тестируете и отлаживаете соединение скелета и нового класса. Убеждаетесь, что эта комбинация работает, прежде чем переходить к добавлению нового класса. Если дело сделано, повторяете процесс, начиная с п. 2.

Инкрементный подход имеет массу преимуществ перед традиционным поэтапным подходом независимо от того, какую инкрементную стратегию вы используете:

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

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

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

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

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

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

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

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

Нисходящая интеграция

При нисходящей интеграции класс на вершине иерархии пишется и интегрируется первым. Вершина иерархии — это главное окно, управляющий цикл приложения, объект, содержащий метод main() в программе на Java, функция WinMain() в программировании для Microsoft Windows или аналогичные. Для работы этого верхнего класса пишутся заглушки. Затем, по мере интеграции классов сверху вниз, классы заглушек заменяются реальными.

Рис.3 Нисходящая интеграция

При нисходящей интеграции вы создаете те классы, которые находятся на вершине иерархии, первыми, а те, что внизу, — последними.

Хорошей альтернативой нисходящей интеграции в чистом виде может стать подход с вертикальным секционированием.

Рис. 4 Вертикальное секционирование

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

Восходящая интеграция

Рис.5 Восходящая интеграция

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

Рис. 6 Гибридный подход при восходящей интеграции

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

Сэндвич-интеграция

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

Рис. 7 Сэндвич-интеграция

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

Напоследок вы оставляете классы среднего уровня.

Риск-ориентированная интеграция

Риск-ориентированную интеграцию, которую также называют «интеграцией, начиная с самых сложных частей» (hard part first integration), похожа на сэндвич-интеграцию тем, что пытается избежать проблем, присущих нисходящей или восходящей интеграциям в чистом виде. Кроме того, в ней также есть тенденция к объединению классов верхнего и нижнего уровней в первую очередь, оставляя классы среднего уровня напоследок. Однако суть в другом.

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

Функционально-ориентированная интеграция

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

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

Рис. 8 Функционально-ориентированная интеграция

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

Т-образная интеграция

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

Рис. 9 Т-образная интеграция

Задание.

1.        Оформить внешнюю спецификацию.

2.        Составить в виде блок-схемы алгоритм решения задачи.

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

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

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

6.        Выполнить системное тестирование программы.

7.        Оформить отчет по лабораторной работе.

Отчет по лабораторной работе должен включать:

1.        Внешнюю спецификацию.

2.        Алгоритм решения задачи.

3.        Текст программы на языке программирования.

4.        Набор тестов для отладки модулей программы.

5.        Описание процесса интеграции модулей.

Задача. Задан двумерный массив размерности n🞨m. Отсортировать элементы строк массива по возрастанию значений, а затем отсортировать строки массива по возрастанию среднего арифметического элементов строк.

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

Контрольные вопросы.

1. Значение фазы интеграции программных модулей.
2. Подходы к интегрированию программных модулей.
3. Эффективность и оптимизация программ.

Лабораторная работа № 7.
Технические командные роли.

Лабораторная работа рассчитана на 6 академических часов.

Цель работы получить практические навыки участия в коллективной разработке, освоив разные технические роли.

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

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

• основной  состав  группы —  специалисты,  полностью  занятые  в  создании  нового программного продукта:

• менеджер проекта;
• программисты;
• тестировщики;
• разработчики документации;
• инженерные психологи;
• технологи по разработке ПО;

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

• группа менеджмента и маркетинга продукта;
• специалисты по технической поддержке ПО;
• администраторы бета-тестирования.

Менеджер проекта

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

Применение следующих принципов способствует повышению эффективности команды разработчиков.

• Гибкое использование ресурсов

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

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

Все ресурсы находятся в руках его менеджера,  а команда в полном составе работает

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

• Централизованное принятие решений

Поскольку  проект  целиком  находится  в  ведении  одного  менеджера,  он  может оперативно  принимать  критически  важные  решения,  разрубая «Гордиевы  узлы»,  когда  не удаётся достичь согласия.

• Более чёткое взаимодействие

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

• Инициативная ответственность

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

Ведущие специалисты

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

Рис. 10 Связи  между менеджером проекта и ведущими специалистами

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

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

• Подбор кадров и управление ими

• Формулирование и исполнение плана проекта

• Руководство командой

• Обеспечение связи между подразделениями

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

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

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

Ведущий разработчик это главный специалист по разработке ПО. В число его обязанностей входит:

• наблюдение за соблюдением архитектурных и технических спецификаций продукта;

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

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

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

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

тестировщиков и технологов;

• мониторинг состояния(ведение списка обнаруженных ошибок);

•  подбор  инструментов  разработки,  метрик  и  стандартов  и  наблюдение  за  их использованием;

• ну и, конечно, программирование, программирование и ещё раз программирование.

Ведущие программисты, отвечающие за реализацию отдельных функций, отвечают за реализацию отдельных функций продукта, часто на основе конкретной технологии. Обычно определение функций формулируют довольно широко, например, «интеграция с IDE» или «разработка API доступа к БД». Обязанностями ведущих программистов, отвечающих за создание отдельных функций ПО, являются:

• согласование архитектурных вопросов с коллегами, ответственными за разработку других функций;

• формулирование требований к функциям и их критический анализ;

• проектирование функций;

• снабжение тестировщиков и разработчиков документации техническими материалами;

• ну и, конечно, программирование, программирование и ещё раз программирование.

В круг обязанностей рядовых программистов входит:

• реализация функции;

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

• исправление ошибок в реализованной функции;

• помощь техническим писателям в документировании реализованной функции;

• помощь тестировщикам в испытаниях этой функции.

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

Ведущий тестировщик отвечает за организацию и исполнение тестирования ПО в период разработки. Его обязанности таковы:

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

• Исполнение плана тестирования

• Автоматизация испытаний

• Проведение регрессивного тестирования

• Выбор инструментов, метрик и стандартов для тестирования

В круг обязанностей рядового тестировщика входит:

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

• проведение автоматизированных испытаний;

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

• окончательное подтверждение устранения ошибки;

• подготовка среды для испытаний.

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

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

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

Специалист по инженерной психологии должен:

• транслировать формулировки требований в ключевые задачи;

• разрабатывать дизайн пользовательского интерфейса (макеты диалоговых окон и т.д.) для решения этих задач;

• тестировать разработанный дизайн и согласовывать его с командой;

• определять, как сформировать положительное первоначальное впечатление от продукта;

• проводить подгонку и доводку пользовательского интерфейса;

• работать с заказчиком после выпуска ПО.

У технолога по созданию ПО три основные обязанности:

• Создание и сопровождение подходящей среды для сборки продукта;

• Создание и сопровождение процедуры установки;

• Сопровождение и администрирование систем управления исходным текстом.

Задание.

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

а)        менеджер проекта;

б)        программист-тестировщик;

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

2.        Оформить отчет по лабораторной работе.

Отчет по лабораторной работе должен включать:

1.        План-график выполнения работ.

2.        Текст программы на языке программирования.

3.        Набор тестов для отладки модулей программы.

4.        Набор программной документации.

5.        Описание работ, выполненных по каждой роли.

Задача 1. Составить список учебной группы, включающей 25 человек. Для каждого учащегося указать дату рождения, год поступления в колледж, курс, группу, оценки каждого года обучения.

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

Задача 2. Составить список книг. Для каждой книги указать: название, автора, год издания, издательство, жанр, оценку популярности.

Достигаемая цель: отсортировать список книг по жанрам и в каждом жанре упорядочить по популярности (по убыванию).

Лабораторная работа № 8.
Типы совместной деятельности.

Лабораторная работа рассчитана на 6 академических часов.

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

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

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

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

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

Парное программирование

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

Формальные инспекции

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

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

В число методик совместной разработки входят так же анализ проекта или кода, чтение кода и презентация.

Анализ проекта или кода

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

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

Чтение кода

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

Презентация

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

Задание.

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

2.        В группах по шесть человек реализовать методику формальной инспекции.

3.        Оформить отчет по лабораторной работе.

Отчет по лабораторной работе должен включать:

1.        Внешнюю спецификацию.

2.        Алгоритм решения задачи.

3.        Текст программы на языке программирования.

4.        Набор тестов для отладки модулей программы.

5.        Описание процесса формальной инспекции.

Задача 1. Задан список участников соревнований по плаванию и их результаты. Все результаты различны. Расположите результаты и фамилии участников в соответствии с занятым местом.

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

Задача 3. Заданное натуральное число М представьте в виде суммы квадратов двух неравных натуральных чисел. В случае если это невозможно, выведите соответствующее сообщение.

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

а) забивших хотя бы два гола;

б) забивавших голы в каждом матче;

в) не забивших ни одного гола.

Лабораторная работа № 9.
Разработка программного модуля коллективом разработчиков

Лабораторная работа рассчитана на 8 академических часов.

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

Задание.

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

а) менеджер проекта;

б) программисты;

в) тестировщики;

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

д) технологи по созданию ПО.

2.        Оформить отчет по лабораторной работе.

Отчет по лабораторной работе должен включать:

1.        Внешнюю спецификацию.

2.        Алгоритм решения задачи.

3.        Текст программы на языке программирования.

4.        Набор тестов для отладки модулей программы.

5.        Набор технической и пользовательской документации.

6.        Описание процесса интеграции модулей.

7.        Описание работ, выполненных по своей роли.

Задача. В файле записаны данные клиентов банка. В первой строке указано число M – количество клиентов. В каждой из следующих M строк записаны: фамилия клиента, дата его рождения, сумма кредита, дата выдачи кредита и количество лет, на которые взят кредит. Определить для каждого клиента дату погашения кредита и результат вывести в файл.

Контрольные вопросы.

1. Что такое спецификация программного обеспечения?
2. Что означает полнота спецификации?
3. Что означает требование точности для спецификации?
4. Что такое тестирование программы?
5. Что такое отладка программы?
6. Какие стадии тестирования выделяют при разработке программного обеспечения?
7. Какие различают подходы в формировании тестовых наборов?
8. В чем суть тестирования методом “покрытия операторов”?
9. В чем суть тестирования методом “покрытия решений”?
10. В чем суть тестирования методом “покрытия условий”?
11. В чем суть тестирования методом “комбинаторного покрытия условий”?
12. В чём суть метода эквивалентных разбиений?
13. В чём суть метода анализа граничных значений?

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

Практическое занятие №1
Обоснованный выбор среды и языка программирования.

Практическая работа рассчитана на 6 академических часов.

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

Теоретическая часть.

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

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

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

Изучая естественные языки, лингвисты Сапир и Уорф (Sapir and Whorf) высказали предположение, что способность к размышлению над определенными идеями связана с выразительной силой языка. Согласно гипотезе Сапира-Уорфа способность человека к обдумыванию определенных мыслей зависит от знания слов, при помощи которых можно выразить эту мысль. Если вы не знаете слов, то не сможете выразить мысль и, возможно, даже сформулировать ее (Whorf, 1956).

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

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

Задание.

1.        Оформить внешнюю спецификацию.

2.        Составить в виде блок-схемы алгоритм решения задачи.

3.        Обосновать выбор среды и языка программирования для решения задачи.

4.        Оформить отчет по лабораторной работе.

Отчет по лабораторной работе должен включать:

1.        Внешнюю спецификацию.

2.        Алгоритм решения задачи.

3.        Обоснование выбора среды и языка программирования.

Варианты заданий:

1. Задан список участников соревнований по плаванию и их результаты. Все результаты различны. Расположите результаты и фамилии участников в соответствии с занятым местом.

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

3. Заданное натуральное число М представьте в виде суммы квадратов двух неравных натуральных чисел. В случае если это невозможно, выведите соответствующее сообщение.

4. Имеется матрица размера N*M. Определить в какой строке количество положительных элементов наибольшее.

Практическое занятие №2
Интеграция программных модулей.

Практическая работа рассчитана на 8 академических часов.

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

Теоретические сведения Термин «интеграция» относится к такой операции в процессе разработки ПО, при которой вы объединяете отдельные программные компоненты в единую систему. В небольших проектах интеграция может занять одно утро и заключаться в объединении горстки классов. В больших — могут потребоваться недели или месяцы, чтобы связать воедино весь набор программ. Независимо от размера задач в них применяются одни и те же принципы.

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

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

Аккуратная интеграция обеспечивает:

• упрощенную диагностику дефектов;
• меньшее число ошибок;
• меньшее количество «лесов»;
• раннее создание первой работающей версии продукта;
• уменьшение общего времени разработки;
• лучшие отношения с заказчиком;
• улучшение морального климата;
• увеличение шансов завершения проекта;
• более надежные оценки графика проекта;
• более аккуратные отчеты о состоянии;
• лучшее качество кода;
• меньшее количество документации.

Задание.

1.        Оформить внешнюю спецификацию.

2.        Составить в виде блок-схемы алгоритм решения задачи.

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

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

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

6.        Выполнить системное тестирование программы.

7.        Оформить отчет по лабораторной работе.

Отчет по лабораторной работе должен включать:

1.        Внешнюю спецификацию.

2.        Алгоритм решения задачи.

3.        Текст программы на языке программирования.

4.        Набор тестов для отладки модулей программы.

5.        Описание процесса интеграции модулей.

Задача 1. На основе сведений об отметках учеников класса в последней четверти:

а) вычислите средние баллы по каждому предмету;

б) определите группу из трех лучших учеников;

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

Задача 2. Известен расход по N видам горючего в каждом из M автохозяйств. Определите для каждого хозяйства вид горючего с наибольшим и с наименьшим расходом.

Практическое занятие №3
Тестирование и отладка ПО.

Практическая работа рассчитана на 6 академических часов.

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

Теоретические основы. Тестирование – процесс выполнения программы на наборе тестов с целью выявления ошибок. Отладка – процесс локализации и исправления ошибок.

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

Задание.

1.        Оформить внешнюю спецификацию.

2.        Составить в виде блок-схемы алгоритм решения задачи.

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

4.        Составить набор тестов и провести тестирование созданной программы с помощью методов «белого ящика» (покрытия операторов, покрытия решений, покрытия условий, комбинаторного покрытия условий).

5.        Составить набор тестов по методу «чёрного ящика».

6.        Оформить отчет по лабораторной работе.

Отчет по лабораторной работе должен включать:

1.        Внешнюю спецификацию.

2.        Алгоритм решения задачи.

3.        Текст программы на языке программирования.

4.        Наборы тестов для отладки программы по методу «белого ящика».

5.         Набор тестов для отладки программы по методу «чёрного ящика».

Задача. «Нахождение характерных точек функции». Составить алгоритм и написать программу последовательного вычисления значений заданной функции Y(X) до тех пор, пока не будет пройдена некоторая характерная точка графика функции. Значения аргумента X составляют возрастающую последовательность с шагом h. Начальное значение X0 и шаг изменения аргумента h задаются пользователем.

Варианты индивидуальных заданий.

Практическое занятие №4
Создание справочной системы. Создание инсталляционного пакета.

Практическая работа рассчитана на 8 академических часов.

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

Теоретическая часть.

Создание справочной системы

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

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

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

Создать справочную систему (HLP-файл) можно при помощи поставляемой вместе с Delphi программы Microsoft Help Workshop. Исходным "материалом" для создания HLP-файла является текст справочной информации, представленный в виде RTF-файла.

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

1. Подготовка справочной информации (создание файла документа справочной информации).

2. Преобразование файла справочной информации в файл справочной системы.

Файл документа справочной информации

Файл документа справочной системы представляет собой RTF-файл определенной структуры. Создать RTF-файл справочной информации можно, например, при помощи Microsoft Word. Сначала нужно набрать текст разделов справки, оформив заголовки разделов одним из стилей Заголовок, например Заголовок1. При этом текст каждого раздела должен находиться на отдельной странице документа (заканчиваться символом "разрыв страницы").

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

Таблица

Сноски, используемые для разметки RTF-файла

Для того чтобы пометить заголовок раздела сноской, нужно установить курсор перед первой буквой заголовка раздела и из меню Вставка выбрать команду Сноска. В открывшемся диалоговом окне Сноски в группе Вставить сноску нужно установить переключатель в положение обычную, а в группе Нумерация — в положение другая. В поле ввода номера сноски следует ввести символ "#" и нажать кнопку ОК.

Рис. 11. Диалоговое окно Сноски

В результате в документ будет вставлена сноска #, и в нижней части окна документа появится окно ввода текста сноски, в котором рядом со значком сноски следует ввести идентификатор помечаемого раздела справки.

В качестве идентификатора можно использовать аббревиатуру заголовка раздела справки или сквозной номер раздела, поставив перед ним, например, буквы Ti (Topic Identifier). Однако лучше, чтобы идентификатор раздела справки начинался с префикса IDH_. В этом случае во время компиляции RTF-файла будет проверена корректность ссылок: компилятор выведет список идентификаторов, которые перечислены в разделе [MAP] файла проекта (см. ниже), но которых нет в RTF-файле.

Рис. 12. Вставка в документ сноски, помечающей заголовок раздела справки

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

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

Создание справочной системы

После того как создан файл справочной информации системы (RTF-файл), можно приступить к созданию справочной системы (HLP-файла). Для этого удобно воспользоваться программой Microsoft Help Workshop, которая поставляется вместе с Delphi и находится в файле Hcw.exe.

Запустить Microsoft Help Workshop можно из Windows или из Delphi, выбрав из меню Tools команду Help Workshop.

Если в меню Tools команды Help Workshop нет, то надо из этого же меню выбрать команду Configure Tools и в открывшемся диалоговом окне Tool Options щелкнуть на кнопке Add. В результате этого откроется диалоговое окно Tool Properties, в поле Title которого надо ввести название программы — Help workshop, а в поле Program — полное (т. е. с указанием пути) имя исполняемого файла программы Microsoft Help Workshop:

C:\Program Files\Borland\Delphi7\Help\Tools\HCW.exe

Для ввода имени файла можно воспользоваться кнопкой Browse.

Для того чтобы приступить к созданию справочной системы, нужно из меню File выбрать команду New, затем в открывшемся диалоговом окне тип создаваемого файла — Help Project. В результате этих действий открывается окно Project File Name. В этом окне сначала надо выбрать папку, где находится программа, для которой создается справочная система, и где уже должен находиться файл документа справочной системы (RTF-файл). Затем в поле Имя файла нужно ввести имя файла проекта справочной системы. После щелчка на кнопке Сохранить открывается окно проекта справочной системы.

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

Для того чтобы добавить в проект файл справочной информации, нужно щелкнуть на кнопке Files и в открывшемся диалоговом окне Topic Files - кнопку Add. В результате откроется стандартное окно Открытие файла, используя которое следует выбрать нужный RTF-файл. В результате этих действий в окне проекта появится раздел [FILES], в котором будет указано имя файла справочной информации. Если справочная информация распределена по нескольким файлам, то операцию добавления файла нужно повторить.

Чтобы задать характеристики главного окна справочной системы, надо в окне проекта нажать кнопку Windows и в поле Create a window named открывшегося окна Create a window, ввести слово main.

В результате щелчка на ОК появляется окно Window Properties, в поле Title bar text вкладки General которого нужно ввести заголовок главного окна создаваемой справочной системы.

Используя вкладку Position диалогового окна Window Properties, можно задать положение и размер окна справочной системы. На вкладке Position находится кнопка Auto-Sizer, при нажатии которой открывается окно Help Window Auto-Sizer, размер и положение которого определяется содержимым полей вкладки Position. При помощи мыши можно менять размер и положение этого окна. После нажатия кнопки ОК координаты и размер окна Help Window Auto-Sizer будут записаны в поля вкладки Position.

Используя вкладку Color, можно задать цвет фона области заголовка раздела справки (Nonscrolling area color) и области текста справки (Topic area color). Для этого надо нажать соответствующую кнопку Change и в стандартном окне Цвет выбрать нужный цвет.

Чтобы программа, использующая справочную систему, могла получить доступ к конкретному разделу справочной информации, нужно определить числовые значения для идентификаторов разделов. Чтобы это сделать, надо в окне проекта справочной системы нажать кнопку Map, в результате чего откроется диалоговое окно Map. В этом окне нужно нажать кнопку Add и в поле Topic ID, открывшегося диалогового окна Add Map Entry, ввести идентификатор раздела справки, а в поле Mapped numeric value — соответствующее идентификатору числовое значение. В поле Comment можно ввести комментарий — название раздела справочной системы, которому соответствует идентификатор.

Компиляция проекта

После того, как будет подготовлен файл проекта, можно выполнить компиляцию, щелкнув на находящейся в окне проекта кнопке Save and Compile. Однако первый раз компиляцию проекта справочной системы лучше выполнить выбором из меню File команды Compile, в результате выполнения которой открывается диалоговое окно Compile a Help File.

В этом окне следует установить флажок Automatically display Help file in WinHelp when done (Автоматически показывать созданную справочную систему по завершении компиляции), а затем нажать кнопку Compile. По завершении компиляции на экране появляется окно с информационным сообщением о результатах компиляции и, если компиляция выполнена успешно, окно созданной справочной системы. Созданный компилятором файл справочной системы (HLP-файл) будет помещен в ту папку, в которой находится файл проекта.

Доступ к справочной информации

Для того чтобы во время работы программы пользователь, нажав клавишу , мог получить справочную информацию, надо чтобы свойство HelpFile главного окна приложения содержало имя файла справочной системы, а свойство HelpContext числовой идентификатор нужного раздела. Вспомните, идентификаторы разделов справочной системы перечислены в разделе [MAP] файла проекта справочной системы.

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

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

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

Можно привести следующие примеры бесплатных программ:

• NSIS (Nullsoft Scriptable Install System)

Домашняя страница: http://nsis.sourceforge.net/

• Inno Setup

Домашняя страница: http://www.jrsoftware.org/

• Excelsior Installer

Домашняя страница: http://installer.excelsior-usa.com/ru/

• WiX Toolset

Домашняя страница: http://wixtoolset.org/

Рассмотрим процесс создания инсталляционного пакета на примере Inno Setup:

Чтобы создать для программы единый установочный файл, запустите Inno Setup, нажмите на кнопку «Файл», «Новый» и запустите Мастер.

Рис. 13 Создание установочного файла

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

Рис. 14 Данные приложения

Далее выберите базовую папку и введите название папки с приложением.

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

Если существует файл лицензии, укажите в следующем окне путь к нему. Также есть возможность создать Readme.txt, написать сообщение либо оставить строки пустыми.

Далее введите такие данные:

• имя установочного файла;
• место для размещения скомпилированного файла;
• ярлык инсталлятора.

В последнем окошке нужно оставить все, как есть, что позволит упростить скрипт инсталлятора.

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

Рис. 15 Файл приложения

Inno Setup поможет сделать полноценный профессиональный инсталлятор, который будет обладать необходимой защитой и рядом обязательных функций.

Задание.

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

2.        Оформить отчет по лабораторной работе.

Отчет по лабораторной работе должен включать:

1.        Описание процесса создания справочной системы.

2.        Описание процесса создания инсталляционного пакета.

Практическое занятие №5
Защита ПО от несанкционированного доступа.

Практическая работа рассчитана на 6 академических часов.

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

Теоретическая часть.

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

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

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

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

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

•  методы и средства организационно-правовой защиты информации;

•  методы и средства инженерно-технической защиты информации;

•  криптографические методы и средства защиты информации;

•  программно-аппаратные методы и средства защиты информации.

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

Идентификация  объекта – одна из функций подсистемы защиты.  Эта функция выполняется в первую очередь, когда объект делает попытку войти в систему.  Если процедура идентификации завершается успешно, данный объект считается законным для данной системы.

Следующий шаг – аутентификация объекта (проверка подлинности объекта). Эта процедура устанавливает,  является ли данный объект именно таким, каким он себя объявляет.

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

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

Простейший метод подтверждения подлинности с использованием пароля основан на сравнении представляемого пользователем пароля РА с исходным значением  РА',  хранящимся в КС (рис.).  Поскольку пароль должен храниться в тайне, он должен шифроваться перед пересылкой по незащищенному каналу. Если значения РА и РА'  совпадают, то пароль РА считается подлинным, а пользователь- законным.

Рис. 16 Схема простой аутентификации с помощью пароля.

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

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

Очевидно, значение F(РA) вычисляется заранее и хранится в виде F'(РA) в идентификационной таблице у получателя(рис. 17).  Подтверждение подлинности состоит из сравнения двух отображений пароля F(РА) и F'(РА) и признания пароля РА, если эти отображения равны.

Рис. 17 Схема аутентификации с помощью пароля и идентификационной таблицы.

Задание.

1.        Оформить внешнюю спецификацию.

2.        Составить в виде блок-схемы алгоритм решения задачи.

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

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

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

6.        Выполнить системное тестирование программы.

7.        Оформить отчет по лабораторной работе.

Отчет по лабораторной работе должен включать:

1.        Внешнюю спецификацию.

2.        Алгоритм решения задачи.

3.        Текст программы на языке программирования.

4.        Набор тестов для отладки модулей программы.

5.        Описание процесса интеграции модулей.

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

Лабораторная работа №1
Криптография. Защита от несанкционированного доступа.

Практическая работа рассчитана на 6 академических часов.

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

Теоретическая часть.

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

Задание.

1.        Оформить внешнюю спецификацию.

2.        Составить в виде блок-схемы алгоритм решения задачи.

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

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

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

6.        Выполнить системное тестирование программы.

7.        Оформить отчет по лабораторной работе.

Отчет по лабораторной работе должен включать:

1.        Внешнюю спецификацию.

2.        Алгоритм решения задачи.

3.        Текст программы на языке программирования.

4.        Набор тестов для отладки модулей программы.

5.        Описание процесса интеграции модулей.

Задача. Задан двумерный массив размерности n🞨m. Отсортировать элементы строк массива по возрастанию значений, а затем отсортировать строки массива по возрастанию среднего арифметического элементов строк.

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

Контрольные вопросы.

1. Как оценивается эффективность алгоритма?

2. Как оценивается эффективность программы?

3. Как выполнить оценивание скорости выполнения алгоритма?

4. Что означает фраза "Алгоритм имеет сложность O(N2)?

5. Как определить сложность алгоритма?

6. Как оценивается сложность рекурсивных алгоритмов?

7. Что такое средний и наихудший случай?

1. Как выполнить проверку правильности вводимых данных при программировании на языке Pascal?

2. Как выполнить проверку правильности вводимых данных при программировании в среде Delphi?

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

4. Что такое защита от несанкционированного доступа?

5. Что такое защита от "отказов" своей программы?

6. Что такое защита программы от влияния чужой программы?

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

Практическое занятие №1
Работа с ЕСПД.

Практическая работа рассчитана на 2 академических часа.

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

Теоретическая часть.

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

Задание.

1.        Оформить внешнюю спецификацию.

2.        Составить в виде блок-схемы алгоритм решения задачи.

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

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

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

6.        Выполнить системное тестирование программы.

7.        Оформить отчет по лабораторной работе.

Отчет по лабораторной работе должен включать:

1.        Внешнюю спецификацию.

2.        Алгоритм решения задачи.

3.        Текст программы на языке программирования.

4.        Набор тестов для отладки модулей программы.

5.        Описание процесса интеграции модулей.

Задача. Задан двумерный массив размерности n🞨m. Отсортировать элементы строк массива по возрастанию значений, а затем отсортировать строки массива по возрастанию среднего арифметического элементов строк.

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

Практическое занятие №2
Работа со стандартами.

Практическая работа рассчитана на 2 академических часа.

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

Теоретическая часть.

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

Задание.

1.        Оформить внешнюю спецификацию.

2.        Составить в виде блок-схемы алгоритм решения задачи.

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

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

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

6.        Выполнить системное тестирование программы.

7.        Оформить отчет по лабораторной работе.

Отчет по лабораторной работе должен включать:

1.        Внешнюю спецификацию.

2.        Алгоритм решения задачи.

3.        Текст программы на языке программирования.

4.        Набор тестов для отладки модулей программы.

5.        Описание процесса интеграции модулей.

Задача. Задан двумерный массив размерности n🞨m. Отсортировать элементы строк массива по возрастанию значений, а затем отсортировать строки массива по возрастанию среднего арифметического элементов строк.

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

Практическое занятие №3
Порядок проведения сертификации информационно-программных средств.

Практическая работа рассчитана на 2 академических часа.

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

Теоретическая часть.

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

Задание.

1.        Оформить внешнюю спецификацию.

2.        Составить в виде блок-схемы алгоритм решения задачи.

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

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

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

6.        Выполнить системное тестирование программы.

7.        Оформить отчет по лабораторной работе.

Отчет по лабораторной работе должен включать:

1.        Внешнюю спецификацию.

2.        Алгоритм решения задачи.

3.        Текст программы на языке программирования.

4.        Набор тестов для отладки модулей программы.

5.        Описание процесса интеграции модулей.

Задача. Задан двумерный массив размерности n🞨m. Отсортировать элементы строк массива по возрастанию значений, а затем отсортировать строки массива по возрастанию среднего арифметического элементов строк.

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

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

Практическая работа рассчитана на 2 академических часа.

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

Теоретическая часть.

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

Задание.

1.        Оформить внешнюю спецификацию.

2.        Составить в виде блок-схемы алгоритм решения задачи.

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

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

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

6.        Выполнить системное тестирование программы.

7.        Оформить отчет по лабораторной работе.

Отчет по лабораторной работе должен включать:

1.        Внешнюю спецификацию.

2.        Алгоритм решения задачи.

3.        Текст программы на языке программирования.

4.        Набор тестов для отладки модулей программы.

5.        Описание процесса интеграции модулей.

Задача. Задан двумерный массив размерности n🞨m. Отсортировать элементы строк массива по возрастанию значений, а затем отсортировать строки массива по возрастанию среднего арифметического элементов строк.

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

Практическое занятие №5
Разработка эксплуатационной документации на программное средство.

Практическая работа рассчитана на 2 академических часа.

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

Теоретическая часть.

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

Задание.

1.        Оформить внешнюю спецификацию.

2.        Составить в виде блок-схемы алгоритм решения задачи.

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

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

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

6.        Выполнить системное тестирование программы.

7.        Оформить отчет по лабораторной работе.

Отчет по лабораторной работе должен включать:

1.        Внешнюю спецификацию.

2.        Алгоритм решения задачи.

3.        Текст программы на языке программирования.

4.        Набор тестов для отладки модулей программы.

5.        Описание процесса интеграции модулей.

Задача. Задан двумерный массив размерности n🞨m. Отсортировать элементы строк массива по возрастанию значений, а затем отсортировать строки массива по возрастанию среднего арифметического элементов строк.

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

Контрольные вопросы.

1. Нормативные документы по стандартизации и виды стандартов.
2. Общие сведения о сертификации информационных систем и их программных средств.
3. Особенности сертификации программного обеспечения.
4. Добровольная и обязательная сертификация.
5. Стандарты в области программного обеспечения.
6. Базовые стандарты административного управления качеством продукции.
7. Стандартизация процессов жизненного цикла ПС.
8. Стандарты, регламентирующие качество ПС.
9. Документация и ее роль в обеспечении качества.
10. Виды программной документации.
11. Техническая документация на ПС.
12. Единая система программной документации (ЕСПД).
13. Перечислите разделы документа «Техническое задание» в соответствии с ГОСТ 34.602-89.
14. Перечислите разделы документа «Руководство пользователя» в соответствии с ЕСПД.
15. Методы и средства разработки технической документации.
16. Автоматизированные средства генерации документации.
17. Три подхода к организации пользовательской документации.