kazminaviktoriya1
В профиль
Выход
![](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="42" height="42"><rect fill-opacity="0"/></svg>)
Добавить аккаунт
Спринт 1/14: Понимание профессии системного аналитика → Тема 2/9: Системный аналитик как участник команды разработки ПО: его функции и компетенции → Урок 1/3
Системный аналитик в команде и результаты его работы
В этом уроке вы узнаете, чем занимается системный аналитик на каждом этапе разработки ПО и что является результатом его работы.
Стажировка Дани продолжается. Он познакомился со всеми членами команды и теперь знает, кто отвечает за программный код, а кто делает интерфейс ПО красивым и удобным. Чем занимается системный аналитик, теперь тоже понятно, но Даня запутался в последовательности задач.
Сложное ПО требует грамотного анализа и проектирования решений, поэтому работа системного аналитика влияет практически на все этапы разработки ПО. Вот какие задачи системный аналитик выполняет на каждом из них:
Анализ
На этом этапе системный аналитик принимает непосредственное участие. Он собирает требования, проводит интервью с заказчиком и иными заинтересованными лицами, анализирует текущее программное обеспечение (если оно есть). Системный аналитик формулирует требования к будущему ПО, описывает его основные задачи и то, как пользоваться этим программным обеспечением. Собранные требования системный аналитик согласовывает с заказчиком и другими заинтересованными лицами, на этом этапе он также взаимодействует с менеджером. Если в команде есть бизнес-аналитик, он тоже подключается на стадии анализа и активно участвует в рабочих процессах.
Проектирование
После сбора требований начинается проектирование будущего продукта. Системный аналитик подробно описывает, как должно работать ПО, из каких компонентов оно будет состоять и как они будут взаимодействовать между собой. В результате получается документ, который называется «постановка задачи». Если у программного обеспечения запланирован пользовательский интерфейс, системный аналитик может создать его прототип — схематичное описание.
Дизайн
Основной участник этого этапа — UI/UX дизайнер. Самостоятельно или на основе прототипов системного аналитика он создаёт дизайн-макеты интерфейса. На этом этапе системный аналитик может консультировать дизайнера по пользовательским сценариям будущего ПО, то есть ориентировать его, как пользователи могут взаимодействовать с ПО. Системный аналитик также участвует в согласовании дизайн-макетов.
Разработка
На этом этапе, опираясь на постановку задачи, менеджер или системный аналитик сообщают разработчикам, что нужно делать. В процессе выполнения задач у разработчиков могут появиться вопросы. Системный аналитик должен ответить на них и при необходимости вносить правки и уточнения в постановку задачи.
Какие вопросы могут возникать у разработчиков? Можно выделить следующие группы вопросов:
- Разработчику нужно уточнить, что имеется в виду в формулировке, так как задача допускает неоднозначное толкование.
- Разработчику требуется дополнительная информация — например, о том как именно пользователи будут работать с реализуемой функциональностью.
- У разработчика возникла идея, как можно реализовать требование, и он хочет обсудить с системным аналитиком, подойдёт ли пользователям такой вариант.
Тестирование
На этапе тестирования активное участие системного аналитика в разработке не нужно. Его роль ограничивается ответами на вопросы тестировщиков (например, о поведении пользователей или о критериях качества ПО) и приёмкой продукта. Во время приёмки системный аналитик оценивает реализованную функциональность «глазами пользователя» и пытается понять, разработано ли то, что задумано, решает ли разработка задачу пользователя.
Внедрение
Если в команде нет технического писателя, на этапе внедрения системный аналитик разрабатывает техническую документацию (подробное описание баз данных и другую техническую информацию) и готовит пользовательскую (например, описание того, что пользователь может делать с ПО и какой результат он получит). В некоторых организациях аналитик также участвует в презентации готового продукта и обучает пользователей работе с ПО.
Поддержка и развитие
После внедрения ПО системный аналитик продолжает участвовать в поддержке и развитии продукта. Он согласовывает изменения разработанного ПО, вместе с менеджером анализирует запросы от пользователей и помогает устранять ошибки в работе ПО.
Выберите один правильный ответ для каждого вопроса.
Результаты работы системного аналитика
Требования к ПО — основной результат работы системного аналитика. Готовые требования можно представить в виде документов, диаграмм и прочих вещей. Всё это называется артефактами. Набор артефактов неодинаков и зависит от компании, проектной команды или конкретной задачи.
Все артефакты можно разделить на две группы:
- Внешние. Артефакты на языке, понятном для заказчика и пользователей. В них содержится описание того, что будет делать разрабатываемый продукт. Примерами таких артефактов могут быть:
- Пользовательские требования, которые могут быть описаны в виде вариантов использования (Use case) или пользовательских историй (User story).
- Техническое задание в соответствии с государственным стандартом или стандартом организации.
- Software requirement specification (SRS) — спецификация требований к программному обеспечению.
- Внутренние. Артефакты, предназначенные для команды разработки. Внутренним артефактом может быть документ «постановка задачи». Он содержит описание архитектуры приложения, моделей данных, пользовательского интерфейса, алгоритмов обработки данных и API.
Как правило, в каждой компании существует стандарт, по которому ведётся документация. Есть, например, шаблоны оформления спецификаций требований или постановки задачи на разработку. Поэтому набор артефактов отличается у разных компаний и в разных проектных командах.
Стандарт позволяет системному аналитику придерживаться заданных целей, ведь он пишет не для себя, а для других членов проектной команды, пользователей и заинтересованных лиц. По документам или схемам, которые разработал системный аналитик, затем будут действовать разработчики, инженеры по тестированию и другие члены проектной команды, поэтому эти артефакты должны содержать ровно то, что требуется разработчикам и инженерам по тестированию, в удобной для их восприятия форме.
Важно не пренебрегать обратной связью и учитывать, какие у разработчиков и инженеров по тестированию возникали вопросы, что они не так поняли, что пришлось уточнять. В следующий раз это поможет написать документ чётче, понятнее и однозначнее.
Чат поддержки