Конструирование программного обеспечения

Июль 26, 2022

Главная
Информатика
Конструирование программного обеспечения

Содержание

2. Макконел С. Совершенный код. Практическое руководство по разработке программного обеспечения. – 2016. Орлов С.А., Цилькер Б.Я.
3. Конструирование программного обеспечения (software construction) представляет собой процесс детального создания программной системы, который раньше называли программированием.
4. Этапы разработки программного обеспечения
5. основы конструирования; управление конструированием; практические аспекты конструирования. Основные направления конструирования ПО
6. Общая структура предмета
7. Минимизация сложности; Ожидание изменений; Конструирование с возможностью проверки; Стандарты в конструировании. 1. Основы конструирования (Software Construction
8. Информационные технологии – отрасль, заставляющая человеческий разум охватывать диапазон информации от отдельных битов до сотен мегабайт
9. Модуль - это функция, процедура или класс, входящие в программную систему. Состав и функции модулей определяются
10. Прототип – это работающая версия системы, реализующая определенный набор функций. Использование прототипов позволяет демонстрировать заказчику возможности
11. облегчают кодирование (написание программы на алгоритмическом языке), чтение программного кода и его отладку. В коллективе для
12. удобство чтения программного кода. Достигается с помощью целого ряда средств: структурирования, использования мнемонических имен и пр.
13. общие, разрабатываемые специальными организациями, например, ISO, IEEE или Комитетом по стандартизации РФ, стандарты языка (например, java)
14. Модуль это – фрагмент программы, реализующий один или несколько классов, методов или функций. Обычно он состоит
15. Затраты на модульность
16. информационная закрытость; связность; сцепление. Свойства модулей
17. Информационная закрытость модулей
18. Это мера зависимости его частей. Для ее измерения используют понятие силы связности (СС). Типы связности: Функциональная
19. 1.Функционально связанный модуль содержит элементы, участвующие в решении только одной задачи. Например, вычисление синуса угла, определение
20. Это мера взаимодействия модулей по данным и измеряется степенью сцепления ( СЦ). Выделяют 6 типов сцепления
21. Показатели: 1) Длина N ≈ n1 log2 (n1) + n2 log2 (n2) где n1 - число
22. Количество вершин (модулей); Количество связей между вершинами; Высота – количество уровней управления; Ширина – максимальное количество
23. Пример иерархической структуры ПС Высота 4, ширина – 6
24. Коэффициент объединения по входу, Fan_in(i) – количество модулей, которые прямо управляют i–тым; Коэффициент разветвления по выходу,
25. Это один из этапов разработки программного обеспечения. Свойства прототипа Этап создания должен быть коротким. Прототипы являются
26. Определение начальных требований. Разработка первого варианта, который содержит только пользовательский интерфейс системы. Изучение прототипа заказчиком и
27. Быстрое, при котором макет может быть выброшен, главное - скорость; Эволюционное, которое ставит своей целью последовательное
28. Достоинства уменьшение времени, стоимости и рисков; вовлечение пользователя в процесс разработки Недостатки недостаточный анализ, смешение прототипа
29. Это процесс создания модели программного продукта. Модель может быть в виде : Бумажного макета или макета
30. Многократное повторение итераций Макетирование
31. Последовательность этапов макетирования
32. Это свойство текстового материала, характеризующее лёгкость восприятия его человеком. На читабельность программного кода влияют: Стили отступов
33. полезны в следующих случаях. Над проектом работает несколько программистов; Программу будут сопровождать и изменять другие программисты;
34. Существует два вида изменений: Усовершенствование кода программы (рефакторинг); Добавление новой функциональности (реинжениринг). 1.2. Ожидание изменений
35. Это процесс изменения внутренней структуры программы, не затрагивающий ее внешнего поведения и имеющий целью облегчить понимание
36. дублирование кода; длинный метод; большой класс; длинный список параметров; «жадные» функции — метод, который часто обращается
37. Это - процесс создания новой функциональности или устранения ошибок путем глобального изменения, но на основе уже
38. Использует следующие техники: обзор и оценка кода; модульное тестирование; структурирование кода совместно с применениям автоматизированных средств
39. заключается в совместном внимательном чтении исходного кода и высказывании рекомендаций по его улучшению. Считается, что автор
40. процесс, позволяющий проверить корректность отдельных модулей исходного кода программы. Модульное или юнит-тестирование
41. Поиск и документирование несоответствий требованиям Поддержка разработки и рефакторинга низкоуровневой архитектуры системы и межмодульного взаимодействия. Поддержка
42. Государственные (ГОСТ) - ЕСПД; Отраслевые (ОСТ) – стандарты языков (СИ, Java); Стандарты предприятий (СТП); Стандарты проектов
43. 2. Управление конструированием 2.1 Модели конструирования
44. методы, средства и процедуры Принципы разработки ПО
45. обеспечивают решение следующих задач: Планирование и оценка проекта; Анализ системных и программных требований; Проектирование структур данных,
46. обеспечивают автоматизированную или автоматическую поддержку методов. Могут объединяться в системы автоматизированного конструирования ПО. Такие системы называют
47. объединяют методы и средства и обеспечивают непрерывную последовательность разработки. Определяют: Порядок применения методов и утилит; Формирование
48. Каскадная или водопадная; Инкрементная; V-образная; Эволюционная (спиральная); Компонентно-ориентированная. Парадигмы и модели жизненного цикла ПО
49. Каскадная модель жизненного цикла ПО
50. Достоинства - упорядоченный процесс конструирования с четким планом и графиком следования этапов. Недостатки: Требования к проекту
51. Инкрементная модель объединяет достоинства каскадной и методов макетирования.
52. Основным достоинством V-модели является связь разработки программ с их тестированием, валидацией и верификацией. V-образная модель
53. Эволюционная стратегия 1 – начальный сбор требований и планирование проекта; 2 – та же работа на
54. Достоинства : Более точно отображает процесс разработки ПО; Позволяет учитывать риск разработки; Использует моделирование для оценки
55. основана на эволюционной стратегии конструирования и является развитием спиральной. Использует библиотеки. Компонентно-ориентированная модель
56. Уменьшение времени разработки в среднем на 30%; Сокращение стоимости разработки в среднем на 70%; Увеличение производительности
57. Необходимо оценить: людские ресурсы (в человеко-месяцах); продолжительность (в календарных датах); стоимость. Определяется порядок разработки компонентов и
58. организационное управление (Organizational Management), управление процессом и проектом (Process/Project Management), измерения инженерии ПО (Software Engineering Measurement).
59. Задачи : управление персоналом (обучение, мотивация и др.), коммуникации между сотрудниками и средой (сценарии, встречи, презентации
60. составление плана проекта, построение графиков работ (сетевых или временных диаграмм) исходя из имеющихся ресурсов, распределение персонала
61. Позволяют - определить или показать качество продукции; - оценить производительность труда персонала; - оценить выгоды (прибыль
62. Прямые, косвенные. Типы измерений
63. Трудоемкость и емкостная сложность (асимптотическая оценка), Количество строк кода (LOC - lines-of-code), Цикломатическая сложность, Анализ функциональных
64. 3. Практические соображения 3.1. Проектирование в конструировании
65. Структурные - структурное, схемное или текстовое представление структуры ПО из объектов, компонентов, их интерфейсов и связей,
66. Литературная, при которой код пишется как письмо, за столом; Сельскохозяйственная – аналогия с выращиванием растений (каждый
67. 3) Жемчужины – наращивание функциональности как жемчуг в раковине; 4) Строительная – по аналогии со строительством
68. Уровни проектирования программных систем
69. Тяжеловесные – строго и подробно документированные, при которых прогнозируется весь объем работ; Облегченные (подвижные - agile)
70. Быстрая разработка (RAD); Унифицированная разработка (RUP); Экстремальное программирование; Технология Scrum. Технологии разработки приложений
71. применяет инкрементную стратегию конструирования, обеспечивает очень короткий цикл разработки за счет компонентно-ориентированного конструирования. Эффективна, если требования
72. Один из самых известных процессов, использующих итеративную модель разработки. Был разработан компанией Rational Software и стал
73. Разработка требований с помощью прецедентов использования (сценариев); Итеративная разработка с продолжительностью отдельной итерации от 2 до
74. Начало - обычно состоит из одной итерации. Проектирование может занимать 2 – 3 итерации или быть
75. 3) Построение длится от 2 до 4 итераций. При этом происходит разработка окончательного продукта. 4) Внедрение
76. Облегченный процесс, ориентированный на группы малого и среднего размера (до 10 человек), которые разрабатывают системы в
77. Кодирование, Тестирование, Выслушивание заказчика, Проектирование. Основные действия в XP-цикле
78. Используются 12 базовых методов, которые предполагают разработку историй (сценариев) и включение их в очередную итерацию. Каждая
79. Идеальный XP-процесс
80. представляет собой эмпирический подход к разработке программного обеспечения. Основан на повторяющихся циклах. В процессе разработки участвуют
81. Процесс работы над программным продуктом
82. Это короткие ежедневные и циклические 30-дневные встречи. Отбор задач на спринт выполняется с учетом их важности.
83. Конфигурационные, которые задают параметры выполнения программной системы; Инструментальные – языки конструирования из повторно-используемых элементов (script); Языки
84. Важную роль играют Программирование не на языке, а с использованием языка. Опыт программирования на конкретном языке.
85. Практика написания программного кода. техники создания легко понимаемого исходного кода на основе использования соглашений об именовании,
86. 5) обработка ошибочных условий и исключительных ситуаций; 6) документирование кода; 7) тонкая «настройка» кода; 8) рефакторинг.
87. читаемость; лёгкость в поддержке, тестировании, отладке и устранении ошибок, модификации и портировании; экономное использование ресурсов: памяти,
88. Это процесс выполнения программы с намерением найти ошибки. Методологии тестирования: «белого ящика» и «чёрного ящика». 3.4
89. Метод белого ящика
90. Метод черного ящика Тестирование внешних интерфейсов
91. Метод серого ящика
92. Модульное; Интеграционное. Уровни тестирования
93. Схема процесса тестирования
94. Это методология конструирования и проектирования программных систем, заключающаяся в том, что система частично или полностью должна
95. Представление качества в стандарте ISO 9126 3.6 Качество конструирования
96. Внешнее – качество для заказчика (это удобство в использовании, отсутствие ошибок, хорошая производительность и т.п.) Внутреннее
97. Характеристики и атрибуты качества ПО по ISO 9126
98. Это процесс объединения частей в целое. Наиболее распространенные виды интеграции : Объединение модулей в единую программную
99. Это практика разработки программного обеспечения, которая заключается в слиянии рабочих копий в основную ветвь разработки несколько
100. получение исходного кода из репозитория; сборка проекта; выполнение тестов; развертывание готового проекта; отправка отчетов. Задачи службы
101. проблемы интеграции выявляются и исправляются быстро, что обеспечивает минимум затрат; немедленный прогон модульных тестов для свежих
103. Скачать презентацию

Слайд 2

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

2016.
Орлов С.А., Цилькер Б.Я. Технологии разработки программного обеспечения. – 2012
Смирнов А.А. Технологии программирования. – 2011.

Литература

Слайд 3

Конструирование программного обеспечения (software construction) представляет собой процесс детального создания программной

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

Определение

Слайд 4

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

Слайд 5

основы конструирования;
управление конструированием;
практические аспекты конструирования.
Основные направления конструирования ПО

Слайд 6

Общая структура предмета

Слайд 7

Минимизация сложности;
Ожидание изменений;
Конструирование с возможностью проверки;
Стандарты в конструировании.
1. Основы конструирования (Software

Construction Fundamentals)

Слайд 8

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

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

1.1 Минимизация сложности (Minimizing Complexity)

Слайд 9

Модуль - это функция, процедура или класс, входящие в программную систему.

Состав и функции модулей определяются на этапе проектирования системы.

Модульность

Слайд 10

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

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

Прототипирование

Слайд 11

облегчают кодирование (написание программы на алгоритмическом языке), чтение программного кода и

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

Простые алгоритмы

Слайд 12

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

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

Читабельность

Слайд 13

общие, разрабатываемые специальными организациями, например, ISO, IEEE или Комитетом по стандартизации

РФ,
стандарты языка (например, java)
а также стандарты конкретной организации-разработчика программной системы.

Стандарты программирования

Слайд 14

Модуль это – фрагмент программы, реализующий один или несколько классов, методов

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

Модульный принцип разработки ПО

Слайд 15

Затраты на модульность

Слайд 16

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

Слайд 17

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

Слайд 18

Это мера зависимости его частей. Для ее измерения используют понятие силы

связности (СС).
Типы связности:
Функциональная (СС = 10)
Информационная (СС = 9);
Коммуникативная (СС = 7);
Процедурная (СС = 5);
Временная (СС = 3);
Логическая (СС = 1);
По совпадению (СС = 0).

Связность модулей

Слайд 19

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

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

Примеры связанных модулей

Слайд 20

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

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

Сцепление модулей

Слайд 21

Показатели:
1) Длина
N ≈ n1 log2 (n1) + n2 log2 (n2)
где

n1 - число различных операторов модуля,
n2 - число различных операндов.
2) Объем
V = N * log2 (n1 + n2).
3) Цикломатическая сложность:
V(G) = E*N – 2,
где E – количество дуг, а
N – количество вершин в управляющем графе программной системы.

Сложность программной системы

Слайд 22

Количество вершин (модулей);
Количество связей между вершинами;
Высота – количество уровней управления;
Ширина –

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

Характеристики иерархической сложности структуры программной системы

Слайд 23

Пример иерархической структуры ПС
Высота 4, ширина – 6

Слайд 24

Коэффициент объединения по входу, Fan_in(i) – количество модулей, которые прямо управляют

i–тым;
Коэффициент разветвления по выходу, Fan_out(i) - количество модулей, которыми прямо управляет i–тый модуль.
В примере Fan_in(n) = 4, Fan_out(m) = 3.

Локальные характеристики модулей

Слайд 25

Это один из этапов разработки программного обеспечения.
Свойства прототипа
Этап создания должен

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

Прототипирование и макетирование

Слайд 26

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

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

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

Слайд 27

Быстрое, при котором макет может быть выброшен, главное - скорость;
Эволюционное, которое

ставит своей целью последовательное создание макетов системы.

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

Слайд 28

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

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

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

Слайд 29

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

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

Макетирование

Слайд 30

Многократное повторение итераций
Макетирование

Слайд 31

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

Слайд 32

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

кода влияют:
Стили отступов = правила форматирования исходного кода,
Комментарии,
Декомпозиция (разбиение системы на уровни иерархии),
Соглашения об именовании данных.

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

Слайд 33

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

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

Соглашения об именовании

Слайд 34

Существует два вида изменений:
Усовершенствование кода программы (рефакторинг);
Добавление новой функциональности (реинжениринг).
1.2. Ожидание

изменений

Слайд 35

Это процесс изменения внутренней структуры программы, не затрагивающий ее внешнего поведения

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

Рефакторинг

Слайд 36

дублирование кода;
длинный метод;
большой класс;
длинный список параметров;
«жадные» функции — метод, который часто

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

Причины необходимости рефактринга

Слайд 37

Это - процесс создания новой функциональности или устранения ошибок путем глобального

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

Реинжиниринг

Слайд 38

Использует следующие техники:
обзор и оценка кода;
модульное тестирование;
структурирование кода совместно

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

1.3. Конструирование с возможностью проверки

Слайд 39

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

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

Обзор кода

Слайд 40

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

Слайд 41

Поиск и документирование несоответствий требованиям
Поддержка разработки и рефакторинга низкоуровневой архитектуры системы

и межмодульного взаимодействия.
Поддержка рефакторинга модулей
Поддержка устранения дефектов и отладки

Задачи модульного тестирования

Слайд 42

Государственные (ГОСТ) - ЕСПД;
Отраслевые (ОСТ) – стандарты языков (СИ, Java);
Стандарты предприятий

(СТП);
Стандарты проектов – соглашения об оформлении кода и пр. документов.

Стандарты в конструировании

Слайд 43

2. Управление конструированием
2.1 Модели конструирования

Слайд 44

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

Слайд 45

обеспечивают решение следующих задач:
Планирование и оценка проекта;
Анализ системных и программных требований;
Проектирование

структур данных, алгоритмов и программных структур;
Кодирование;
Тестирование;
Сопровождение.

Методы разработки ПО

Слайд 46

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

конструирования ПО. Такие системы называют CASE-системами (Computer Aided Software Engineering).

Средства (утилиты)

Слайд 47

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

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

Процедуры разработки ПО

Слайд 48

Каскадная или водопадная;
Инкрементная;
V-образная;
Эволюционная (спиральная);
Компонентно-ориентированная.
Парадигмы и модели жизненного цикла ПО

Слайд 49

Каскадная модель жизненного цикла ПО

Слайд 50

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

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

Достоинства и недостатки каскадной модели

Слайд 51

Инкрементная модель
объединяет достоинства каскадной и методов макетирования.

Слайд 52

Основным достоинством V-модели является связь разработки программ с их тестированием, валидацией

и верификацией.

V-образная модель

Слайд 53

Эволюционная стратегия
1 – начальный сбор требований и планирование проекта; 2

– та же работа на основе рекомендаций заказчика; 3 – анализ риска на основе начальных требований; 4 - анализ риска на основе рекомендаций заказчика; 5 – переход к комплексной системе; 6 – начальный макет системы; 7 – следующий уровень макета; 8 – сконструированная система; 9 – оценивание заказчиком.

Спиральная модель

Слайд 54

Достоинства :
Более точно отображает процесс разработки ПО;
Позволяет учитывать риск разработки;
Использует моделирование

для оценки характеристик.
Недостатки :
Повышенные требования к заказчику;
Сложность контроля и управления временем разработки.

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

Слайд 55

основана на эволюционной стратегии конструирования и является развитием спиральной. Использует библиотеки.
Компонентно-ориентированная

модель

Слайд 56

Уменьшение времени разработки в среднем на 30%;
Сокращение стоимости разработки в среднем

на 70%;
Увеличение производительности труда в среднем в 1.5 раза.

Достоинства компонентно-ориентированной модели

Слайд 57

Необходимо оценить:
людские ресурсы (в человеко-месяцах);
продолжительность (в календарных датах);
стоимость.
Определяется порядок разработки компонентов

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

2.2 Планирование конструирования

Слайд 58

организационное управление (Organizational Management),
управление процессом и проектом (Process/Project Management),
измерения

инженерии ПО (Software Engineering Measurement).

Управление инженерией ПО

Слайд 59

Задачи :
управление персоналом (обучение, мотивация и др.),
коммуникации между сотрудниками и средой

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

Организационное управление

Слайд 60

составление плана проекта, построение графиков работ (сетевых или временных диаграмм) исходя

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

Управление процессом

Слайд 61

Позволяют
- определить или показать качество продукции;
- оценить производительность труда персонала;
- оценить

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

2.3 Измерения в конструировании

Слайд 62

Прямые,
косвенные.
Типы измерений

Слайд 63

Трудоемкость и емкостная сложность (асимптотическая оценка),
Количество строк кода (LOC - lines-of-code),
Цикломатическая

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

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

Слайд 64

3. Практические соображения
3.1. Проектирование в конструировании

Слайд 65

Структурные - структурное, схемное или текстовое представление структуры ПО из объектов,

компонентов, их интерфейсов и связей,
Поведенческие, отражающие динамический аспект поведения систем и их компонентов.

Нотации проектирования

Слайд 66

Литературная, при которой код пишется как письмо, за столом;
Сельскохозяйственная – аналогия

с выращиванием растений (каждый блок пишется и отлаживается отдельно);

Метафоры (подходы) проектирования

Слайд 67

3) Жемчужины – наращивание функциональности как жемчуг в раковине;
4) Строительная –

по аналогии со строительством зданий, предпочтительная.

Слайд 68

Уровни проектирования программных систем

Слайд 69

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

работ;
Облегченные (подвижные - agile) имеют адаптивную природу, требуют меньшего объема документов, ориентированы на человека и учитывают частые изменения требований к программному продукту.

Процессы разработки программных систем

Слайд 70

Быстрая разработка (RAD);
Унифицированная разработка (RUP);
Экстремальное программирование;
Технология Scrum.
Технологии разработки приложений

Слайд 71

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

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

Быстрая разработка (Rapid Application Development)

Слайд 72

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

компанией Rational Software и стал основной методологией компании IBM.
RUP описывает некоторый абстрактный процесс, на основе которого организация или проектная команда создает специализированный процесс для конкретной системы.

Унифицированная разработка (Rational Unified Process - RUP)

Слайд 73

Разработка требований с помощью прецедентов использования (сценариев);
Итеративная разработка с продолжительностью отдельной

итерации от 2 до 6 недель.

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

Слайд 74

Начало - обычно состоит из одной итерации.
Проектирование может занимать 2 –

3 итерации или быть пропущенным (если используется уже существующая архитектура). На нем создается архитектура системы. Результатом является 20 – 30 % реализованных прецедентов использования.

Жизненный цикл проекта RUP состоит из 4 фаз:

Слайд 75

3) Построение длится от 2 до 4 итераций. При этом происходит

разработка окончательного продукта.
4) Внедрение занимает от 1 до 3 итераций. На этой стадии проводится тестирование системы, тренинги пользователей и развертывание системы на рабочей площадке.

Последние фазы

Слайд 76

Облегченный процесс, ориентированный на группы малого и среднего размера (до 10

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

Экстремальное программирование (eXtreme Programming, XP)

Слайд 77

Кодирование,
Тестирование,
Выслушивание заказчика,
Проектирование.
Основные действия в XP-цикле

Слайд 78

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

их в очередную итерацию. Каждая история реализуется за 2 недели.
Применяется парное программирование (написание и отладка кода двумя программистами).
Широко используется тестирование. Тесты составляются до начала кодирования.

Особенности XP-программирования

Слайд 79

Идеальный XP-процесс

Слайд 80

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

циклах. В процессе разработки участвуют актеры со следующими ролями.
1. Scrum Мастер (Scrum Master) – самая важная роль (организует работу).
2. Владелец продукта (Product Owner) – представитель заказчика.
3. Команда (Team) самоорганизующаяся и самоуправляемая, работает как единое целое, без учета вклада отдельных членов.

Технология Scrum

Слайд 81

Процесс работы над программным продуктом

Слайд 82

Это короткие ежедневные и циклические 30-дневные встречи.
Отбор задач на спринт

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

Спринт

Слайд 83

Конфигурационные, которые задают параметры выполнения программной системы;
Инструментальные – языки конструирования из

повторно-используемых элементов (script);
Языки программирования - C++, Java .

3.2. Языки конструирования программного обеспечения

Слайд 84

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

на конкретном языке.
Программирование с псевдокодом – запись в программе пошагового алгоритма.

Язык программирования

Слайд 85

Практика написания программного кода.
техники создания легко понимаемого исходного кода на

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

3.3 Кодирование

Слайд 86

5) обработка ошибочных условий и исключительных ситуаций;
6) документирование кода;
7) тонкая «настройка»

кода;
8) рефакторинг.

Кодирование

Слайд 87

читаемость;
лёгкость в поддержке, тестировании, отладке и устранении ошибок, модификации и портировании;
экономное

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

Качество исходного кода

Слайд 88

Это процесс выполнения программы с намерением найти ошибки.
Методологии тестирования:
«белого ящика» и
«чёрного

ящика».

3.4 Тестирование в конструировании

Слайд 89

Метод белого ящика

Слайд 90

Метод черного ящика
Тестирование внешних интерфейсов

Слайд 91

Метод серого ящика

Слайд 92

Модульное;
Интеграционное.
Уровни тестирования

Слайд 93

Схема процесса тестирования

Слайд 94

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

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

3.5 Повторное использование

Слайд 95

Представление качества в стандарте ISO 9126
3.6 Качество конструирования

Слайд 96

Внешнее – качество для заказчика (это удобство в использовании, отсутствие ошибок,

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

Виды качества

Слайд 97

Характеристики и атрибуты качества ПО по ISO 9126

Слайд 98

Это процесс объединения частей в целое. Наиболее распространенные виды интеграции

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

3.7 Интеграция

Слайд 99

Это практика разработки программного обеспечения, которая заключается в слиянии рабочих копий

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

Непрерывная интеграция (CI - Continuous Integration)

Слайд 100

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

непрерывной интеграции

Слайд 101

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

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

Преимущества непрерывной интеграции

Конструирование программного обеспечения

Содержание

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

Конструирование программного обеспечения (software construction) представляет собой процесс детального создания программной

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

основы конструирования;управление конструированием;практические аспекты конструирования.Основные направления конструирования ПО

Общая структура предмета

Минимизация сложности;Ожидание изменений;Конструирование с возможностью проверки;Стандарты в конструировании.1. Основы конструирования (Software

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

Модуль - это функция, процедура или класс, входящие в программную систему.

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

облегчают кодирование (написание программы на алгоритмическом языке), чтение программного кода и

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

общие, разрабатываемые специальными организациями, например, ISO, IEEE или Комитетом по стандартизации

Модуль это – фрагмент программы, реализующий один или несколько классов, методов

Затраты на модульность

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

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

Это мера зависимости его частей. Для ее измерения используют понятие силы

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

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

Показатели:1) Длина N ≈ n1 log2 (n1) + n2 log2 (n2)где

Количество вершин (модулей);Количество связей между вершинами;Высота – количество уровней управления;Ширина –

Пример иерархической структуры ПСВысота 4, ширина – 6

Коэффициент объединения по входу, Fan_in(i) – количество модулей, которые прямо управляют

Это один из этапов разработки программного обеспечения.Свойства прототипа Этап создания должен

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

Быстрое, при котором макет может быть выброшен, главное - скорость;Эволюционное, которое

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

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

Многократное повторение итерацийМакетирование

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

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

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

Существует два вида изменений:Усовершенствование кода программы (рефакторинг);Добавление новой функциональности (реинжениринг).1.2. Ожидание

Это процесс изменения внутренней структуры программы, не затрагивающий ее внешнего поведения

дублирование кода;длинный метод;большой класс;длинный список параметров;«жадные» функции — метод, который часто

Это - процесс создания новой функциональности или устранения ошибок путем глобального

Использует следующие техники:обзор и оценка кода; модульное тестирование; структурирование кода совместно

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

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

Поиск и документирование несоответствий требованиямПоддержка разработки и рефакторинга низкоуровневой архитектуры системы

Государственные (ГОСТ) - ЕСПД;Отраслевые (ОСТ) – стандарты языков (СИ, Java);Стандарты предприятий

2. Управление конструированием 2.1 Модели конструирования

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

обеспечивают решение следующих задач:Планирование и оценка проекта;Анализ системных и программных требований;Проектирование