|
ГОСТ 34.602-89 Вопросы и ответы
|
||
|---|---|---|
Участник
Откуда: Нижний Новгород
Сообщения: 14 239 |
||
| 01.09.2006, 13:41 |
|
|
|
|
|
ГОСТ 34.602-89 Вопросы и ответы
|
|||
|---|---|---|---|
|
#18+
iscrafmА можно расшифровать в чем заказчик не прав? плз При установлении требований он ошибся знаком. Вместо <= 3тыс. указал =3тыс. Точнее ошибся конечно разработчик ТЗ, а заказчик по неграмотности согласился. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2006, 11:57 |
|
||
|
ГОСТ 34.602-89 Вопросы и ответы
|
|||
|---|---|---|---|
|
#18+
Boatman mcureenab UC требованием быть не может. UC это модель поведения системы, требование, это соглашение исполнителя и заказчика о том, что система должна в определённой мере соответствовать этой модели. Так можно договориться до того, что требование одно - сооветствие системы ТЗ, а ТЗ - это модель системы, состоящая из множества ограничений и допущений. Так ТЗ это и есть требования. А то о чём ты говоришь ("сооветствие системы ТЗ") это скорее положение договора на поставку/разработку автоматизированной системы. В общем, это конечно тоже требование, но не техническое, а юридическое. Отождествлять ТЗ и модель системы в общем случае я бы не стал. Например, повторюсь, когда речь идёт о доработке существующей системы ТЗ будет содержать только те требования, которые нужно реализовать в рамках проекта доработки, тогда как модель будет описывать всю систему в том числе и существующую часть системы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2006, 12:15 |
|
||
|
ГОСТ 34.602-89 Вопросы и ответы
|
|||
|---|---|---|---|
|
#18+
mcureenab iscrafmА можно расшифровать в чем заказчик не прав? плз При установлении требований он ошибся знаком. Вместо <= 3тыс. указал =3тыс. Точнее ошибся конечно разработчик ТЗ, а заказчик по неграмотности согласился. Я не об этом. Действительно, если 2 тормозят, то каким образом подключение большего числа пользователей ускорит работу? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2006, 12:44 |
|
||
|
ГОСТ 34.602-89 Вопросы и ответы
|
|||
|---|---|---|---|
|
#18+
Boatman А если мы не можем реализовать смоделированный UC, не стоит ли его измернить? Может быть и стоит, зависит от ситуации. Если мы хотим создавать систему поэтапно или частями, то можно создать модель для каждого этапа или части, но можно создать и целевую модель, а подмножества требований для каждого этапа выделить в ТЗ на версию системы. Опять же, возвращаясть с доработке системы, нам придётся в ТЗ выделить из UC только те требования, которые не были реализованы ранее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2006, 13:02 |
|
||
|
ГОСТ 34.602-89 Вопросы и ответы
|
|||
|---|---|---|---|
|
#18+
iscrafm mcureenab iscrafmА можно расшифровать в чем заказчик не прав? плз При установлении требований он ошибся знаком. Вместо <= 3тыс. указал =3тыс. Точнее ошибся конечно разработчик ТЗ, а заказчик по неграмотности согласился. Я не об этом. Действительно, если 2 тормозят, то каким образом подключение большего числа пользователей ускорит работу? Увеличение числа пользователей работу не усуорит, но увеличит производительность, т.е. количество операций выполняемых в единицу времени. Например, система будет обслуживать не 2тыс запросов в минуту, а 3тыс., хотя при этом каждый отдельный запрос может выполняться одинаково долго как при малой так и при большой нагузке. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2006, 13:06 |
|
||
|
ГОСТ 34.602-89 Вопросы и ответы
|
|||
|---|---|---|---|
|
#18+
iscrafm Dmitry V. Liseev Заказчик при запуске в опытную эксплуатацию: - Вот в требованиях был пункт, что система должна работать с приемлемой производительностью на 3 тыс. одновременных юзверей. Мы подключили только двух и у нас все "страшно тормозит". - Так вы подключите 3 тыс. одновременно по всему заводу и посмотрите. - А зачем подключать 3 тыс., если даже два тормозят? А можно расшифровать в чем заказчик не прав? плз Заказчик неправ в следующем: В ТЗ использовал недопустимую техническую характеристику - "приемлимая производительность". Так формулировать требование нельзя. Всегда должно быть указано конкретное числовое значение, которое можно реально проверить, типа: - среднее время обработки короткой транзакции -n сек; - максимальное время отклика системы на запрос пользователя - не более n сек при количестве одновремеенео работающих пользователей m; - масштабирование системы (увеличение числа пользователей до к человек ) не должно приводить к увеличению масимального времени отклика и т д. Т. е. ТЗ не должно содержать неких "качественных" требований, которые разработчик и заказчик могут толковать совершенно по разному. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2006, 13:21 |
|
||
|
ГОСТ 34.602-89 Вопросы и ответы
|
|||
|---|---|---|---|
|
#18+
ЮВ, понятно что требование сформировано не корректно. Но я специально выделю часть диалога которая имелась ввиду в вопросе: Так вы подключите 3 тыс. одновременно по всему заводу и посмотрите. - А зачем подключать 3 тыс., если даже два тормозят? Чем не логичен последний вопрос? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2006, 13:24 |
|
||
|
ГОСТ 34.602-89 Вопросы и ответы
|
|||
|---|---|---|---|
|
#18+
mcureenab Отождествлять ТЗ и модель системы в общем случае я бы не стал. Например, повторюсь, когда речь идёт о доработке существующей системы ТЗ будет содержать только те требования, которые нужно реализовать в рамках проекта доработки, тогда как модель будет описывать всю систему в том числе и существующую часть системы. Если пользоваться определением модели системы из системного анализа, то ТЗ - это и есть модель системы определенного уровня детализации. Проектная документация тоже модель, но более детализированная и т.д. Процесс разработки - это построение последовательности все более детализированных моделей будущей системы. mcureenab Может быть и стоит, зависит от ситуации. Если мы хотим создавать систему поэтапно или частями, то можно создать модель для каждого этапа или части, но можно создать и целевую модель, а подмножества требований для каждого этапа выделить в ТЗ на версию системы. Опять же, возвращаясть с доработке системы, нам придётся в ТЗ выделить из UC только те требования, которые не были реализованы ранее. Чтобы не страдать раздвоением личности, когда модель расходится с требованиями, в описанном случае предлагаю разбить исходный UC на два и связать их отношением extends. Тогда не придется мучительно выделять из UC, который сам по себе может быть записан в ТЗ, какие-то волшебные требования и отслеживать их сложные отношения с исходной моделью. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2006, 15:14 |
|
||
|
ГОСТ 34.602-89 Вопросы и ответы
|
|||
|---|---|---|---|
|
#18+
iscrafmЮВ, понятно что требование сформировано не корректно. Но я специально выделю часть диалога которая имелась ввиду в вопросе: Так вы подключите 3 тыс. одновременно по всему заводу и посмотрите. - А зачем подключать 3 тыс., если даже два тормозят? Чем не логичен последний вопрос? Есть статистистические методы оценки достоверности информации. Если вы на экзамене выбрали случайныи образом билет и не ответили на 2 приведенных в нем вопроса, вам ставят двойку сразу, не проверяя знание остальных 98 (из 100) вопросов по предмету. Если в случайной выборке нескольких микросхем из партии в 100 штук обнаруживается брак, то бракуется вся партия. И здесь аналогичная логика рассуждений - если система тормоззит при 2 пользователях, то нет смысла проверять ее при 3000. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2006, 17:31 |
|
||
|
ГОСТ 34.602-89 Вопросы и ответы
|
|||
|---|---|---|---|
|
#18+
ЮВИ здесь аналогичная логика рассуждений - если система тормоззит при 2 пользователях, то нет смысла проверять ее при 3000. Я то с этим согласен. Вопрос собственно был Лисееву Дмитрию. Может я неправильно понял то, что он хотел сказать этим: авторПришлось долго грузить заказчика теорией массового обслуживания, эрлангами и прочей мутью, объясняя, что то, что он понимает под "производительностью", на самом деле называется "временем отклика". И архитектура системы такова, что время отклика мало отличается, будет ли там два юзера или 3 тыс ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2006, 17:50 |
|
||
|
ГОСТ 34.602-89 Вопросы и ответы
|
|||
|---|---|---|---|
|
#18+
"ЮВ" <nospam@sql.ru>; wrote in message news:3076531@sql.ru... Hi! > Заказчик неправ в следующем: > В ТЗ использовал недопустимую техническую характеристику > - "приемлимая производительность". Есть такая наука: "Безопасность жизнедеятельности". Там есть понятие "психофизиологии оператора". Если время отклика системы превышает, скажем полсекунды, то оператор ощущает дискомфорт и сильный стресс. Повышается утомляемость, растет количество ошибок. Есть масса книг на эту тему и там есть такой термин, как "комфортное время отклика". > - максимальное время отклика системы на запрос пользователя > - не более n сек при количестве одновремеенео работающих > пользователей m; Во-первых, надо сначала посадить m пользователей, т.е. запустить систему в пром. эксплуатацию по всему заводу. А это деньги и время. Во-вторых, как измерять будем? Каждому пользователю секундомер дадим? > - масштабирование системы (увеличение числа пользователей до > к человек ) не должно приводить к увеличению масимального > времени отклика и т д. Тут тоже не все так просто. Если данных мало, то очевидно, что время отклика с увеличением юзеров будет расти очень быстро. Кроме того, быстро будет падать общая производительность всей системы вплоть до полной остановки и вылета большинства транзакций по таймауту. Если данных очень много, то общая производительность будет расти, а время отклика будет расти не существенно. Эффект этот проявляется тем сильнее, чем сложнее модель данных в системе (много зависимостей между данными), а этот параметр зависит только от предметной области и постановки задачи, а не от архитектуры системы и ее ТТХ. В принципе, в таких случаях проводят искусственную денормализацию данных и оптимизируют их под типовые транзакции, но тут поле для маневра не очень велико. И чем "хуже" статистика на конкретном наборе таких сложных данных, тем печальнее ситуация. На разных наборах данных одного объема можно получить результаты измерения, отличающиеся на несколько порядков. Угадать заранее, какие конкретно данные будет хранить заказчик, не представляется возможным, кроме того они меняются. В итоге так строго это требование теоретически не выполнимо. Можно говорить лишь о вероятностях, крайне сильно зависящих от незначительного изменения кучи факторов. Грузить заказчика синергетикой, фракталами и странными аттракторами - бесполезно. > Т. е. ТЗ не должно содержать неких "качественных" требований, > которые разработчик и заказчик могут толковать совершенно > по разному. Чтобы толковать одинаково, надо много дополнительных книг заказчику прочитать. ____________________________ С уважением, Лисеев Дмитрий. http://private.peterlink.ru/dimik/ PGP key fingerprint: 09 28 74 28 6C 39 62 29 2E CB 95 03 4F 04 33 73 Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2006, 18:08 |
|
||
|
ГОСТ 34.602-89 Вопросы и ответы
|
|||
|---|---|---|---|
|
#18+
"iscrafm" <nospam@sql.ru>; wrote in message news:3076564@sql.ru... Hi! > Чем не логичен последний вопрос? Сколько готовых автомобилей в минуту сходят с конвейера? Каково полное время изготовления одного автомобиля? Как связаны эти числа? ____________________________ С уважением, Лисеев Дмитрий. http://private.peterlink.ru/dimik/ PGP key fingerprint: 09 28 74 28 6C 39 62 29 2E CB 95 03 4F 04 33 73 Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2006, 18:08 |
|
||
|
ГОСТ 34.602-89 Вопросы и ответы
|
|||
|---|---|---|---|
|
#18+
Dmitry V. Liseev Есть такая наука: "Безопасность жизнедеятельности". Там есть понятие "психофизиологии оператора". Если время отклика системы превышает, скажем полсекунды, то оператор ощущает дискомфорт и сильный стресс. Да, это проблема была актуальна раньше - искусственно увеличивалось время отклика, чтобы оператор мог немного "расслабиться" после введенной команды. Сейчас, к сожалению, приходится решать обраьные проблемы - как сократиить это время. Dmitry V. Liseev Во-первых, надо сначала посадить m пользователей, т.е. запустить систему в пром. эксплуатацию по всему заводу. А это деньги и время. Во-вторых, как измерять будем? Каждому пользователю секундомер дадим? Чтобы убедиться, что аппарат будет двигаться по Луне, вам обязательно нужна Луна ? Для проверки работспособности существуют стенды, макеты, математические модели и т. п. Мне не надо сажать за компьютеры 200 пользователй. Я создаю на 2-3-x компъютерах 200 процессов, которые с определенной частотой выполняют некие транзакцтт, имитируя реальную деятtльность пользователей. Все временные параметры контролируется и фиксируется в журналах обработки (протоколах). Dmitry V. Liseev > - масштабирование системы (увеличение числа пользователей до > к человек ) не должно приводить к увеличению масимального > времени отклика и т д. Тут тоже не все так просто. Моделирование. См. выше. Dmitry V. Liseev > Т. е. ТЗ не должно содержать неких "качественных" требований, > которые разработчик и заказчик могут толковать совершенно > по разному. Чтобы толковать одинаково, надо много дополнительных книг заказчику прочитать. Либо в ТЗ ввести раздел "Термины и определения", приведя их однозначное толкование. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2006, 18:36 |
|
||
|
ГОСТ 34.602-89 Вопросы и ответы
|
|||
|---|---|---|---|
|
#18+
Dmitry V. Liseev Во-первых, надо сначала посадить m пользователей, т.е. запустить систему в пром. эксплуатацию по всему заводу. А это деньги и время. Во-вторых, как измерять будем? Каждому пользователю секундомер дадим? Что-то я совсем плохо Вас понимаю. Зачем садить m пользователей, если система на двух тормозит? Задаю такой же вопрос, как и заказчик из Вашей байки. На 3000 быстрее станет? При чем здесь автомобили? Давайте про сосиски еще поговорим тогда уж :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2006, 19:03 |
|
||
|
ГОСТ 34.602-89 Вопросы и ответы
|
|||
|---|---|---|---|
|
#18+
Boatman Если пользоваться определением модели системы из системного анализа, то ТЗ - это и есть модель системы определенного уровня детализации. Проектная документация тоже модель, но более детализированная и т.д. .... ИМХО, детализация тут ни при чём. ТЗ детально описывает ЧТО должна научиться делать система. Проектная документация (если я правильно тебя понял) - КАК система будет это делать. Т.е. проектная документация не детализирует требования (требования должны быть атомарными), а специфицирует их с точки зрения реализации. ЧТО и КАК, это не разные уровни абстракции или детализации, а разные точки зрения на предмет. ЧТО - внешний вид предмета, КАК - внутренняя организация предмета. Комплект ТЗ на все версии системы позволяет нам судить о системе в целом, но отдельно взятое ТЗ в общем случае не даёт представления о системе. Например, если в очередной верии требуется, чтобы система работала на UNIX, то в ТЗ будет только требование относительно поддержки UNIX и больше ничего. Что это за система из этого ТЗ мы не поймём. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2006, 19:42 |
|
||
|
ГОСТ 34.602-89 Вопросы и ответы
|
|||
|---|---|---|---|
|
#18+
BoatmanЧтобы не страдать раздвоением личности, когда модель расходится с требованиями, в описанном случае предлагаю разбить исходный UC на два и связать их отношением extends. Тогда не придется мучительно выделять из UC, который сам по себе может быть записан в ТЗ, какие-то волшебные требования и отслеживать их сложные отношения с исходной моделью. Декомпозиция UC усложняет модель, тогда как выделение подмножества требований на модель не влияет. Согласен, что полное соответствие модели и создаваемой системы облегчает жизнь, но менять модель только из-за того, что заказчик в последний момент перед подписанием ТЗ отказался от реализации части требований может быть не удобно. К стати, в какой форме ты предполагаешь запись UC в ТЗ? Это будет набор сценариев или как? Как запись UC согласуется со стандартной структурой ТЗ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2006, 20:12 |
|
||
|
ГОСТ 34.602-89 Вопросы и ответы
|
|||
|---|---|---|---|
|
#18+
"iscrafm" <nospam@sql.ru>; wrote in message news:3078987@sql.ru... Hi! > Что-то я совсем плохо Вас понимаю. Зачем садить > m пользователей, если система на двух тормозит? > Задаю такой же вопрос, как и заказчик из Вашей байки. > На 3000 быстрее станет? При чем здесь автомобили? Автомобили здесь притом, что это конвейер. Если один автомобиль делают месяц, то это не значит, что при полной загрузке конвейера за день мы получим только 1/30 часть автомобиля. Можно получать целый каждую минуту. Следовательно, из того, что 2 юзера тормозят никак не следует, что 3000 будут тормозить в 1500 раз сильнее. Есть распределенная конвейерная обработка данных. Например, в микропроцессорах. Пока запрос проходит все этапы конвейера, время получения ответа будет больше, чем если его обрабатывать целиком за один этап. Однако при полной загрузке конвейера время получения каждого ответа не изменится, хотя конвейер в целом будет выдавать значительно больше ответов в единицу времени, чем если бы этап был один (совсем без конвейера). Можно посчитать, кто быстрее перевезет лимон тонн груза. Одна фура на 10 тонн или 10 газелей по 1 тонне. Очевидно, что газели быстрее. Пока фуру грузят, она не двигается. А когда двигается, грузчики простаивают без дела. ____________________________ С уважением, Лисеев Дмитрий. http://private.peterlink.ru/dimik/ PGP key fingerprint: 09 28 74 28 6C 39 62 29 2E CB 95 03 4F 04 33 73 Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2006, 23:43 |
|
||
|
ГОСТ 34.602-89 Вопросы и ответы
|
|||
|---|---|---|---|
|
#18+
Dmitry V. Liseev Следовательно, из того, что 2 юзера тормозят никак не следует, что 3000 будут тормозить в 1500 раз сильнее. Конечно не следует. Из этого только следует то, что не нужно тестировать на 3000 пользователях, если уже на 2-х тормозит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2006, 00:34 |
|
||
|
ГОСТ 34.602-89 Вопросы и ответы
|
|||
|---|---|---|---|
|
#18+
mcureenabИМХО, детализация тут ни при чём. ТЗ детально описывает ЧТО должна научиться делать система. Проектная документация (если я правильно тебя понял) - КАК система будет это делать. Т.е. проектная документация не детализирует требования (требования должны быть атомарными), а специфицирует их с точки зрения реализации. ЧТО и КАК, это не разные уровни абстракции или детализации, а разные точки зрения на предмет. ЧТО - внешний вид предмета, КАК - внутренняя организация предмета. Комплект ТЗ на все версии системы позволяет нам судить о системе в целом, но отдельно взятое ТЗ в общем случае не даёт представления о системе. Например, если в очередной верии требуется, чтобы система работала на UNIX, то в ТЗ будет только требование относительно поддержки UNIX и больше ничего. Что это за система из этого ТЗ мы не поймём. Если это именно версия ТЗ, то оно включает в себя всю информацию о системе: информацию из дополнений и неизменившуюся информацию из предыдущих версий. Неполная информация может быть в дополнении к ТЗ, а в нем должна стоять обратная ссылка на ТЗ. При этом дополнение будет неотъемлемой частью ТЗ, а ТЗ с дополнением неотъемлемой частью договора. Таким образом всегда есть пакет документов, в котором есть полная информация. Если есть ТЗ на подсистему, то оно так же будет неотъемлемой частью пакета ТЗ вместе с ТЗ на полную систему. А по поводу детализации: КАК всегда предвращается в ЧТО и наоборот. Пример: ЧТО: Кормить семь. КАК Достать денег, Купить еду или КАК пойти на охоту, принести дичь дальше КАК превращается в ЧТО ЧТО заработать денег КАК освоить профессию, устроиться на работу или КАК продать квартиру, начать бизнес или КАК купить лотерейный билет, выиграть деньги Когда вы говорите ЧТО вам надо, вы не знаете КАК, но уже можете сформулировать критерии и ограничения. Например: заработать деньги в размере $1000 в месяц законным путем. Это и будет ТЗ. Но иногда можно грубо наметать, КАК надо достигать цели - это и будет UC ПРИМЕР .... ЧТО1: Кормить семь. -Достать денег (см ЧТО2) -Купить еду (см ЧТО3) ЧТО2: Достать денег -Учиться (см ЧТО21) -Работать (см ЧТО22) ... И это тоже будет ТЗ, так как это взгляд пользователя, ставящего задачу. В какой-то момент чтобы увеличить уровень описания системы мы должны перейти из одного слоя в другой: изменить уровень абстракции или сменить точку зрения. ТЗ, если угодно - это точка зрения пользователя на систему, предусловия и постусловия. При разработке точка зрения меняется на взгляд изнутри и там есть свои точки зрения и уровни абстракции. Но иногда перед разработкой уже фиксируются некоторые непользовательские характеристики системы: платформы, технические стандарты, условия сопряжения с имеющимися системами и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2006, 12:17 |
|
||
|
ГОСТ 34.602-89 Вопросы и ответы
|
|||
|---|---|---|---|
|
#18+
mcureenab BoatmanЧтобы не страдать раздвоением личности, когда модель расходится с требованиями, в описанном случае предлагаю разбить исходный UC на два и связать их отношением extends. Тогда не придется мучительно выделять из UC, который сам по себе может быть записан в ТЗ, какие-то волшебные требования и отслеживать их сложные отношения с исходной моделью. Декомпозиция UC усложняет модель, тогда как выделение подмножества требований на модель не влияет. Согласен, что полное соответствие модели и создаваемой системы облегчает жизнь, но менять модель только из-за того, что заказчик в последний момент перед подписанием ТЗ отказался от реализации части требований может быть не удобно. К стати, в какой форме ты предполагаешь запись UC в ТЗ? Это будет набор сценариев или как? Как запись UC согласуется со стандартной структурой ТЗ? ИМХО не менять модель (выделенные слова) можно только если она выбрасывается сразу после подписания ТЗ при условии, что в ТЗ или в его дополнении будет написана суть вносимых изменений. Иначе, мы теряем информацию. Если просто в работу что-то не пойдет, можно не разрабатывать трассируемые из выкинутого архитекурные элементы. При этом модель уже не сможет служить для обзорного взгляда на систему (получается: здесь играем, здесь не играем). Если в модели наступили неучтенные изменения, вы не сможете с ней дальше работать. Как записать UC в ТЗ уже выше пережевано: заголовок UC - это функция. Сценарий UC - это спецификация функции. Можно выделить раздел со спецификациями, если неудобно затаскивать спецификации в функциональные требования. Можно этот раздел вынести в приложения. Кроме заголовка UC функциональное требование может явно включать ссылки на актеров, запись предусловия, постусловия и дополнительные требования (ограничения и допущения), которые к ней относятся. А так же что-то еще, что я забыл указать. Может случиться так, что атомарными функциональными требованиями станут не UC, а элементы сценария, когда на сами UC, будет неудобно подвешивать ограничения и критерии. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2006, 12:50 |
|
||
|
ГОСТ 34.602-89 Вопросы и ответы
|
|||
|---|---|---|---|
|
#18+
Boatman Если это именно версия ТЗ, то оно включает в себя всю информацию о системе: информацию из дополнений и неизменившуюся информацию из предыдущих версий. Неполная информация может быть в дополнении к ТЗ, а в нем должна стоять обратная ссылка на ТЗ. При этом дополнение будет неотъемлемой частью ТЗ, а ТЗ с дополнением неотъемлемой частью договора. Таким образом всегда есть пакет документов, в котором есть полная информация. Если есть ТЗ на подсистему, то оно так же будет неотъемлемой частью пакета ТЗ вместе с ТЗ на полную систему. Слава Богу! Вернулись к ГОСТу. Речь не о версии ТЗ, а о версии системы. В ГОСТе нет прямых указаний относительно содержания ТЗ на версию системы, однако сошласно п. 1.6 в ТЗ включают только те требования, которые дополняют требования к системам данного вида,... содержащиеся в действующих НТД... Видимо, ТЗ на прежние версии АС относятся к НТД. Таким образом ТЗ в общем случае включает только часть требований. Кроме того, нафига писать в ТЗ, например, порядок монтажа системы, если оборудование уже давно смонтировано? Возможно, ТЗ на новую версию АС допустимо оформлять дополнением к ТЗ. Тогда вопрос, кто как поступает в этом случае? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2006, 12:56 |
|
||
|
ГОСТ 34.602-89 Вопросы и ответы
|
|||
|---|---|---|---|
|
#18+
Кормить семью, достать денег, это пакеты требований. Требования - учиться, работать, покупать еду, то есть именно этим и будет заниматься система, для того чтобы кормить семью. Очевидно, что мы забыли про покупку посуды и дров для приготовления пищи, таким образом наша система не сможет накормить семью (разве что сырым мясом), но это не наша проблема, а проблема заказчика, если он подписал такое ТЗ. Возможно заказчик сыроед. Если заказчик не детализирует своё требование, то оно остаётся требованием (атомарным), а его реализация остаётся на усмотрении разработчика, если детализирует, то такое "требование" превращается в пакет атомарных требований. Дальнейшая декомпозиция требований может происходить на стадии технического проектирования, п. 5.3 Разработка ТЗ на разработку изделий для комплектования АС. Но это уже будут требования исполнителя к подрядчикам в рамках проектного решения принятого исполнителем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2006, 13:24 |
|
||
|
ГОСТ 34.602-89 Вопросы и ответы
|
|||
|---|---|---|---|
|
#18+
BoatmanКогда вы говорите ЧТО вам надо, вы не знаете КАК, но уже можете сформулировать критерии и ограничения. Например: заработать деньги в размере $1000 в месяц законным путем. Это и будет ТЗ. Но иногда можно грубо наметать, КАК надо достигать цели - это и будет UC Хм. ИМХО, тут мы имеем дело с переходом от бизнес требований к техническим требованиям, который выполняется на стадии 2 Разработка концепции АС, этап 2.1 Проведение НИР. Грубость недопустима. UC должен в точности отвечать бизнес требованиям заказчика, иначе ожидания заказчика будут обмануты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2006, 13:35 |
|
||
|
ГОСТ 34.602-89 Вопросы и ответы
|
|||
|---|---|---|---|
|
#18+
авторКонечно не следует. Из этого только следует то, что не нужно тестировать на 3000 пользователях, если уже на 2-х тормозит. если время отклика, скажем, 20-30 с. на 2 пользователях и на 3000 то это не про тормоза. Просто в ТЗ не оговорено как тестировать (и что) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2006, 13:41 |
|
||
|
ГОСТ 34.602-89 Вопросы и ответы
|
|||
|---|---|---|---|
|
#18+
mcureenab Слава Богу! Вернулись к ГОСТу. Речь не о версии ТЗ, а о версии системы. В ГОСТе нет прямых указаний относительно содержания ТЗ на версию системы, однако сошласно п. 1.6 в ТЗ включают только те требования, которые дополняют требования к системам данного вида,... содержащиеся в действующих НТД... Видимо, ТЗ на прежние версии АС относятся к НТД. Таким образом ТЗ в общем случае включает только часть требований. Кроме того, нафига писать в ТЗ, например, порядок монтажа системы, если оборудование уже давно смонтировано? Возможно, ТЗ на новую версию АС допустимо оформлять дополнением к ТЗ. Тогда вопрос, кто как поступает в этом случае? ТЗ на версию АС - это не НТД, а ТЗ на аналогичную систему. Если новая версия получается путем незначительной доработки, предлагаю смотреть в сторону термина "модернизация". Это не будет ТЗ на вновь разрабатываемую систему - это будет ТЗ на модернизацию. Требования к монтажу вы не указываете, если такие работы производиться не будут. Так же вы не указываете все остальное, что не нужно в ТЗ как на новую систему, так и на модернизацию. И еще вопрос: если в следующей версии есть только дополнения функционала, то можно работать со старым ТЗ и дополнениями. Но есть порог за которым удобнее выпустить новое ТЗ. Я не понимаю причин, по которым Вы не хотите видеть все требования к системе в одном документе. mcureenabХм. ИМХО, тут мы имеем дело с переходом от бизнес требований к техническим требованиям, который выполняется на стадии 2 Разработка концепции АС, этап 2.1 Проведение НИР. Грубость недопустима. UC должен в точности отвечать бизнес требованиям заказчика, иначе ожидания заказчика будут обмануты. Вот мы и приходим к тому, что UC специфицирует и цель и средства. Это вариант, когда пользователь утверждает технологию работы с системой до начала разработки. При этом UC не перестает быть набором требований. В ТЗ по ГОСТ для целей создания системы есть раздел (это самые крупные UC этапа бизнес-анализа) Для UC промежуточного уровня в ТЗ явного места нет, но разрешено ввести доп. раздел. UC самого нижнего уровня или элементы их сценариев отражаются функциями и подфункциями. А на каком этапе впервые выявляются эти элементы - это уже вопрос принятой методологии. Если у нас есть результаты НИР - это основания для разработки к ТЗ, их можно приложить к ТЗ, тогда UC диаграмма будет там. Все это опять к тому же вопросу: куда класть UC в ТЗ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2006, 13:52 |
|
||
|
|
start [/forum/topic.php?fid=33&startmsg=33954935&tid=1549017]: |
0ms |
get settings: |
8ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
81ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
59ms |
get tp. blocked users: |
1ms |
| others: | 269ms |
| total: | 446ms |
| 0 / 0 |
