Лекции_по_разделу_1_Основные_понятия_и_стандартизация_требований (2)

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

Преподаватель: Синтяй Юлия
Александровна, каф. ПИТиП

2. Содержание

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

3.

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

4. 1.1 Анализ предметной области. Основные понятия

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

5. Анализ предметной области. Основные понятия

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

6. Анализ предметной области. Основные понятия

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

7. Анализ предметной области. Основные понятия

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

8. Анализ предметной области. Основные понятия

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

9. Анализ предметной области. Основные понятия

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

10. Анализ предметной области. Основные понятия

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

11. 1.2 Требования к программному обеспечению. Классификация требований

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

12. Требования к программному обеспечению. Классификация требований

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

13. Требования к программному обеспечению. Классификация требований

Требован
ия
• Функциональные
• Нефункциональн
ые

14. Требования к программному обеспечению. Классификация требований

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

15. Требования к программному обеспечению. Классификация требований

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

16. Требования к программному обеспечению. Классификация требований

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

17. Требования к программному обеспечению. Классификация требований

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

18. Требования к программному обеспечению. Классификация требований

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

19. 1.3 Стандарты, регламентирующие работу с требованиями

Техническое задание – документ,
содержащий описание целей разработки
и требований к программному продукту
К стандартам, регламентирующим разработку
требований к программному обеспечению,
относят ГОСТ 34.602–89 «Информационная
технология (ИТ). Комплекс стандартов на
автоматизированные системы. Техническое
задание на создание автоматизированной
системы», был принят 24.03.1989 и начал
действовать с 01.01.1990.
Последняя редакция датируется 01 июня 2009,
а с начала 2022 его применение в качестве
национального стандарта РФ прекращено.
Взамен ему пришел ему пришел документ с
аналогичным названием и похожим номером –
ГОСТ 34.602-2020 «Информационные
технологии (ИТ). Комплекс стандартов на
автоматизированные системы. Техническое
задание на создание автоматизированной
системы».
Аналогично своему предшественнику, ГОСТ
34.602-2020 также ссылается на стандарт
19.201-78, который устанавливает порядок
построения и оформления ТЗ на разработку ПО.

20. Стандарты, регламентирующие работу с требованиями

ТЗ является основным документом, определяющим
требования и порядок создания, развития или
модернизации информационной системы. В
соответствии с данным стандартом проводится
разработка систем и ввод их в эксплуатацию.
Стандарт 34.602-2020 отмечает следующие 10
обязательных разделов в ТЗ:
• общие сведения;
• цели и назначение создания автоматизированной
системы;
• характеристика объектов автоматизации;
• требования к автоматизированной системе;
• состав и содержание работ по созданию
автоматизированной системы;
• порядок разработки автоматизированной
системы;
• порядок контроля и приемки
автоматизированной системы;
• требования к составу и содержанию работ по
подготовке объекта автоматизации к вводу
автоматизированной системы в действие;
• требования к документированию;
• источники разработки.

21. Стандарты, регламентирующие работу с требованиями

Подразделы и ключевое содержимое
Примечания и примеры
Раздел «Общие сведения»
· полное наименование АС и ее
Примеры документов, документам, на основании которых
условное обозначение
создается АС:
· шифр темы (при наличии);
· договорные документы;
· наименование организации —
· нормативное правовые и технические документы
заказчика АС и организации-разработчика,
· ТЗ на ранее разрабатывавшуюся АС
если это известно;
· перечень документов, на основании
которых создается АС, кем и когда
утверждены эти документы;
· общие сведения об источниках и
порядке финансирования работ
Раздел «Цели и назначение создания АС»
· наименования и требуемые значения технических,
цели создания АС
технологических, производственно-экономических и пр.
показателей объекта автоматизации, которые должны быть
достигнуты в результате создания АС
· критерии оценки достижения целей создания АС
· вид автоматизируемой деятельности (управление,
назначение АС
проектирование и пр.) относительно объекта автоматизации в
целом. Для сложного объекта автоматизации приводится
перечень объектов, где будет использоваться АС

22. Стандарты, регламентирующие работу с требованиями

Раздел «Характеристика объекта автоматизации»
· основные сведения об объекте
основные сведения об объекте автоматизации, чтобы
автоматизации или ссылки на документы с
однозначно его идентифицировать и сформировать представление о
этими сведениями;
масштабах разработки
· сведения об условиях эксплуатации
объекта автоматизации и характеристиках
окружающей
среды
Раздел «Требования к автоматизированной системе»
требования к структуре АС в целом
· перечень подсистем, их назначение и основные характеристики,
требования к числу уровней иерархии и степени централизации АС
· требования к способам и средствам обеспечения информационного
взаимодействия компонентов АС
· требования к интеграции (характеристикам взаимосвязей) со
смежными АС, требования к совместимости, включая способы обмена
информацией
· требования к режимам функционирования АС
· требования по диагностированию АС
· перспективы развития и модернизации
требования к функциям (задачам) АС
Для каждой функции (задачи) указываются результаты ее выполнения
и их основные характеристики. Дополнительно можно указать:
· временной регламент реализации
· требования к реализации
· требования к форме представления выходной информации
· характеристики точности и времени выполнения, одновременности
выполнения группы функций,
· требования к достоверности выдачи результатов
· перечень и критерии отказов для функций, где указаны требования
по надежности

23. Стандарты, регламентирующие работу с требованиями

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

24. Стандарты, регламентирующие работу с требованиями

Раздел «Порядок разработки автоматизированной системы»
· порядок организации разработки АС;
· перечень документов и исходных
данных для разработки АС;
· перечень документов, предъявляемых
по окончании соответствующих этапов работ;
· порядок проведения экспертизы
технической документации;
· перечень макетов, порядок их
разработки, изготовления, испытаний,
необходимость разработки на них
документации, программы и методик
испытаний;
· порядок разработки, согласования и
утверждения плана совместных работ по
разработке АС;
· порядок разработки, согласования и
утверждения программы работ по
стандартизации;
· требования к гарантийным
обязательствам разработчика;
· порядок проведения техникоэкономической оценки разработки АС;
· порядок разработки, согласования и
утверждения программы метрологического
обеспечения,
программы обеспечения надежности,
программы эргономического обеспечения

25. Стандарты, регламентирующие работу с требованиями

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

26. Стандарты, регламентирующие работу с требованиями

Раздел «Требования к документированию»
· перечень подлежащих разработке
Например, Руководство пользователя, Техническая
документов;
инструкция по ГОСТам серии 34. При отсутствии соответствующих
· вид представления и количество
ГОСТов, определяющих требования к документированию
документов;
элементов АС, сюда включают требования к составу и
· требования по использованию ЕСКД и
содержанию таких документов
ЕСПД при разработке документов.
Раздел «Источники разработки»
документы и информационные
материалы (ТЭО, отчеты о законченных НИР,
материалы на системы-аналоги и пр.)

27. Стандарты, регламентирующие работу с требованиями

28. Стандарты, регламентирующие работу с требованиями

Чем ГОСТ 34.602-2020 отличается от 34.602-89
меньше ссылок на другие стандарты — ГОСТ 34.602-2020 ссылается лишь
на стандарт 19.201-78, который устанавливает порядок построения и
оформления ТЗ на разработку ПО.
перечислены характеристики требований – в разделе «Общие
положения» ГОСТ 34.602-2020 отмечает некоторые критерии «хорошего
требования» (единичность, непротиворечивость, актуальность, выполнимость,
проверяемость, однозначность, максимальная детализация).
уточнение порядка согласования и утверждения изменений в виде
дополнения ТЗ на АС
согласования и утверждения самого исходного документа технического
задания.
введен новый обязательный раздел — в ГОСТ 34.602-2020 добавлен
раздел, регламентирующий порядок разработки автоматизированной системы
недопустимо исключение обязательных разделов — при отсутствий
требований по обязательному разделу, в структуре документа ТЗ он все равно
сохраняется, и в нем делается соответствующая запись, например,
«Требования не предъявляются».
в раздел «Требования к автоматизированной системе» добавлен новый
подраздел «Общие технические требования к АС», где перечисляются
требования к численности и квалификации персонала и пользователей АС, к
показателям назначения, надежности, безопасности и прочие
нефункциональные требования, которые описывают качество и условия
эксплуатации автоматизированной системы. В ГОСТ 34.602-89 эти требования
также перечислялись, но в составе других подразделов.
изменены структура и содержание некоторых подразделов – частично
изменен набор требований к отдельным видам обеспечения
(информационному, лингвистическому, программному, метрологическому,
организационному и методическому).

29. 1.4 Современные принципы и методы разработки приложений

Система может быть развернута в двух вариантах:
файл-серверном и клиент-серверном.
• Файл-серверный вариант рассчитан на работу
небольшого числа пользователей в локальной
сети. Клиент обращается к серверу с
файловыми командами, а механизм
управления всеми информационными
ресурсами находится на компьютере клиента
(рабочей станции).
• Клиент-серверный вариант (архитектура
«клиент–сервер») предполагает работу с
большими объемами информации и большим
числом пользователей, что требует наличия
выделенных серверов баз данных,
принимающих запросы и выполняющих
обработку данных. Как правило, на сервере
баз данных нет клиентских программ и сервер
используется только для хранения данных,
управления данными и обработки запросов.

30. Современные принципы и методы разработки приложений

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

31. Современные принципы и методы разработки приложений

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

32. Современные принципы и методы разработки приложений

Web-клиент
«Тонкий» клиент позволяет работать с
системой через Интернет, для этого
используется web-сервер, настроенный
для работы с системой
Web-клиент, в отличие от «толстого» и «тонкого» клиентов, не
требует какой-либо предварительной установки на компьютер. Он
выполняется не в среде операционной системы компьютера, а в среде
web-браузера.
У web-клиента нет исполняемого файла. Любому пользователю
достаточно всего лишь запустить свой браузер и ввести адрес webсервера, на котором опубликована информационная система

33. Современные принципы и методы разработки приложений

Структура типового приложения включает следующие
части:
• презентационная логика (presentation logic) –
обеспечивает ввод и отображение данных;
• бизнес-логика (business logic) – обеспечивает
выполнение прикладных функций, определяющих
основные алгоритмы решения задач приложения;
Бизнес-логика, или логика приложений, – часть кода
приложения, которая определяет собственно
алгоритмы решения конкретных задач приложения
• логика обработки данных (database logic) –
обеспечивает выполнение функций обработки
данных внутри приложения;
часть кода приложения, которая связана с обработкой
данных внутри приложения; для обеспечения доступа
к данным используются язык запросов и средства
манипулирования данными стандартного языка SQL
• процессор управления данными (database
manager system) – обеспечивает выполнение
функций управления информационными
ресурсами.
Эти задачи могут быть поразному распределены между
серверным
и
клиентским
процессами.

34. Современные принципы и методы разработки приложений

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

35. Современные принципы и методы разработки приложений

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

36. Современные принципы и методы разработки приложений

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

37. Современные принципы и методы разработки приложений

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

38. Современные принципы и методы разработки приложений

• Кластеры высокой доступности НА (high-availability cluster)
Применяются для критических серверных приложений
ПО для НА-кластеров обычно заблаговременно конфигурирует узел на
резервном сервере и запускает на нем приложение в фоновом режиме
так, чтобы основной экземпляр приложения мог немедленно
переключиться на свою реплику на резервном компьютере при отказе
основного.
НА-кластеры обычно используются для терминальных серверов, серверов
баз данных, почтовых серверов.
Технология кластера высокой доступности НЕ может служить
заменой резервному копированию.

39. Современные принципы и методы разработки приложений

• Кластеры с балансировкой нагрузки
Балансировка нагрузки – это эффективное распределение входящего сетевого
трафика в группе (кластере) серверов.
Балансировщик нагрузки выполняет следующие функции:
• Распределяет запросы клиентов и нагрузку сети эффективным образом во всем
кластере серверов;
• Обеспечивает высокую доступность и надежность посылкой запросов только на
те серверы, которые находятся в режиме онлайн;
• Обеспечивает гибкость, добавляя или удаляя серверы по мере надобности.
Применение: ЦОД, комплексы для
ERP/CRM-систем, сервисы биллинга в
телекоммуникационных системах.
Преимущества: масштабируемость,
возможность использования недорогих
серверов стандартной архитектуры.

40. Современные принципы и методы разработки приложений

• Вычислительный кластер / High-Performance Computing cluster
Кластер построен на основе нескольких серверов, объединенных
высокоскоростными линиями передач и специальным ПО. На выходе
образуется единая система для комплексных вычислений. Каждый сервер в
таком кластере обрабатывает задачу, которая автоматически выделяется ему
из общего объема работы.
Применение: аналитика, сбор и обработка данных для Big Data, системы
искусственного интеллекта, нейронные сети.
Преимущества: высокая производительность в ресурсоемких задачах,
выполнение параллельных вычислений.

41. Методы организации работы в команде разработчиков

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

42. Методы организации работы в команде разработчиков

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

43. Методы организации работы в команде разработчиков

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

44. Методы организации работы в команде разработчиков

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

45. Системы контроля версий

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

46. Системы контроля версий

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

47. Системы контроля версий

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

48. Системы контроля версий

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

49. Системы контроля версий

В настоящее время существует довольно большое число СКВ с различными
возможностями: Git – распределенная СКВ, выпущенная в 2005 г.; CVS (система
одновременных версий), централизованная СКВ; Apache Subversion (SVN);
Mercurial, распределенная СКВ, была выпущена одновременно с Git и др.

50. Основные подходы к интегрированию программных модулей

Интеграция – это не просто
объединение модулей.
Интеграция может производиться на
уровне баз данных, программноаппаратных средств и сетевых устройств,
пользовательских интерфейсов, форм и
шаблонов, программных приложений и
т.д.
XML (eXtensible Markup Language) является одним из самых распространенных
и универсальных методов взаимодействия различных систем.
XML может использоваться и для хранения структурированных данных, и для
обмена данными в сложных информационных системах с большим числом
приложений, связанных потоками информации самой различной структуры. В этом
случае XML-документы выполняют роль универсального формата для обмена
информацией между отдельными компонентами большой программы
Язык XML – расширяемый язык разметки данных, но не каких-то конкретных
данных, а любых структурированных данных, которые можно представить в
текстовом виде

51. Основные подходы к интегрированию программных модулей

Сервис-ориентированная
архитектура (Service-Oriented
Architecture – SOA) представляет собой
модульный подход к разработке
программного обеспечения, основанный
на использовании сервисов со
стандартизированными интерфейсами,
называемых web-сервисами или webслужбами.
На принципах сервис-ориентированной архитектуры базируется
интегрированная сервисная шина предприятия (Enterprise Service Bus – ESB). Это
программное обеспечение, являющееся промежуточным связующим звеном,
которое обеспечивает обмен сообщениями между разными программными
системами.
ESB определяет общий регламент публикации сервисов, управления
системами, обмена информацией между приложениями различных систем,
входящих в состав интегрированной системы. Это упрощает управление
программным обеспечением, организует их поддержку, снижает риск
фрагментации процессов.

52. Основные подходы к интегрированию программных модулей

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

53. Основные подходы к интегрированию программных модулей

Common Language Runtime
(CLR) – компонент пакета .NET
Framework, который
обеспечивает среду выполнения
.NET-приложений. Программа
для .NET Framework, написанная
на любом поддерживаемом
языке программирования,
сначала переводится
компилятором в единый для .NET
промежуточный байт-код
Common Intermediate Language
(CIL). JIT-компилятор (Just-in-time
compilation) преобразует
промежуточный байт-код в
машинные коды нужного
процессора

54. Основные подходы к интегрированию программных модулей

Над уровнем CLR
располагаются базовые классы
платформы, на следующем уровне
находятся слой классов данных и
XML, а также слой классов для
создания web-служб, webприложений и Windowsприложений.
Эти классы объединяются под
общим именем FCL (Framework
Class Library) – библиотека классов.
Она открывает доступ к системным
функциям, к прикладным
функциям для web-разработки
(ASP.NET), доступа к данным
(ADO.NET), обеспечения
безопасности и удаленного
управления.
Библиотека классов применяется для разработки
приложений, начиная с обычных приложений,
запускаемых из командной строки, и приложений с
графическим интерфейсом пользователя (GUI) и
заканчивая приложениями, использующими
последние технологические возможности

55. Основные подходы к интегрированию программных модулей

Технология ASP.NET (Active Server Pages
.NET) является платформой для создания webприложений и web-сервисов, работающих под
управлением IIS (Internet Information Services).
IIS – набор серверов для нескольких служб
Интернета от компании Microsoft. ASP.NET
отличается от других технологий создания
web-приложений высокой степенью
интеграции с серверными продуктами
Базовые языки программирования,
являются полностью объектноориентированными, что делает разработку,
модификацию, обслуживание, отладку и
повторное использование модулей гораздо
более простыми

56. Основные подходы к интегрированию программных модулей

LINQ (Language Integrated Query) –
название набора технологий, основанных
на интеграции возможностей запроса
непосредственно в язык C# (а также в
Visual Basic или другие языки .NET).
Благодаря LINQ запрос является одним из
основных структурных элементов языка,
подобно классам, методам, событиям и
т.д. Встроенную в язык часть LINQ
называют выражением запросов.
Выражения запросов можно
использовать для запроса и
преобразования данных, полученных из
любого источника данных,
поддерживающего LINQ

57. Основные подходы к интегрированию программных модулей

XAML (eXtensible Application
Markup Language) – расширяемый
язык разметки для приложений,
основанный на XML, для
декларативного программирования
приложений. XAML широко
используется в .NET Framework.
Его набор свойств, методов и
событий позволяет объединить
веб-документы в связанное
приложение. Документы
приложения пишутся на XAML.
XAML может использоваться как
для браузер-базированных
приложений, так и для настольных
приложений.

58. Стандарты кодирования

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

59. Стандарты кодирования

Стандарты кодирования
camelCasing – это соглашение об
именовании в компьютерном
программировании, при котором
несколько слов объединяются вместе,
образуя единое имя, причем первое слово
пишется строчными буквами, а первая
буква каждого последующего слова –
заглавной
camelCasing используется в таких языках
программирования, как C # и Java, для
присвоения имен идентификаторам,
таким как переменные, методы и
параметры
• Например, «myVariableName»,
«myMethodName» и «MyParameter» все это примеры идентификаторов,
написанных в camelCasing.

60. Стандарты кодирования

Стандарты кодирования
Нотация Паскаля. Тот же
camelCase, но все слова, даже
первое, начинаются с заглавной
буквы. В таком стиле часто
именуют классы (в Java, Python,
JavaScript), а в программной
платформе .NET — ещё и
переменные.
Pascal case стал известным
благодаря одному почти
забытому языку Паскаль — в нём
так именовались переменные,
процедуры и функции.

61. Стандарты кодирования

Стандарты кодирования С#
• Для имени класса необходимо
использовать регистр Pascal.
• Необходимо использовать
регистр Pascal для имени
метода
• Используйте регистр Pascal для
конструктора, перечисления и
констант.
• Необходимо использовать
регистр Camel для переменных
и параметров метода.
• Используйте регистр Camel
для имен файлов.
public class ClassName
{
//Your code here
}
void MethodName(string name)
{
//Your code here
}
int totalCount = 0;
void
MethodName(string parameterName)
{
string fullMessage = "Hello "
+ name;
}

62. Стандарты кодирования

Стандарты кодирования С#
• Необходимо использовать
осмысленное и описательное имя
для объявления переменной,
также не должно быть
сокращением.
• Избегайте использования
переменных с именем из одного
символа, учитывая исключение
переменных инициализатора,
используемых в циклах for, while,
do while.
• Избегайте использования символа
подчеркивания для имен
локальных переменных.
string name, address, contact;
decimal salary;
int age;
for (int i = 0; i < count;
i++)
{
//Your code here
}
// Avoid
string first_name = "John";
int max_value = 100;
// Prefer
string firstName = "John";
int maxValue = 100;

63. Стандарты кодирования

Стандарты кодирования С#
• Используйте префикс «is» для
переменных, свойств и
методов с типом возврата
Boolean.
• Используйте соответствующий
префикс для внешнего
интерфейса / элементов
пользовательского
Label
интерфейса.
Textbox
private bool isValid, isCompleted;
lbl
txt
Button
btn
DropdownList
ddl
Checkbox
chk

64. Стандарты кодирования

Соглашения о комментировании C #
• Необходимо писать комментарии для сложных логических блоков кода, что
помогает другим разработчикам.
• Начинайте комментарий с верхнего регистра
• Однострочный комментарий в C # Code behind. Выберите строку или текст,
который вы хотите прокомментировать, и нажмите сочетание клавиш Ctrl + K + C.
Чтобы отменить комментарий, нажмите Ctrl + K + U.
// Однострочный комментарий
• Многострочное комментирование в C #, используется для комментирования
всего блока кода.
/*
Строка первая
Строка вторая
*/
• Для комментирования XML следуйте приведенному ниже примеру для справки.
/// <contact>
/// <name></name>
/// <company></company>
/// <phone></phone>
/// </contact>