Чат поддержки

Практикум
Привет! Это поддержка Практикума 👋 Если что-то не получается — постараемся помочь. Пишите в чат или выберите другой способ связи

пт, 2 декабряв 17:21

Мы уже начали заниматься вашим вопросом, ответим в ближайшее время

Практикум

Здравствуйте!

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

Если же у вас возникнут иные вопросы — обязательно пишите, будем рады помочь :)

17:24

Выбрать способ связи

Поменять когорту

Перейти в профиль

Выйти из профиля

Добавить аккаунт

Поддержка, обслуживание и оценка результатов

спринт Поддержка, обслуживание и оценка результатов

Рабочая документация

2/2

О чём этот спринт

Документирование по ГОСТ

План миграции

4/4

Постпроектная деятельность

1/1

Воркшоп и домашнее задание

2/2

Заключение

1/1

Пригласить друзей

О чём этот спринт

В этом уроке вы узнаете о роли системного аналитика в завершающем этапе проекта.

Команда RANA.Software завершила тестирование первой версии ПО для «Капсулы». Даня рад, что наконец-то можно выдохнуть: последние несколько недель были довольно напряжёнными. Впереди новые вершины и проекты, как надеется Даня, с менее сжатыми сроками (наивный!).

Айгуль

Даня, а где капсула?

Даня

Я её упаковал и вынес из офиса. Не переживай, грузчики уже едут! Доедет в целости и сохранности до наших заказчиков 😇

Айгуль

Мы же договорились, что вернём капсулу после завершения всех работ 😒

Даня

Стоп, а мы не закончили?!

Айгуль

Конечно нет! Нам нужно составить ПМИ, руководство пользователя, план миграции, и это ещё не всё!

Даня

М-да, неловко получилось. Пойду за капсулой! Расскажешь, какой у нас план?

Что будет дальше?

Демонстрация функций ПО

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

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

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

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

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

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

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

Проведение демонстрации функций ПО отличается в разных моделях разработки ПО: в каскадной (Waterfall) и гибкой (Agile).

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

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

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

Во время подготовки к испытаниям программы системный аналитик составляет программу и методику испытаний (ПМИ) — документ, в котором описаны последовательность, сценарии и примеры демонстрации функций ПО.

Во время испытаний команда разработки и заинтересованные лица записывают фактические результаты работы функций. Если какие-то из функций не работают должным образом или вообще отсутствуют в ПО, то испытания программы считаются непройденными. Команда разработки исправляет зафиксированные в ПМИ недочёты, и испытания программы повторяются.

Стандарты программной документации

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

Помимо ГОСТа и собственных стандартов предприятий, существуют международные стандарты документирования программ. Например, в спринте «Разработка требований» вы научились составлять спецификацию требований к ПО в соответствии с международным стандартом, разработанным следующими организациями по стандартизации:

Международной организацией по стандартизации (International Organization for Standardization — ISO);

Международной электротехнической комиссией (International Electrotechnical Commission — IEC);

Институтом инженеров электротехники и электроники (Institute of Electrical and Electronics Engineers — IEEE).

Название каждого международного стандарта включает название организаций, разработавших их, а также код стандарта и его название. Например, стандарт для спецификации требований к ПО называется «ISO/IEC/IEEE 29148:2011(E), Systems and software engineering — Life cycle processes — Requirements engineering».

ГОСТ и стандарты ISO/IEC/IEEE являются полезными для системного аналитика источниками знаний. Чуть подробнее о ГОСТе вы узнаете в следующем уроке.

Демонстрация в гибкой модели

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

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

Также, как правило, во время подготовки к ревью системный аналитик не составляет ПМИ и какие-либо иные документы, а только репетирует последовательность, сценарии и примеры демонстрации разработанных за итерацию функций ПО.

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

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

Рабочая документация

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

Системный аналитик, как правило, самостоятельно разрабатывает руководство пользователя и участвует в составлении иных документов. Эти документы также составляют в соответствии с ГОСТом, стандартами ISO/IEC/IEEE и собственными стандартами предприятия.

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

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

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

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

Системный аналитик вместе с командой разработки оценивает успешность выполнения проекта с точки зрения процесса разработки ПО и удовлетворения результатов проекта бизнес-требованиям.

Что вас ждёт в этом спринте

В этом спринте вы научитесь составлять ПМИ и руководство пользователя в соответствии с ГОСТом.

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

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

Наконец, вы узнаете, как системный аналитик может оценить процесс и результат разработки требований к ПО.

К следующему уроку

Курсы

Вводный модуль

Понимание профессии системного аналитика

Разработка требований

Проект 1. Спецификация требований ко второму релизу Chatty

SQL для аналитиков

Моделирование данных

Проект 2. Моделирование данных и работа с базой данных интернет-магазина «Накарабине»

Моделирование процессов

Пользовательские интерфейсы

Agile-практики

Проект 3. Бэклог приложения для сети клиник «Вита»

Трудоустройство

Архитектура системы

Программные интерфейсы

Проект 4

Реализация системы

Поддержка, обслуживание и оценка результатов

Дипломный проект

Дополнительные материалы

x