Меня интересеут ответ на вопрос: какие документы должен получить разработчик для того, чтобы работать максимально эффективно? И что должно содержаться в этих документах?
Понятно, что если разные стандарты типа ГОСТ, ISO и, наверное, другие, но у меня сейчас нет времени на их изучение (если только где-то есть краткое описание).
Для себя я разделяю документы (или то, что в них написано) на две категории — требования и тех.задание. По требованиям понятно что нужно, но вариантов реализации может быть очень много, а ТЗ как раз таки описывает именно как должно быть.
Собственно, почему спрашиваю. Мне выдали документ, который скорее похож на требования. Он содержит:
1. Описание бизнес-процессов системы ввиде разных UML-диаграмм. Например, жизненный цикл заказа в систиме.
2. Описание функциональных требований. Например, возможности менеджера по работе с заказом.
На мой взгляд документа вполне достаточно для разработки, но у меня такое ощущение, что для того чтобы не было реально сильного продолба по срокам и заказчик получил то, что нужно, тут ещё аналитик и архитектор должны минимум месяц работать.
Хотелось бы также узнать как у Вас выглядят документы доступные разработчику. Насколько формализованы задачи, которые получает разработчик?
Здравствуйте, FreddieM, Вы писали:
FM>Меня интересеут ответ на вопрос: какие документы должен получить разработчик для того, чтобы работать максимально эффективно? И что должно содержаться в этих документах?
FM>Понятно, что если разные стандарты типа ГОСТ, ISO и, наверное, другие, но у меня сейчас нет времени на их изучение (если только где-то есть краткое описание).
FM>Для себя я разделяю документы (или то, что в них написано) на две категории — требования и тех.задание. По требованиям понятно что нужно, но вариантов реализации может быть очень много, а ТЗ как раз таки описывает именно как должно быть.
AFAIK у буржуев нет такого зоопарка, как в нашем ГОСТ-32.* (ТЗ, ТП, ЭП), а есть тупо техническая спецификация (TS), которой обзывают вообще всякий технический документ — внешний ли, внутренний ли.
В ISO TS проходит например такой жизненный цикл.
http://www.iso.org/iso/standards_development/it_tools/flowchart_main/flowchart_ts.htm
Структурировать внутреннюю TS можно как угодно, главное чтобы её структура соответствовала принятой в команде методологии разработки.
FM>Собственно, почему спрашиваю. Мне выдали документ, который скорее похож на требования. Он содержит:
FM> 1. Описание бизнес-процессов системы ввиде разных UML-диаграмм. Например, жизненный цикл заказа в систиме.
FM> 2. Описание функциональных требований. Например, возможности менеджера по работе с заказом.
Если в конторе правит Agile, которая в теории стимулирует к снижению уровня бюрократии, то TS предназначена не столько для того, чтобы разжевать разработчику что ему кодить, сколько является памяткой о том, что ему нужно не забыть реализовать в итерации. Если чо непонятно или упущено — подбежит аналитик и дообъяснит на пальцах или дополнительным подчиненным таском.
FM>На мой взгляд документа вполне достаточно для разработки, но у меня такое ощущение, что для того чтобы не было реально сильного продолба по срокам и заказчик получил то, что нужно, тут ещё аналитик и архитектор должны минимум месяц работать.
Если и должны работать, то не над четкими чеканными многостраничными формулировками документа, а над эскизами и понятными схемами, предназначенными для разработчика.
Внешний вид экранной формы можно описать десятью страницами текста, а можно одной картинкой-макетом с комментариями.
Ну и про личное общение не забывать.
FM>Хотелось бы также узнать как у Вас выглядят документы доступные разработчику. Насколько формализованы задачи, которые получает разработчик?
Лично у меня, если речь идёт об учетных системах, внутренняя ТС состоит из кусочков:
— Терминология
— Краткое, но доходчивое описание предметной области
— Схематичные диаграммы (ER, UML Activity/Statechart)
Далее идут требования к разрабатываемым/дорабатываемым разделам, которые в свою очередь включают:
— Опять краткое описание предметной области
— Назначение таблиц и при необходимости описание полей
— Схематичные диаграммы (ER, Activity, Statechar, Class)
— Алгоритмы в виде текстовых юз-кейсов
— Правила проверки пред-пост-условий и инвариантов
— Макеты экранных форм
Серьезные "боевые" диаграммы держатся не в документе, а в стороне.
B>AFAIK у буржуев нет такого зоопарка, как в нашем ГОСТ-32.* (ТЗ, ТП, ЭП), а есть тупо техническая спецификация (TS), которой обзывают вообще всякий технический документ — внешний ли, внутренний ли.
B>В ISO TS проходит например такой жизненный цикл.
B>http://www.iso.org/iso/standards_development/it_tools/flowchart_main/flowchart_ts.htm
Не путайте коллегу, приведенная диаграмма — часть жизненного цикла при создании стандарта ИСО, а TS — это одна из стадий жизни стандарта.
