ТЕХНОЛОГИИ ПРОГРАММИРОВАНИЯ · 2020. 3. 29. · Управление конфигурацией Конфигурация—все характеристики

ЕвгенийАлександровичМирошниченко

[email protected]

Отделение информационных технологий

Инженерная школаинформационных технологийи робототехники

Томский политехнический университет

ВВЕДЕНИЕ В ПРОГРАММНУЮ ИНЖЕНЕРИЮ

ТЕХНОЛОГИИ

ПРОГРАММИРОВАНИЯ

Технологии программирования | Е.А. Мирошниченко, ТПУ

Средства групповой работы (collaborative software)

• Порталы типа Microsoft Sharepoint;• Google Disc и т.п.; • Google Docs;• Wiki, см. https://en.wikipedia.org/wiki/Comparison_of_wiki_software;• Microsoft OneNote;• и др., см. https://en.wikipedia.org/wiki/List_of_collaborative_software

2


Железный треугольник (треугольник возможностей)

«Объявление: делаем дёшево, быстро и качественно.Выберите два пункта из трёх».

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

3

Время (сроки)

Ресурсы(деньги, люди и т.д.)

Качество(возможности,

требования)


Управление конфигурацией

Конфигурация — все характеристики системы, зафиксированные в технической документации или в самом продукте (ISO/IEC/IEEE 24765:2010 Systems and software engineering — Vocabulary).

Основные элементы конфигурации:• печатные документы;• электронные документы;• исходные тексты.

Стандарт: IEEE Std 828-2012 Configuration Management in Systems and Software Engineering

4


Управление конфигурацией: задачи

Задачи управления конфигурацией:• определить что и в каком виде надо хранить (configuration

identification);• управлять изменениями конфигурации и её элементов

(configuration control), в том числе: хранить историю изменений (см. также резервное копирование); организовать согласованное внесение изменений; хранить моментальных снимков (версий) конфигурации, то есть

согласованные состояния проекта; управлять правами доступа; решать проблемы и конфликты.

С чего начать:• Выбор и внедрение системы управления версиями (version

control system);• Разработка организационного обеспечения (регламента).

5


Управление конфигурацией: системы управления версиями

Настольные (локальные)

6

Локальный компьютер

БД версий

Версия 3

Версия 2

Версия 1

Файл

ЦентрализованныеЦентральный сервер

VCS

БД версий

Версия 3

Версия 2

Версия 1

Компьютер 1

Файл


Файл

Распределённые (децентрализованные)


БД версий

Версия 3

Версия 2

Версия 1

Файл


БД версий

Версия 3

Версия 2

Версия 1

Файл

Сервер

БД версий

Версия 3

Версия 2

Версия 1

Файл


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

Централизованные (примеры):• Microsoft Team Foundation Server (TFS) / Azure DevOps Server

Version Control (Team Foundation Version Control)• Subversion (SVN)• Perforce Helix Core

Распределённые (примеры):• Git• Mercurial• Bazaar• Darcs

Обзоры:• https://www.softwaretestinghelp.com/version-control-software/• https://en.wikipedia.org/wiki/Comparison_of_version-

control_software7

https://www.softwaretestinghelp.com/version-control-software/

https://en.wikipedia.org/wiki/Comparison_of_version-control_software


Инженерия требований (Requirements Engineering)

Инженерия требований — междисциплинарный подход, который связывает стороны поставщика и заказчика для определения и поддержки требований, которым должна отвечать целевая система, продукт или услуга (ISO/IEC/IEEE 29148).

Инженерия требований — дисциплина, нацеленная на определение требований и управление ими (REBoK).

8

Инженерия требований

Анализ/разработка требований Управление требованиями


Нужно больше ясности

Бизнес-анализ

Анализ требований

Системный анализ

АналитикБизнес-

аналитик

Требования

Потребности

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

Техническое задание

Инженер по требованиям

Системный аналитик

Продуктовый аналитик

9

Инженерия требований


Важно: различать потребности и требования

Люди не знают, чего хотят, до тех пор, пока им это не предложат.Фредерик Бегбедер. 99 франков

Гюнтер о’Дим даёт не то, что ты хочешь, а то, что ты просишь.The Witcher 3. Hearts of Stone

Я хочу нравиться

мужчинам!

10


Системный подход

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

Стейкхолдерам на самом деле не нужна создаваемая система как таковая.

Им нужно достигнуть каких-то своих целей, а создаваемая система — одно из средств этого добиться.

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

11


Дерево целей

12

Увеличить долю компании на рынке

Повысить лояльность

клиентов

Внедрить CRM-систему

Повысить долю успешных проектов

Внедрить управление проектами

Разработать систему управления

проектами

Улучшить репутацию у

вендоров

Повысить качество работ

Улучшить коммуникацию

сотрудников

Переделать корпоративный

портал

Коммерческийдиректор

Генеральныйдиректор

Техническийдиректор

IT-директор

Вы


Требования

Требование — утверждение, которое передаёт или выражает

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

(ISO/IEC/IEEE 29148-2011).

Внимание: Holy War detected!

Требование — это форма или содержание, то есть конкретная

формулировка утверждения или его семантика?

13


Важно: не путать задачу и решение!

Удовлетворить потребность — задача.Как этого добиться технически — решение.

14


Между Сциллой и Харибдой

15

Пространство выбора решений для разработчиков

Больше Меньше

Понятность для разработчиков и проверяемостьМеньше Больше

Требование

Техническое решение

Потребность

Требование





Основные работы при разработке требований

• Исходная постановка задачи.• Идентификация и вовлечение стейкхолдеров.• Сбор и исследование информации:

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

• специфика бизнес-процессов организации;• данные об унаследованном ПО (legacy software);• используемое аппаратное обеспечение;• политика безопасности организации;• уровень квалификации персонала.

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

16


Виды требований по уровню и источнику

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

• Stakeholder Requirements: потребности/требования с точки зрения конкретных стейкхолдеров или классов стейкхолдеров

• User Requirements: частный, но наиболее распространённый вариант “Stakeholder Requirements”, если стейкхолдеры — это пользователи/потребители

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

• Software Requirements: требования к программному обеспечению.

17

Documents

ТЕХНОЛОГИИ ПРОГРАММИРОВАНИЯ · 2020. 3. 29. · Управление конфигурацией Конфигурация—все характеристики