241
Поздравления / Re: Поздравляем Юрия Булуй с Днем Рождения
« : 10 Сентября 2008, 15:07:17 »
Исполнения всего, что задумано!
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
... Чем меньше напишете в требования к функциям в ТЗ для договора - тем лучше для Вас, как Исполнителя. Описания ВИ (текстовые - не диаграммы ВИ UML), как правило, весьма подробны. ...
1. ГОСТ не запрещает описывать ВИ в ТЗ . Но описание требований к функциям в разделе 2.6.2 должно быть. Если заменить описание функций описанием ВИ - Заказчик будет иметь право возражать.
2. Результаты оценки оформляются в виде отчета о выполненной работе (предпроектном обследовании). Есть ГОСТ на НИР, но он регламентирует фактически только форму титульного листа отчета.
3. ... Вообще-то странно, если Заказчик согласится Вам оплатить предпроектное обследование только для того, чтобы Вы заявили ему стоимость Ваших услуг. ...
Скорее всего, наиболее приемлемым документом для Заказчика будет ТЗ.ТЗ обязательно будем писать
И если Вы собираетесь использовать описание ВИ (use cases) для описания требований в ТЗ по ГОСТ, то местами в тексте ТЗ Вам придется достаточно "творчески" отображать объектно-ориентированные представления в функциональные , имея в виду, что ВИ - не тождественен функции.
2.6.2. В подразделе “Требование к функциям (задачам)”, выполняемым системой, приводят:
- по каждой подсистеме перечень функций, задач или их комплексов (в том числе обеспечивающих взаимодействие частей системы), подлежащих автоматизации;
- при создании системы в две или более очереди - перечень функциональных подсистем, отдельных функций или задач, вводимых в действие в 1-й и последующих очередях;
- временной регламент реализации каждой функции, задачи (или комплекса задач);
- требования к качеству реализации каждой функции (задачи или комплекса задач), к форме представления выходной информации, характеристики необходимой точности и времени выполнения, требования одновременности выполнения группы функций, достоверности выдачи результатов;
- перечень и критерии отказов для каждой функции, по которой задаются требования по надежности.
У меня подходит к концу проект, в котором целый этап был посвящен написанию ТЗ ровно по ГОСТ 34.602. Не то, чтобы это первое ТЗ по ГОСТ у меня, но такого трепетного отношения мы к нему еще не проявляли, к тому же со временем приходит все новое понимание старых вещей. Хорошо или плохо, но мы, естественно написали этот документ.
Из вопросов которые я мог бы осветить в потенциальной статье мне наиболее интересны следующие:
- Место концепции в ТЗ
- Место описания бизнес-процессов в ТЗ
- Место вариантов использования и других требований в ТЗ
Чуть менее интересно, по причине того, что это может быть очень по разному у всех
- Что мы писали в определеннных разделах (наше толкование ГОСТ)
- Последовательность разработки