Этап первый - техническое задание

Т.е. это еще не ТЗ, а самый первый документ - кто такой клиент, как происходят его бизнес-процессы, какие есть проблемы в бизнес-процессах и что хотелось бы улучшить с помощью планируемого продукта.

Обозвал бы такой шаблон методикой проведения предпроектного обследования. Чтобы его разработать, неплохо было бы поискать ГОСТы по предметной области. Например, ГСДОУ и ГОСТ 6.30 для документооборота. Многое зависит от предметной области.

А "выходной" документ может называться отчетом о проведении предпроектного обследования (ППО) и разрабатываться на основе ГОСТ 7.32-2001.

У меня такая задача - переработать шаблон документа для сбора требований к разрабатываемому ПО (судя по всему это client requirements).

Т.е. это еще не ТЗ, а самый первый документ - кто такой клиент, как происходят его бизнес-процессы, какие есть проблемы в бизнес-процессах и что хотелось бы улучшить с помощью планируемого продукта.

По этому поводу я нашла следующее:
С.Орлик, Ю.Булуй. Программная инженерия: Программные требования (по SWEBOK) - извините, файл оттуда убрали, я не нашла, где он еще есть...
Вигерс Карл. Разработка требований к программному обеспечению.
Ну и наш собственный первоначальный шаблон, а также документы, которые в прошлом по этому шаблону разрабатывались. Формат - документ MS Word.

Нахожусь в процессе чтения.
Вопрос номер раз - что еще можно посмотреть.
Просто ТЗ будет, как я понимаю, разрабатываться на основе этого документа, т.е. он должен быть максимально тщательно подготовлен (причем, подготовкой конкретных требований для каждого клиента буду заниматься уже не я, моя задача - разработка шаблона).
Таким образом, требования из ГОСТ 19.201-78 сюда не совсем подходят

- они более конкретны и предназначены для ТЗ... или все же их тоже лучше рассмотреть и по возможности прописать уже на первом этапе сбора требований?...

P.S. Я пишу подробно, может потом кому-то с аналогичными заморочками пригодится...
P.P.S. Или все-таки стоит подумать о том, что "незаменимых нет" и не разрабатывать идеальный шаблон, по которому каждый дурак составит требования? ))))

Ирина, тематика

(хнического задания?)
представляет огромный интерес. Только Вам лучше зарегистрироваться, иначе в форуме не будет у Вас никаких прав.

Что имеете в виду под электронным учебником?

ОПИСАНИЕ ПРИМЕНЕНИЯ (ГОСТ 19.502-78)
- назначение программы*;
- условия применения**;
- описание задачи***;
- входные и выходные данные*****

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА (ГОСТ 19.404-79)
- введение*****;
- назначение* и область применения**;
- технические характеристики;
Раздел «Технические характеристики» должен содержать следующие подразделы:
· постановка задачи на разработку программы, описание применяемых математических методов и, при необходимости, описание допущений и ограничений, связанных с выбранным математическим материалом***;
· описание алгоритма и (или) функционирования программы с обоснованием выбора схемы алгоритма решения задачи, возможные взаимодействия программы с другими программами****;
· описание и обоснование выбора метода организации входных и выходных данных*****;
· описание и <обоснование> <выбора> состава технических и программных <средств> на основании проведенных расчетов и (или) анализов, распределение носителей данных, которые использует <программа>.
- ожидаемые технико-экономические показатели******;
- источники, использованные при разработке.

ТЗ (ГОСТ 19.201-78)
- введение*****;
- основания для разработки;
- назначение разработки*;
- требования к программе или программному изделию****;
- требования к программной документации;
- технико-экономические показатели;******
- стадии и этапы разработки;
- порядок контроля и приемки;
- в техническое задание допускается включать приложения.

Готово. Открываю топик? Я бы назвала его СКВОЗНАЯ ЗАДАЧА по разработке ТЗ, но не уверена, что все поймут о чем речь... Впрочем, так и назову, а если Вы придумаете что-то получше, переименуете.

Хорошо, попробуем.

А если я такая хорошая, что от меня просто так не сбежишь ???

А если серьезно, если есть время (или попозже, когда будет), можно открыть топик, где я выступлю в роли закзазчика, абы как определю задачу, а Вы покажете, что именно ему надо говорить. Далее, когда задача станет понятной, я бы написала к ней ТЗ, а Вы его покритиковали и все это можно выложить на сайте как сквозной пример.

Права, конечно. Можно обойтись и без проектной документации и слить все в ТЗ. Но, заполучив такое детальное ТЗ, Заказчик может сделать тёте ручкой и уйти к другой - ведь у него полностью разжеванный документ.
А вот если заставить Заказчика подписать небольшое ТЗ, содержащее только его формализованные хотелки, то работа будет открыта, и Заказчику так просто уже не уйти. А детали потом в пояснительной записке.

Если Заказчик внутренний, свой, то это все не смертельно. А внешний точно сбежит.

ЭТО ДА!
И все-таки уже в ТЗ я хочу КАЖДУЮ ЗАДАЧУ разбить на небольшие логичкие задачки, описать их и К КАЖДОЙ из них писать функции и организацию входных и выходных данных. Может, я и не права... Время покажет...Но пока у меня другого выхода просто нет...

Короче, в ТЗ пишем требования Заказчика, а после согласования и утверждения расписываем в пояснительной записке все детали. И ее согласовываем и утверждаем. Иначе - труба.

Было такое. Сдавал одну софтину, а Заказчику то шрифт мелковат (переделал, снова попытался сдать софтинку). Заказчику кнопочка не понравилась. Переделал, снова сдача работы. Не, сказал Заказчик, давай-ка ту кнопочку вернем взад, а разместим ее левее и выше.

Товарищ меня полгода мурыжил. Потом я уперся, расписал проект со скриншотами в цвете, и заставил Заказчика подписаться даже под каждой картинкой. И все, сдал с первого раза.

Более того, Заказчик, меня терзая, кое о чем забыл, не указал в ТЗ. И тут уж я отыгрался - извини, родной, в ТЗ не предусмотрено. Если хочешь - открываем новую работу, в новые сроки за новые деньги

Раньше, при первой же сдаче работы
Можем поиграть в командно-штабную игру, если есть время. Вы - Исполнитель, я - Заказчик. И сразу все на свои места встанет.

Это да...
а я поняла, что мне не нравится в ГОСТовских ТЗ, но умолкаю...
а) потому что умные люди их писали (хотя косяков хватает...)
б) потому что небольшой опыт. Как знать, мож, через пару лет мне это все смешным покажется, а ГОСТы будут типа Отче наш...

А море где-то далеко от нас

Короче, голова сегодня никакая, но убедился лишний раз, что функции и задачи все равно расписывать придется, поскольку без них ПМ не получится. А без ПМ заказчику работу не сдать.

кроме одного = А ГДЕ МОРЕ????????

Чтобы быть в тонусе, нужно, чтоб тонус был в тебе (из рекламы соков)
мда.... все, в общем-то понятно...

Не, чё то я сегодня не в тонусе

В Программе и методиках испытаний (ПМ):

4.3.2.1. Методика проверки проверки выполнения функции отображения оповещения

Следуя указаниям п. такого-то Руководства пользователя задать время оповещения, равное текущему системному времени плюс одна минута.

В случае отображения в заданное время на экране монитора оповещения считать проверку выполненной успешно.

4.3.2.2. Методика проверки параметров оповещения

Проверка цвета текста оповещения проводится путем визуального сравнения цвета с эталонным.

Эталонный цвет задается в палитре графического редактора такого-то (д.б. указан в ТЗ).

При визуальном совпадении проверку считать выполненной успешно.

Вот такая фигня полезет, и деваться будет некуда. А нумерация пунктов у меня сейчас произвольная.

3.2 - эксплуатационное назначение?

В ТЗ:

3.2.1. Программа должна обеспечивать отображение на экране монитора оповещения в заданное время.

3.2.1.1. Программа должна обеспечивать пользователю возможность программирования (указания, задания) времени отображения оповещения посредством графического интерфейса пользователя.

3.2.1.2. Оповещение должно обладать перечисленными ниже параметрами:

а) текст оповещения должен быть зелененьким (код цвета RGB);
б) размер шрифта текста оповещения д.б таким-то;
и) шрифт текста оповещения д.б. таким-то и т.д.

и пущай Заказчик подписывает, такая формулировка должна его устроить.

"обеспечивать отображение на экране" - то же самое, что и "обеспечивать решение задачи отображения на экране", просто форма скрытая.

Много хочет

Именно поэтому в ТЗ пишется, ЧТО хочет видеть Заказчик, а проектной - КАК решено реализовать хотелки Заказчика.

Если в ТЗ прописать, что программа должна обеспечивать зелененькое предупреждение, а в проекте не расписать, как и какое именно (графическое или текстовое, какие шрифты, какие размеры, положение на экране и т.д.), Заказчик будет вести себя, как дама в интересном положении. Своими "хочу-не хочу" всю душу и нервы вымотает. И работу Вы ему не сдадите ни за что.

Поясните Заказчику:

1. что есть ГОСТы - определенный порядок разработки документов;
2. спросите его, как он намерен принимать у Вас "зелененькое в 18.00";
3. предложите ему самому сформулировать требования ТЗ, а потом разбейте его формулировки в пух и прах, ткните носом, покажите, что он сильно неправ.

Может, тогда он поймет, что требования должны быть четкими, конкретными и не допускающими возможность разночтения.

Что-то типа:
программа должна обеспечивать возникновение в 18.00 на экране монитора зеленого предупреждения о том, что пользователю пора домой, для этого она должна:
- .... функции системного времени;
- .... функции графического ....

ДА, там есть кое-что... Но задачу, которая стоит предо мной это не решает. Если описывать по этим ГОСТам, то, например:
"программа должна обеспечивать
1. функции определения системного времени;
2. функции отображения информации в графическом виде;
... и т.п. Заказчик не видит в этом поставленной собой задачи, и ВЕДЬ ОН ПРАВ!!! Сказать ему, извините, так должен оформляться документ, я НЕ МОГУ!!! - я понимаю, что незачем ему тратить драгоценное время на расшифровку всего этого... Он хочет видеть на экране в шесть часов вечера зелененькое предупреждение о том, что пора домой, и он хочет, чтобы его слова были в ТЗ именно об этом, а не о том, какие ф-ции будет обеспечивать...
Наверное, есть смысл сделать это прямо в ТЗ без др. документов (ведь подписать-то он ТЗ должен!)

Кстати, рекомендую разделы ТЗ на софтину дополнять разделами ТЗ на систему - http://www.nist.fss.ru/hr/doc/gost/34-602-89.htm

Там очень много требований, которых, на непросвещенный мой взгляд, не хватает в ТЗ по ГОСТ 19-201.

Ага, я согласна, только это замечание к разработчику ГОСТа.
Я, кстати, пока читала и руководствовалась ГОСТами, не видела, сколько в них недочетов...

Моя ошибочка!

Это тоже - к разработчикам ГОСТа

Изготовления не надо, есть уже разработка.

АС, кажись, тоже здесь не должно быть.

Достаточно "регламентирующей".

А так все довольно ровно выглядит. Мне сейчас трудно дать оценку, поскольку нет под рукой методических указаний с Госстандартовских курсов, да и занятия по разработке стандартов, как сейчас помню, прогулял
Посмотрю дома.

Выслала самое общее и почти полностью слизанное с ГОСТа. Надеюсь, Вы скажете, что ЭТО имеет право быть, и не противоречит никаким законам...

Мы тоже, и не жалеем. Универовские какие-то все бестолковые, почему-то уверены, что они умные, а мы, технари, должны обеспечивать им возможность работы. Причем все без исключения, от студента до профессора

Там хитростей и тайных подлостей много. Как очухаюсь немного, отсканирую методические указания на эту тему и выложу. А СтО высылайте, интересно же

Уж полгода софтинку пользую, а слюнки все текут Самое сложное -собрать отцов-командиров и устроить им показуху. Как сообразят, что софтинка эта позволяет, так $450 на бочку и выложат. А обосновать можно, скачав аналитическую записку - http://ergd.ru/HTML/?c=4

СтО - расш. как стандарт организации ???? Ну... мы университетов не кончали Куда уж нам уж
А если серьезно, то насколько надо осторожничать? Есть какие-то законы? А нельзя взять соответствующие ГОСТы и, со ссылками на них, разработать???
Алексей, можно выслать Вам написанный СтО, как я его понимаю?

Огромное спасибо за возможность повозиться с Author IT. Повозилась совсем немного, но уже слюнки текут... Не сейчас, но все-таки я надеюсь уговорить начальство, что это нужно!

Насчет СтП (теперь это называется СтО) - поосторожней Это целая наука, сегодня ее постиг (в некоторых рамках).

Разумнее разработать один проектный документ с требумыми разделами и обозвать его Пояснительной запиской. ТЗ - само собой, то там только требования, что делать. А в проектном документе - как это все делать.

Будем называть их Д1, Д2, Д3 соответственно.
Зведочками обозначено то, что так или иначе повторяется в этих трех документах.
А мне на этом этапе работы нужен, собственно, 1 документ, где:
1. Бизнес-процессы, которые будут автоматизированы (1 или 2 звездочки).
3. Описание задачи (3 звездочки)
4. Описание матетатических методов ее решения и (или) логики связей (4 звезд.)
5. Входные и выходные данные (5 звезд)
6. Требования к пользовательским интерфейсам (совсем нет)
7. Ну и всякие там безопасности, контроль, упаковка (есть)

Что делаю я? Я составляю стандарт на требование к моему докумету, который мне нужен на этой стадии работы (вышеописанное) и считаю стандартом предприятия. Я ошибаюсь??????? Нужно-таки, написать эти три документа с повторениями?

пока что я нахожу 3 ГОСТА, по которым размазана моя задача:

ОПИСАНИЕ ПРИМЕНЕНИЯ (ГОСТ 19.502-78)
- назначение программы*;
- условия применения**;
- описание задачи***;
- входные и выходные данные*****

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА (ГОСТ 19.404-79)
- введение*****;
- назначение* и область применения**;
- технические характеристики;
Раздел «Технические характеристики» должен содержать следующие подразделы:
· постановка задачи на разработку программы, описание применяемых математических методов и, при необходимости, описание допущений и ограничений, связанных с выбранным математическим материалом***;
· описание алгоритма и (или) функционирования программы с обоснованием выбора схемы алгоритма решения задачи, возможные взаимодействия программы с другими программами****;
· описание и обоснование выбора метода организации входных и выходных данных*****;
· описание и обоснование выбора состава технических и программных средств на основании проведенных расчетов и (или) анализов, распределение носителей данных, которые использует программа.
- ожидаемые технико-экономические показатели******;
- источники, использованные при разработке.

ТЗ (ГОСТ 19.201-78)
- введение*****;
- основания для разработки;
- назначение разработки*;
- требования к программе или программному изделию****;
- требования к программной документации;
- технико-экономические показатели;******
- стадии и этапы разработки;
- порядок контроля и приемки;
- в техническое задание допускается включать приложения.

НЕТ! Моя задача - описать все эти бумажки так, чтобы было понятно и Заказчику и исполнителю. Желательно сочетать лаконизм с ПОЛНЫМ ОПИСАНИЕМ ВСЕГО. Мне (в моей комании, по крайней мере) неважно, соответсвует ли моя документация ГОСТ, ИССО или др. Но я все равно лезу в ГОСТы, чтобы не изобретать велосипед, а посмотреть, что умные головы наваяли. И что я вижу?