Практическая работа №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 макетом Работу проверила Шевель. А.А
