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

1.

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

2.

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

3.

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

4.

Какие бывают цели создания программного обеспечения
Программы можно создавать по-разному и с разными целями. Например:
- с учебными целями
Это могут быть программы от простейших (вроде "Hello World") до более сложных. Но при этом цель
разработчика программы - освоить технологию программирования или смежную технологию (например,
алгоритмы вычислений или создание 3D-моделей).
- в режиме хобби
Разработчик создает программу, которая ему чем-либо интересна. При этом у него нет жестких
требований и ограничений. Этой программой могут пользоваться другие люди, даже широкий круг
пользователей - но при этом инициатива в развитии программы исходит от самого разработчика.
-с исследовательскими целями
Это могут быть программы для проверки какой-либо концепции, исследования свойств нового
алгоритма или технологии.
- для решения проблем конечных пользователей
Это может быть:
- коммерческий продукт
- программа для внутренней автоматизации
- некоммерческая программа, разрабатываемая организацией или координируемая
организованным сообществом

5.

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

6.

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

7.

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

8.

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

9.

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

10.

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

11.

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

12.

Анализ требований - технические требования
-технические требования
эти требования определяют особенности технической реализации
функций программы
в т.ч.:
- технические характеристики
например, "программа должна обрабатывать поток данных не менее 50
Мбит/с"
- требования совместимости
например, "программа должна работать под ОС Linux и поддерживать
соединение по протоколу HTTP".

13.

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

14.

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

15.

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

16.

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

17.

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

18.

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

19.

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

20.

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

21.

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

22.

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

23.

плюсы и минусы трехзвенной архитектуры (с тонким клиентом):
+:
- возможна работа многих пользователей с едиными данными и едиными
алгоритмами бизнес-логики
- объемы обрабатываемых данных и сложность вычислений не ограничены
мощностями клиентской машины (сервер БД и сервер приложений могут быть
мощными, а клиентские машины могут иметь слабые аппаратные ресурсы)
- при изменениях как в данных, так и в бизнес-логике нет необходимости в
обновлении программы у пользователей
-:
- работоспособность системы зависит от связи между тремя компонентами
- потребляется сетевой трафик, увеличивается время отклика за счет
взаимодействия по сети

24.

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

25.

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

26.

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

27.

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

28.

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

29.

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