Загрузил Александра Шевель

Практическая работа №27

реклама
Практическая работа №27
Тема: Техническое задание. Постановка задачи.
1.Что такое постановка на реализацию в IT
Техническое задание — это не то же самое, что и постановка на реализацию.
Техническое задание — это результат обработки исходных (организационных, бизнес-)
требований, их уточнения и перевода на системный/технический уровень.
Постановка задачи на реализацию — это описание способа реализации исходных
требований, технического задания, архитектурного решения, изложение требований к
устройству спроектированного решения (на этом этапе исходные требования уже
обработаны).
Постановки на реализацию
в процессе создания IT-продукта
Процесс реализации ИТ-проекта от инициации идеи до внедрения и эксплуатации
готового ИТ-решения
Далее на этапе Определения метода решения мы занимаемся Уточнением требований.
Здесь уже появляется структура функций, ИТ-продуктов будущего проекта. А постановка
на реализацию описывает, как мы эти функции и продукты будем реализовывать.
Постановка описывает конкретную функцию, модуль, что-то максимально
локализованное. Объектами постановки могут быть отдельные компоненты, модули или
функции – в зависимости от того, как мы декомпозировали функциональную структуру
системы/решения в техническом задании.
Зачем нужна постановка на реализацию?
Постановка помогает:
1. Определить границы, защититься от их изменений
2. Зафиксировать критерии успешного результата
Кто пишет постановку на реализацию?
1. Менеджер проекта / менеджер продукта
2. Аналитик
3. Тимлид разработки, например, когда аналитика на проекте нет. Тогда менеджер
верхнеуровнево описывает необходимые функции, а команда разработки сама
пишет для себя постановки и задачи.
Кому нужна постановка на реализацию?
1.
2.
3.
4.
Менеджеру проекта (или продукта).
Аналитику.
Команде..
Заказчику
Постановка на реализацию может содержать разделы:
1.
2.
3.
4.
5.
6.
Контекст задачи
Ключевые источники информации
Заинтересованные стороны
Критерии приемки результата
Нефункциональные требования и ограничения
Описание решения
Контекст задачи – это краткая информация о ситуации и проблемах, из-за
которых возникла стоящая перед вами задача по автоматизации. Данная
часть постановки – это, по сути, срез бизнес-требований, которые были
собраны бизнес-аналитиком на предыдущем этапе.
Контекст задачи помогает:






сформировать «мостик» между заказчиком и исполнителем,
минимизировать риск того, что решение будет оторвано от реалий будущего
использования,
разработчикам придумать лучшее решение,
тестировщики могут разработать максимально приближенные к реальному
использованию тест-кейсы,
команде погрузиться в предметную область и прокачать экспертизу в предметной
области,
аналитику в трассировке требований на проблемы бизнеса.
Ключевые источники информации - В этом разделе постановки речь идёт
о едином перечне источников информации, описание которых снижает риск
использования недостоверной информации.




Описание внешнего или ранее реализованного API (например, API
компании-перевозчика). Разработчик не должен сам искать в интернете какуюто версию, т.к. она может оказаться не последней и не согласована с
архитектором.
HLD (high-level design, описание архитектуры)
Стандарты заказчика, если речь идет про передачу листинг кода, а также когда
есть свои определенные стандарты его оформления
Ссылка на памятку по чтению постановки. В некоторых случаях формат
постановки может быть достаточно объемным и в нем могут использоваться
артефакты, которые не всегда будут понятны человеку со стороны (или даже
разработчику команды, который может воспринять постановку неправильно).
Поэтому ссылка, например, на соглашение о моделировании вполне может быть
источником информации.
Заинтересованные стороны
Заинтересованные стороны (далее ЗС) — это перечень людей, которые
будут влиять на принятие решений и от которых зависит успех реализации.
Чем помогает перечень заинтересованных лиц:




Определение принадлежности реализуемых в рамках постановки на реализацию
требований к ЗС.
Позволяет проверить, что все необходимые ЗС выявлены и привлечены.
Дает понимание о том: кто принимает решения, с кем можно коммуницировать
при реализации, кто будет в ходе испытаний принимать решение согласно
критериям приемки.
Можно использовать этот перечень при согласовании и демо.
Роли заинтересованных сторон
Критерии приемки результатов. Уровень детализации критериев
приемки
Критерии приемки результатов — критерии, выполнение которых может
говорить о том, что решение реализовано (definition of done постановки).
Чем помогают критерии приемки:



дают понимание границ реализации,
обеспечивают полноту реализации,
выступают чек-листом приемки (аналитиком при авторском надзоре и
заказчиком)
Примеры требований, которые могут служить критериями приемки:
1. Необходимо учитывать время технологических операций по сбору заказа,
хранению и транспортировке с производства до терминалов компанийперевозчиков.
2. Информация по срокам доставки конкретных компаний – перевозчиков должна
рассчитываться в момент оформления заказа
3. Перечень доступных для выбора компаний-перевозчиков должен
формироваться с учетом возможности доставки компанией-перевозчиком по
указанному адресу доставки
Раздел 5. НФТ и ограничения решения
Нефункциональные требования — требования к видам обеспечения и
ограничений реализации. НФТ нужны, чтобы их учитывать при принятии
решения в рамках постановки.
Ошибки при их проработке в последствии могут привести к очень серьезным
проблемам и полной неработоспособности решения
К наиболее важным требованиям относятся:



производительность (использование в нескольких филиалах) ,
доступность (24/7),
масштабируемость (количество сотрудников).
Необходимо также учитывать:


требования к видам обеспечения - документация и юридические аспекты,
переходные требования - требования, позволяющие без потерь перейти к новой
версии автоматизации.
Примеры НФТ и ограничений:
1. Время расчета срока не должно превышать 1 секунду
2. Необходимо предусмотреть возможность подключения в дальнейшем
неограниченного количества компаний — перевозчиков
3. Сервис расчета сроков должен быть доступен 24/7
4. Расчет срока возможен только при online-доступности
Раздел 6. Описание решения
Описание решения — это основная часть постановки, описывающая способ
и границы реализации
Может содержать:







Сценарии использования (UseCase)
Информационные модели
Статусные модели
Алгоритмы
Макеты интерфейсов (UX/UI)
Компонентные схемы
Описание интеграций
Диаграммы для UseCase ограничены, т.е. фиксируют конкретный набор
функциональности, который, в свою очередь, помогает:




аналитику ничего не забыть,
разработчику реализовать данный сценарий,
заказчику увидеть сценарий его будущего взаимодействия с
системой,
тестировщикам создать тест кейсы.
Важно понимать, что команда разработчиков должна уметь читать эти
диаграммы.
Задача:
1. Кратко законспектируете основные критерии
2. Создайте постановку задачи it макетом
Работу проверила
Шевель. А.А
Скачать