ТЗ на доработку
- Войдите на сайт для отправки комментариев
Возникли задачи (причем сразу несколько 
(() писать ТЗ на доработку уже существующих (но без документации!!!) программ.
Что делать? Пробую писать что-то типа полноценного ТЗ, получается полноценная фигня. Много ненужного, а нужное теряется.
Задачи там типа таких - этот п.Меню сделать невидимым, эту форму недоступной, а в этой форме добавить пару окон...
Ну и т.д. Пока смогла только в произвольной форме описать эту задачу, дескать, есть такая-то программа, в ней есть такие-то п. Меню, такие-то формы, ну и что с ними сделать.
Но это получается не ТЗ, а сочинение на тему... произвольным стилем (по-собачьи, то есть). Вот. Может, кто-то не только сталкивался, но и успешно преодолел? ? А может, есть какие-нибудь документы по этому поводу?
Хорошо. Напишу "Техническое задание на модернизацию системы" (хотя в ГОСТе указано писать только "Техническое задание").
А краткое описание того, что модернизируется на титульном листе не писать?
Меня смущает, что таких "ТЗ на модернизацию" с одинаковым названием через пару лет может оказаться десяток?
Вот же проблему Вы себе придумали 
Пишите так:
1. Общие сведения
Настоящее Техническое задание разработано в соответствии с требованиями ГОСТ 34.602-89.Согласно п. 1.1 ГОСТ 34.602-89 ТЗ на АС является основным документом, определяющим требования и порядок модернизации автоматизированной системы, в соответствии с которым проводится модернизация АС и ее приемка при вводе в действие.
И не парьтесь Это в тексте. А на титульном листе напишите "техническое задание на модернизацию системы".
Судя по ГОСТу, ТЗ на доработку (модернизацию) АС действительно по сути ничем не отличается от ТЗ на создание АС. Однако мне представляется неправильным писать на титульном листе просто название АС без описания того, что нужно изменить.
Если назвать документ: "АБС. Техническое задание", - то это название не отражает содержание документа. Оно создаёт впечатление, что исполнитель должен в целом создать АС. А это неверно, так как АС уже существует. Конечно, Заказчику важно не только добавить возможность формировать новый отчёт, но и сохранить весь существующий функционал. Но суть ТЗ всё-таки не в разработке ТЗ, а в разработке отдельной функциональности. Необходимо как-то отразить в названии документа. Я и спрашиваю, как это корректно нужно сделать.
Оформлять документ как "Дополнение к ТЗ" нельзя, ибо система уже сдана и вообще ТЗ на систему не существует.
ТЗ на модернизацию (доработку) АС ничем не отличается от обычного ТЗ на разработку АС. Оно даже существенно проще, поскольку в нем можно прописать только отличия доработанной системы от существующей.
Вопрос же касался оформления титульного листа. Титульный лист на доработку АС, таким образом, ничем не отличается от титульного листа на разработку АС. Вы, ведь, будете сдавать заказчику не отдельные патчи, а доработанную систему в целом.
Альтернативой является разработка ТЗ на патчи, но я полагаю, что заказчик возжелает принимать не их, а всю систему вкупе с патчами.
Здесь речь идёт о дополнении к ТЗ. А этот документ, насколько я понимаю, разрабатывается в том случае, если:
1) существует ТЗ;
2) акт сдачи-приёмки АС еще не подписан;
3) в ТЗ необходимо внести коррективы/ изменения.
А я спрашиваю о ТЗ на модернизацию АС (доработку)
ГОСТ 34.602-89:
в текст ТЗ на АС изменений не вносят.
3.4. На титульном листе помещают подписи заказчика, разработчика и согласующих
организаций, которые скрепляют гербовой печатью. При необходимости титульный лист
оформляют на нескольких страницах. Подписи разработчиков ТЗ на АС и должностных
лиц, участвующих в согласовании и рассмотрении проекта ТЗ на АС, помещают на
последнем листе.
Форма титульного листа ТЗ на АС приведена в приложении 2. Форма последнего листа ТЗ
на АС приведена в приложении 3.
3.5. При необходимости на титульном листе ТЗ на АС допускается помещать
установленные в отрасли коды, например: гриф секретности, код работы,
регистрационный номер ТЗ и др.
3.6. Титульный лист дополнения к ТЗ на АС оформляют аналогично титульному листу
технического задания. Вместо наименования «Техническое задание» пишут «Дополнение
№ ... к ТЗ на AC ... ».
3.7. На последующих листах дополнения к ТЗ на АС помещают основание для изменения,
содержание изменения и ссылки на документы, в соответствии с которыми вносятся эти
изменения.
3.8. При изложении текста дополнения к ТЗ следует указывать номера соответствующих
пунктов, подпунктов, таблиц основного ТЗ на АС и т. п. и применять слова: «заменить»,
«дополнить», «исключить», «изложить в новой редакции».
Добрый день!
Посоветуйте, пожалуйста, как оформить титульный лист (ТЛ) в ТЗ, если заказчик просит внести "патч" в АС, чтобы в ней были реализованы новые функции.
В 34-м ГОСТе я не нашёл описания того, где в названии документа писать о "модернизации" (доработке, развитии АС).
Допустим, владелец автоматизированной банковской системы АБС просит реализовать в ней возможность формирования отчета О.
Мои версии оформления ТЛ:
- a) Вместо строк "Наименование вида системы", "Наименование объекта автоматизации" и "Краткое наименование системы" пишем: АБС.
Строкой ниже пишем: "Комплекс задач на формирование отчета" O.
Еще ниже пишем: "Техническое задание".
- б) В строке "Наименование вида системы" пишем: АБС.
В строке "Наименование объекта автоматизации" пишем: "Формирование отчета" O.
Еще ниже пишем: Техническое задание на модернизацию".
- в) еще как-то...
[/]
[/]
[/]
Вы можете добавлять в ТЗ сколько угодно дополнительных разделов-подразделов. Например, "Требования к графическому интерфейсу пользователя". И не обязательно в специальные требования - если работаете по ГОСТ 34.602-89, разумнее всего такой подраздел забросить в Требования к информационному обеспечению.
А вот у меня еще такой вопрос.
Требования к интерфейсу ПП (ну, там заказчик кнопочку хочет какую-нить перерисовать) - это к какому пункту ТЗ привесить можно?
Что-то мне кажется - в спец. требования... :roll:
Хотя - лучше бы вынести в отдельный пункт, имхо - уж очень часто встречается именно этот тип требований...
Ну это само собой
бред уставшей от ТЗ девушки
Ну, не надо так переживать . Всегда будьте, прежде всего, бодрой девушкой, а лишь потом разработчицей ТЗ 
.
Ой, нет, все с цитатой нормально. Это я когда первый раз страницу открыла, все кривовато было...а сейчас все хорошо.
Прошу списать это 2 последних сообщения на бред уставшей от ТЗ девушки )
Ужасть! Это я так цитату пыталась вставить 
!! Сорри :?
Тогда возможен такой вариант (если на это согласится Заказчик). В начале ТЗ привести фразу: «Функциональные возможности и технические характеристики доработанной системы определяются функциональными возможностями и техническими характеристиками исходной системы
Vadim спасибо. Наверное на первой итерации так сказать надо предложить этот вариант, а если не согласить, то предется старый функционал вписывать...а этого конечно очень не хотелось бы...Но Заказчик очень придирчивый. Настоящий "Зазазчик" - так сказать
Да, наверное так и предется сделать: вписать старый функционал в ТЗ...А без ТЗ никак нельзя, потому что Заказчик при приемке заявил, что без ТЗ никак нельзя...вот и изворачиваюсь как уж на сковородке
Если писать ТЗ на всю систему как на вновь разрабатываемую, то и отвечать на испытаниях (помните я вас недавно по этому поводу пытала) придется по полному соответствию ТЗ - всему функционалу (то есть даже по тому, что было до нас). А хотелось бы "ответить" только за те функции которые дорабатывались нами.
Тогда возможен такой вариант (если на это согласится Заказчик). В начале ТЗ привести фразу: «Функциональные возможности и технические характеристики доработанной системы определяются функциональными возможностями и техническими характеристиками исходной системы за исключением следующих параметров, оговоренных в настоящем ТЗ». И далее писать о том, что исключается и что добавляется .
так у старой системы нет ТЗ
Посты "перехлестнулись". Если нет ТЗ, то попытайтесь не писать ничего, кроме нового функционала и новых требований к техническому обеспечению, если речь идет о некой "безопасной" системе, работающей на серверах и пользовательских рабочих станциях, и не управляющей каким-нибудь высоковольтным коммутационным оборудованием и т.д.
Но старый функционал выдернуть из руководства и прописать в ТЗ, возможно, тоже придется. Был у меня недавно подобный случай - остановились на том, что новый функционал выделяем в ТЗ цветом
Просто модернизировать можно по разному - дорабатывать коды старой софтины, полностью переписывать все коды. Во втором случае придется вписать в ТЗ старый функционал.
так у старой системы нет ТЗ 
Добавлю следующее - если про безопасность, надежность и прочие мутные вещи в ранее разработанном ТЗ упомянуто, лучше в ТЗ на модернизацию о них не упоминать, или сослаться на старое ТЗ - "требования к... предъявлены в ТЗ на создание системы, дец. номер такой-то".
К сожалению, имеет место самый невероятный, но возможный вариант, когда документации нет никакой (ну кроме руководства пользователя). Если писать ТЗ на всю систему как на вновь разрабатываемую, то и отвечать на испытаниях (помните я вас недавно по этому поводу пытала) предется по полному соответствию ТЗ - всему функционалу (то есть даже по тому, что было до нас). А хотелось бы "ответить" только за те функции которые дорабатывались нами.
вот...
В системе разработки и постановки на производство промышленной продукции (ГОСТ 15) я не нашел такого вида работ (этапа) как «доработка изделия».
Я полагаю по здравому смыслу, что вначале нужно определиться с тем, какая документация имеется на дорабатываемую систему. Если система выпускается серийно, на нее должны быть технические условия. Если до стадии серийного производства дело еще не дошло, должно быть техническое задание на ее разработку. Самый невероятный, но возможный вариант — на систему вообще нет документации. Рассмотрим варианты.
1. Есть ТУ, в которых прописаны технические характеристики системы. Тогда в самом начале ТЗ на доработку системы можно включить фразу: «Система должна удовлетворять требованиям таких-то ТУ (или пунктов таких-то таких-то ТУ), см. Приложение (куда включить эти ТУ)». Затем в ТЗ на доработку включаются только дополнительные требования, которых не было раньше, в той последовательности, как этого требует структура ТЗ.
2. Есть ТЗ на разработку предыдущей системы. Решение напрашивается аналогичное тому, когда есть ТУ.
3. Нет ничего. Тогда придется писать ТЗ в полном объеме как на вновь разрабатываемую систему.
Полагаю, что при таком подходе (если на предыдущую систему есть документы) можно существенно сократить ненужную писанину, и это нормативными документами не возбраняется .
Я примерно тоже самое и делаю. В разделе 4. Требования к системе очень много пунктов, которые при модернизации я вовсе и не затрагиваю. В основном дополняется функционал. Вопрос вот в чем: такие пункты как: требования к безопасности, надежности и т.д. вовсе пропускать (боюсь Заказчик не примет...), или пункты все же сделать, но в тексте каждого пункта писать: При модернизации требований не предъявляется...?
Очень нужна основа/шаблон
Возьмите ГОСТ 34.602, на его основе сделайте шаблон в ворде, например. Создайте документ с разделами и подразделами, так как в ГОСТ указано. Часть уже готовых разделов можете стащить отсюда - http://authorit.ru/?c=3
А потом "фильтруйте базар", пишите, что знаете, не пишите в ТЗ, чего не знаете, а если не знаете, что писать, но понимаете, что такой раздел понадобится обязательно - задавайте вопросы в форуме.
Я тоже теперь столкнулась с написанием ТЗ на доработку системы, Рикки, surgeon поделитесь опытом. Очень нужна основа/шаблон. Я наступала на те же грабли: писала ТЗ на создание, действительного много ненужного...теперь решила все изменить, выбросить многое. Но как найти тот необхдимый минимум?..
Высылайте, но быстро не обещаю, очень здорово пахать сейчас приходится. Что довольно непривычно
Как сможете, конечно!
Пока начну на нем (т.к. все равно НЕ НА ЧЕМ!!!) - какое-никакое решение. Все равно на двух-трех доработках будет обкатываться
Высылаю.
Высылайте, но быстро не обещаю, очень здорово пахать сейчас приходится. Что довольно непривычно
Типичный реинжиниринг
Попыталась разработать шаблон ТЗ НА ДОРАБОТКУ. Хотелось бы критики... Алексей, посмотрите?
иМХО, если это касается экранов, окон и прочих визуальных объектов, то может лучше эту "фигню" представить в стиле набора извещений на изменение???
Типа: В экранной форме №111 было то-то, надо сделать то-то. И скриншотов побольше (чтоб программисты не промахнулись)
Если есть возможность - то подойти формально. А то уж больно муторно ТЗ задним планом писать
ВО, ЧТО Я НАШЛА 
Реинжиниринг основан на концепции прерывистого мышления -- отыскании устаревших правил и фундаментальных допущений, на которых строится работа, и решительном разрыве с ними. Если мы не меняем эти правила, мы просто переставляем стулья на палубе "Титаника".
Типичный реинжиниринг
Подошел бы так: сначала из процедур и операций восстановил бы функции, а уж и наборов функций - задачи. Другого пути не вижу.
Просто надо понять, зачем, с какой целью, для выполнения каких функций софтина делает недоступными кнопки, окошки и т.д. Процесс довольно-таки творческий. Не завидую
- Войдите на сайт для отправки комментариев
А краткое описание того, что модернизируется на титульном листе не писать?
Меня смущает, что таких "ТЗ на модернизацию" с одинаковым названием через пару лет может оказаться десяток?
Даже в старших системах Гост не разделяется ОКР по созданию нового образца от модернизации существующего. Этому есть простое логическое объяснение. Что такое модернизация - улучшение одного или конкретного ряда тактико-технических характеристик образца. Т.е. в результате завершенной модернизации изделие приобретает новые (другие - улучшенные характеристики). Конечно, таких модернизаций может быть много, пока экономическая целесообразность не покажет, что модернизация уже будет дороже, чем создание нового, по новейшим технологиям.
Поэтому на титульном листе надо писать "ТЗ на модернизацию изделия (системы, объекта) такого-то". Все равно в разделах "цель ОКР", "задачи ОКР" Вы однозначно будете определять, чем эта модернизация отличается от, скажем, предыдущей...
P.S. Посмотрите, на всякий случай, то, что есть сейчас в образце - обычно заказчик по ТЗ на ОКР закладывает проработку вопроса о возможностях и степени последующих модернизаций. В материалах ЭП, ТП Вы можете обнаружить для себя весьма интересные моменты.
С уважением, Михаил