Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Тема начата: Granitsa от 31 Января 2010, 23:40:03
-
Здравствуйте
Насколько я понял ТЗ может быть на всю систему, а ФД могут быть только по модулям...
но чем отличаются эти документы кроме размера? Есть ли что-то что входит в состав ТЗ, но не входит в ФД?
может ли назвать ТЗ если они разрабатываются отдельно для каждого из модулей системы?
Описаны ли ФД в каких-нибудь методологиях кроме ORACLE AIM?
-
ТЗ (например, по ГОСТ 34) может быть как на автоматизированную систему в целом, так и на ее отдельные части. ТЗ на отдельные части (при наличии ТЗ на систему) называются ЧТЗ - Частные Технические Задания.
-
Заниматься сопоставлением терминов, происходящих из разных понятийных систем (ГОСТ 34 и Корпорация Оракл?) - неблагодарное дело.
Давайте так - зачем вам нужен ответ на этот вопрос? Что вы с ним будете делать?
-
Говоря об отличии терминов, то если речь идет о Oracle AIM и конкретно MD050 - Functional Design, то даже если рассматривать ТОЛЬКО различие моделей ЖЦ в AIM и по ГОСТ, станут понятны и различия соответствующих документов. Исходя из шифра - FD разрабатывается в процессе Module Design and Build, преимущественно на фазе Solution Design. Назначение его достаточно очевидно - представить в связке с соотетствующими бизнес-требованиями (BR030) детальное описание имплементации конкретного модуля, включая описание форм (суть GUI) и отчетов. Т.е. имеем классический пример описания внутреннего и внешнего устройства системы, т.е. - по сути дизайн системы но с т.з. ее функциональности.
Рассматривая ТЗ по ГОСТ - стадия ТЗ в ГОСТ 34 и одноименный документ - суть фаза сбора и формулировки ТРЕБОВАНИЙ к системе или ее части. Дизайн системы как таковой по ГОСТ 34 разрабатывается на более поздних этапах, в частности на стадии Технического проекта (не берем в расчет в данном случае Эскизный проект или Рабочий проект).
Таким образом имеем следующее - сравнение этих двух документов не корректно, как минимум с точки зрения их назначения (ТЗ - это требования, FD - описание дизайна) и фазы ЖЦ на которых они создаются. Другой вопрос, что в практике отечественных интеграторов, занимающихся внедрением того же OEBS можно увидеть причудливые смеси ГОСТа и Oracle AIM, который делается иногда в угоду бредовым требованиям заказчика, иногда по незнанию самих интеграторов, искренне считающих, что ТЗ - это описание дизайна системы :-).
-
Давайте так - зачем вам нужен ответ на этот вопрос? Что вы с ним будете делать?
До не давнего времени в нашей компании не было единой методологии разработки. В результате у нас в проектах попадаются ТЗ, ФД и списки требований. Сейчас мы пытаемся привести нашу документацию к единообразию. Старые проекты трогать не будем, но все новые хотим вести по новой методологии.
Спасибо , Юрию за исчерпывающий ответ. Думаю мы остановимся на ТЗ и ЧТЗ, а функциональные дизайны использовать не будем.
-
Ну как же так, не будете использовать функциональный дизайн... Вот вы подписали с заказчиком ТЗ или ЧТЗ, в которых написано, ЧТО надо сделать. А теперь надо написать КАК вы собираетесь это делать - это будет Функциональный дизайн.
ТЗ и ФД не исключают один другого, они делаются в разное время, с разными целями, и читаются часто разными людьми.
-
Ну как же так, не будете использовать функциональный дизайн... Вот вы подписали с заказчиком ТЗ или ЧТЗ, в которых написано, ЧТО надо сделать. А теперь надо написать КАК вы собираетесь это делать - это будет Функциональный дизайн.
ТЗ и ФД не исключают один другого, они делаются в разное время, с разными целями, и читаются часто разными людьми.
ФД ответит на вопрос, КАК будет сделана система только с одной точки зрения - с т.зрения ее функциональности. Но ничего не скажет об устройстве системы с других точек зрения (архитектурных), например с т.з. той же безопасности. Т.е. описание все равно не будет полным. Тогда зачем, спрашивается огород городить? Кроме этого - следует отдавать себе отчет, что если вы внедряете OEBS, то логичнее работать по AIM, а не выхватывать что-то из ГОСТ, а что-то из AIM - стыковка разных методик/стандартов не такая уж тривиальная задача, если мы хотим, чтобы "гибрид" получился жизнеспособным. Если же речь не идет об OEBS, то зачем использовать методику, которая не факт, что однозначно подходит для конкретного случая?
Хотел добавить, если речь идет о достижении согласия с заказчиком о GUI или тех же отчетных формах - то можно попробовать обойтись "малой кровью" - прототипами, если конечно заказчик готов воспринимать такой формат.
-
Нет мы не внедряем OEBS, у нас самописные системы с нуля и 1с.
для самописных систем используем ТЗ и прототипы в Axure, этот вариант мне нравится больше всего. А вот в 1с там сейчас 1 ТЗ, остальное ФД... Но как и говорил будем двигаться к единой методологии....
-
прототипы в Axure, этот вариант мне нравится больше всего.
Алексей, не поделитесь, как Вам Axure, представителям заказчика какого уровня Вы показываете прототипы на ней, как они реагируют?
-
ФД ответит на вопрос, КАК будет сделана система только с одной точки зрения - с т.зрения ее функциональности.
Что, собственно, и соответствует перечислению 2 п. 2.6 ГОСТ 34.602-89... Таким образом, ФД должен разрабатываться именно на стадии "Техническое задание" по ГОСТ 34.601-90, а уж дорабатываться на проектных стадиях и этапах.
Но ничего не скажет об устройстве системы с других точек зрения (архитектурных), например с т.з. той же безопасности.
Разве требования безопасности можно в полной мере отнести к архитектурным? Защитное заземление/зануление, к примеру?
Хотел добавить, если речь идет о достижении согласия с заказчиком о GUI или тех же отчетных формах - то можно попробовать обойтись "малой кровью" - прототипами, если конечно заказчик готов воспринимать такой формат.
Сейчас очень часто так делается. Остальная бумага заказчика не интересует, даже госзаказчика. Никто ничего не читает, просто тестируется функционал.