Lektsia_6_lb7

1. РАЗРАБОТКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ПРОГРАММНОЙ СИСТЕМЫ. ПОНЯТИЕ ТЕСТИРОВАНИЯ ПО

2. Диаграммы UML:

• Прецедентов
• Активности (деятельности)
• Последовательности
• Кооперации
• Компонентов
• Классов
• Состояний
• Развёртывания

3. Диаграмма компонентов и особенности ее построения

• Физическая система (physical system) — реально существующий
прототип модели системы.
• Исходным логическим представлением разработки программной
системы могут служить структурные схемы алгоритмов и
процедур, описания интерфейсов и концептуальные схемы баз
данных. Для реализации этой системы необходимо разработать
исходный текст программы на языке программирования. При
этом уже в тексте программы предполагается организация
программного кода, определяемая синтаксисом языка
программирования и предполагающая разбиение исходного кода
на отдельные модули.

4. Диаграмма компонентов и особенности ее построения

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

5. Диаграмма компонентов и особенности ее построения

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

6. Диаграмма компонентов и особенности ее построения

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

7. Интерфейсы

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

8. Зависимости между компонентами

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

9. Зависимости между компонентами

Другим случаем отношения зависимости на диаграмме компонентов является отношение
программного вызова и компиляции между различными видами компонентов. Для рассмотренного
фрагмента диаграммы компонентов наличие подобной зависимости означает, что исполнимый компонент
Control .exe использует или импортирует некоторую функциональность компонентa Library .dll, вызывает
страницу гипертекста Home .html и файл помощи Search .hlp, а исходный текст этого исполнимого
компонентa хранится в файле Control .cpp. При этом характер отдельных видов зависимостей может быть
отмечен дополнительно с помощью текстовых стереотипов.

10. Зависимости между компонентами

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

11. Зависимости между компонентами

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

12. Зависимости между компонентами

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

13. Диаграммы UML:

• Прецедентов
• Активности (деятельности)
• Последовательности
• Кооперации
• Компонентов
• Классов
• Состояний
• Развёртывания

14. Диаграмма развёртывания (1)

Диаграмма развертывания (deployment diagram) - диаграмма, на которой представлены узлы выполнения
программных компонентов реального времени, а также процессов и объектов.
Диаграмма развертывания применяется для представления общей конфигурации и топологии
распределенной программной системы и содержит изображение размещения компонентов по отдельным
узлам системы. Кроме того, диаграмма развертывания показывает наличие физических соединений маршрутов передачи информации между аппаратными устройствами, задействованными в реализации
системы.
Диаграмма развертывания предназначена для визуализации элементов и компонентов программы,
существующих только на этапе ее исполнения (run-time).

15. Диаграмма развёртывания (2)

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

16. Диаграмма развёртывания (3)

17.

Лабораторная работа №7
Задание
1.
В соответствии с требованиями технического задания, разработанного при выполнении
лабораторной работы №3, провести обоснованный выбор средства разработки специального ПО.
Разработать схему общесистемного ПО на подобие схемы, показанной на рис. 13.
2.В соответствии с требованиями технического задания, разработанного при выполнении лабораторной
работы №3, а также проектными решениями, разработанными при выполнении лабораторных работ №4 и
№5, разработать специальное программное обеспечение ПС.
3.Выполнить описание разработанных компонентов приложения в виде табл. 13. Типы компонентов
указать согласно табл. 11. Имена компонентов-файлов привести с указанием расширения.

18.

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

19.

Программное обеспечение ПС. Схема общесистемного ПО

20. Лабораторная работа №7

1 Структурная схема общесистемного программного обеспечения

21.

Лабораторная работа
№7
2 Перечень разработанных компонентов
приложения

22.

Лабораторная работа №7
4.
Построить структурную схему разработанного приложения в виде диаграммы компонентов
UML, выражающую взаимодействие его компонентов с компонентами БД в процессе функционирования
приложения.
5.
Запустить приложение на выполнение. Убедиться в соответствии результатов выполнения
приложения требованиям, установленным в техническом задании. При обнаружении логических
ошибок задокументировать их и устранить.
6.
Представить экранные формы компонентов приложения, в том числе отчетов.
7.
Проанализировать код приложения по критерию сложности. В качестве критерия сложности
использовать:
•число модулей (классов) приложения;
•суммарное число переменных подпрограмм (методов классов), включая их формальные параметры;
•суммарное количество операторов подпрограмм (методов классов);
•глубину вложенности структурных операторов ветвления и повторения;
•глубину наследования классов.
8. Выполнить описание физических элементов ПС в виде табл. 14. Типы элементов указать согласно
табл. 12.
9. Построить диаграмму развертывания UML, выражающую зависимости между узлами ПС и
развернутыми на них компонентами

23.

Лабораторная работа №7
3 Диаграмма компонентов

24. Лабораторная работа №7

4 Экранные формы компонентов приложения

25. Лабораторная работа №7

5 Анализ сложности кода
В результате анализа кода сложности кода были получены следующие результаты
30 функций
84 переменные
53 оператора
Вложенность в 2 оператора
6 Физические элементы программной системы

26. Лабораторная работа №7

7 Диаграмма развертывания

27. Диаграмма объектов (1)

Отражают статический вид системы.
Отображают множество объектов и отношений
между ними в определённый момент времени
(«фотография системы»)
Используется для пояснения и уточнения
диаграмм взаимодействия.

28. Диаграмма объектов (2)

29. Риски и рискообразующие факторы программного проекта

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

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

31. Внутренние факторы риска

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

32. Внешние факторы риска

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

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

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

34. Риски, возникающие на этапе проектирования

1. Сложность архитектуры программного обеспечения
4.
Неоптимальный
выбор
структур
данных
Простота, понятность и единая концептуальная целостность обеспечивают
5. Неоптимальный
выбор
языка программирования
эффективную
реализацию
системы.
2.Необходимо
Неудобный пользовательский
интерфейс факторы: целевая
учитывать следующие
3.платформа;
Неправильнаягибкость
структура базы
данных
языка;
время реализации;
Проблемы, которые могут произойти на этапе проектирования базы
производительность; сопровождение программного
данных:
обеспечения;
область
разрабатываемой
некорректность предметная
схемы базы данных
по отношению
к предметной
области; необходимость в использовании библиотек; опыт
системы;
несоответствие аппаратным ограничениям;
разработчиков.
сложность и неудобная работа с базой данных;
невозможность к поддержке и сопровождению.

35. Риски, возникающие на этапе программирования

1. Не использование актуальных возможностей языка программирования
2. Нечитаемый код
3. Создание программных закладок
Программная закладка – это внесенные в программное обеспечение
функциональные объекты, которые при определенных условиях (входных
данных) инициируют выполнение неописанных в документации функций,
позволяющих
осуществлять
несанкционированные
воздействия
на
информацию.
4. Нерегулярное резервное копирование кода

36. Что такое тестирование

Тестирование программного обеспечения (Software Testing) — проверка
соответствия реальных и ожидаемых результатов поведения программы,
проводимая на конечном наборе тестов, выбранном определённым образом.
Цель тестирования — проверка соответствия ПО предъявляемым
требованиям, обеспечение уверенности в качестве ПО, поиск очевидных
ошибок в программном обеспечении, которые должны быть выявлены до
того, как их обнаружат пользователи программы:
1. Проверка, все ли указанные требования выполнены
2. Создание уверенности в уровне качества объекта тестирования
3. Предотвращение дефектов
4. Обнаружение отказов и дефектов
5. Предоставление заинтересованным лицам достаточной информации, позволяющей им
принять обоснованные решения
6. Снижение уровня риска ненадлежащего качества программного обеспечения

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

Принцип 1 — Тестирование демонстрирует наличие дефектов
(Testing shows presence of defects).
Тестирование только снижает вероятность наличия дефектов, которые
находятся в программном обеспечении, но не гарантирует их отсутствия.
Принцип 2 — Исчерпывающее тестирование невозможно (Exhaustive
testing is impossible).
Полное тестирование с использованием всех входных комбинаций
данных, результатов и предусловий физически невыполнимо
(исключение — тривиальные случаи).
Принцип 3 — Раннее тестирование (Early testing).
Следует начинать тестирование на ранних стадиях жизненного цикла
разработки ПО, чтобы найти дефекты как можно раньше.

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

Принцип 4 — Скопление дефектов (Defects clustering).
Большая часть дефектов находится в ограниченном количестве модулей.
Принцип 5 — Парадокс пестицида (Pesticide paradox).
Если повторять те же тестовые сценарии снова и снова, в какой-то момент этот
набор тестов перестанет выявлять новые дефекты.
Принцип 6 — Тестирование зависит от контекста (Testing is context
depending). Тестирование проводится по-разному в зависимости от контекста.
Например, программное обеспечение, в котором критически важна
безопасность, тестируется иначе, чем новостной портал.
Принцип 7 — Заблуждение об отсутствии ошибок (Absence-of-errors fallacy).
Отсутствие найденных дефектов при тестировании не всегда означает
готовность продукта к релизу. Система должна быть удобна пользователю в
использовании и удовлетворять его ожиданиям и потребностям.

39. Обеспечение качества (QA — Quality Assurance) и контроль качества (QC — Quality Control) 

Обеспечение качества (QA — Quality
Assurance) и контроль качества (QC — Quality
Control)
QC (Quality Control) — Контроль качества продукта — анализ результатов
тестирования и качества новых версий выпускаемого продукта.
К задачам контроля качества относятся:
•проверка готовности ПО к релизу;
•проверка соответствия требований и качества данного проекта.

40. Обеспечение качества (QA — Quality Assurance) и контроль качества (QC — Quality Control) 

Обеспечение качества (QA — Quality
Assurance) и контроль качества (QC — Quality
Control)
QA (Quality Assurance) — Обеспечение качества продукта — изучение
возможностей по изменению и улучшению процесса разработки, улучшению
коммуникаций в команде, где тестирование является только одним из аспектов
обеспечения качества.
К задачам обеспечения качества относятся:
•проверка технических характеристик и требований к ПО;
•оценка рисков;
•планирование задач для улучшения качества продукции;
•подготовка документации, тестового окружения и данных;
•тестирование;
•анализ результатов тестирования, а также составление отчетов и других
документов.

41. Этапы тестирования:

1. Анализ продукта
2. Работа с требованиями
3. Разработка стратегии тестирования и планирование процедур контроля
качества
4. Создание тестовой документации
5. Тестирование прототипа
6. Основное тестирование
7. Стабилизация
8. Эксплуатация

42. Стадии разработки ПО 

Стадии разработки ПО
Стадии разработки ПО — этапы, которые проходят команды разработчиков
ПО, прежде чем программа станет доступной для широкого круга
пользователей.
Программный продукт проходит следующие стадии:
1.анализ требований к проекту;
2.проектирование;
3.реализация;
4.тестирование продукта;
5.внедрение и поддержка.