Тактико техническое задание
Тактико техническое заданиеСкачать файл - Тактико техническое задание
Тема разработки технического задания постоянно обсуждается на различных форумах. Этот вопрос настолько широкий, что ответить в двух словах никак нельзя. Поэтому я решил написать большую статью на данную тему. В процессе работы над статьей я понял, что уложить все в одной статье не выйдет, так как получится под 50 страниц и решил разбить ее на 2 части:. О каких вариантах я говорю:. Клиент имеет своих специалистов со своими взглядами, и они предъявляют конкретные требования к Техническому заданию;. Этот список может быть бесконечным. Говорю так уверенно от того, что уже 15 лет в профессиональной разработке программного обеспечения, а вопрос о Технических заданиях всплывает в любом коллективе разработчиков, с кем приходиться работать. Как правило, те, кто любит умничать на форумах попробуйте все-таки поискать! А тем, кто действительно серьезно занимается вопросом, обычно некогда сидеть на форумах. Про ГОСТЫ, кстати, мы тоже поговорим. В разные годы своей работы мне приходилось видеть множество вариантов технической документации, составленной как отдельными специалистами, так и именитыми командами и консалтинговыми компаниями. Иногда еще я занимаюсь такой деятельностью: В результате приходилось видеть документацию и по таким монстрам, как ГазПром, РЖД и много других интересных компаний. Конечно же, я соблюдаю политику конфиденциальности, несмотря на то, что эти документы попадают ко мне из общедоступных источников или безответственности консультантов разбрасывают информацию по интернету. Как ни странно, проблемы у всех одинаковые! Именно потому, что цели у проектов бывают разные, как и пользователи этих документов. И, конечно, компетенции непосредственных специалистов не на последнем месте. Конечно, получится в сжатом виде, так как вопрос достоин целой книги кстати, идея, а может написать? Да, действительно существуют ГОСТы и стандарты, в которых предприняты попытки регламентировать эту часть деятельности разработки программного обеспечения. Когда-то все эти ГОСТы были актуальны и активно применялись. Сейчас существуют разные мнения по поводу актуальности данных документов. Одни утверждают, что ГОСТы были разработаны очень дальновидными людьми и до сих пор актуальны. Другие говорят, что они безнадежно устарели. Возможно, кто-то сейчас подумал, что правда где-то по середине. Я бы ответил словами Гете: Ни в коем случае! Так вот, между этими мнениями истины нет. Потому как ГОСТы не раскрывают практических проблем современной разработки, а те, кто их критикует, альтернативы конкретной и системной не предлагают. Куда более удачное определение представлено в википедии правда про ТЗ в целом, а не только для программного обеспечения: Техническое задание устанавливает основное назначение разрабатываемого объекта, его технические и тактико-технические характеристики, показатели качества и технико-экономические требования, предписание по выполнению необходимых стадий создания документации конструкторской, технологической, программной и т. Задание как исходный документ на создание чего-то нового существует во всех областях деятельности, различаясь по названию, содержанию, порядку оформления и т. Отличное определение, полностью раскрывающее суть. Впрочем, требования ГОСТа направлены как раз на раскрытие этого определения. Я ни в коем случае не критикую требования ГОСТа, я просто утверждаю, что их там явно недостаточно, чтобы разработать эффективное Техническое задание. И это нормально, ведь есть ГОСТ, например, на изготовление хлеба, и это вовсе не значит, что любой человек может выпечь хлеб по ГОСТу. Кроме ГОСТа требуется знание методик и практик, как в любом деле. Именно этот факт лежит в корне проблемы, которая лежит посерединеJ. А многие специалисты почему-то при необходимости разработать Техническое задание, обращаются только к требованиям ГОСТа. Ну, давайте начнем жить по ГОСТу, посмотрим, что получится! Конечно, есть много отличных! Многое в своей практике я использовал именно оттуда, а когда работал над этой статьей, то тоже нашел много интересных мыслей, которыми рад буду поделиться. Так что, велосипеда изобретать не нужно, но есть потребность систематизировать эти знания. Кстати, любопытный факт, ни одного отечественного автора в этих трудах нет. Вся литература в переводе с западных авторов, но зато каких! Среди них есть просто виртуозы своего дела, у которых есть чему поучиться и нужно это делать. Однако, я увлекся лирикой…. И так, как следует из определения, основное назначение Технического задания — сформулировать требования к разрабатываемому объекту, в нашем случае к автоматизированной системе. Именно основное, но единственное. Настало время взяться за главное: Что необходимо знать о требованиях? Необходимо четко понимать, что все требования нужно разделять по видам и по свойствам. Сейчас мы научимся это делать. Для разделения требований по видам нам как раз поможет ГОСТ. Тот перечень видов требований, который там представлен, является хорошим образцом того, требования каких видов следует рассматривать. Думаю, для Вас очевидно, что ключевым фактором успешного Технического задания являются именно хорошо сформулированные требования к функциональности. Именно этим требованиям посвящено большинство работ и методик, о которых я говорил. Если требования сформулированы плохо, то какой красивый камуфляж на них не натягивай, успешного проекта не выйдет. Да, формально все требования будут соблюдены по ГОСТу J , ТЗ разработано, утверждено и подписано, деньги за него получены. А дальше начнется самое интересное: Если это проект на ГосЗаказе, то проблем нет — там бюджет такой, что ни в какой карман не влезет, в процессе реализации если она будет все и будет выясняться. Все формальности соблюдены, виновных нет, новое авто возле дома. Поэтому давайте разбираться с главным, как разрабатывать полезные и работающие Технические задания. Про виды требований я сказал, а что же со свойствами? Если виды требований могут быть различными зависит от целей проекта , то со свойствами все проще, их Если результат выполнения требования невозможно протестировать, значит, оно либо не понятное, либо не конкретное. Именно во владении этими тремя свойствами требований и заключается мастерство и профессионализм. На само деле все очень просто. На этом повествование о том, что такое Техническое задание можно было бы завершить и перейти к главному: Но не так все быстро. Есть еще один крайне важный момент:. В ответах на эти вопросы кроется очень коварная вещь. Именно поэтому часто возникают споры о достаточности или отсутствии необходимой детализации требований, о понятности документа Заказчиком и Исполнителями, об избыточности, формате представления и т. А где вообще граница между Техническим заданием и Техническим проектом? Техническое задание — это документ, в основе которого лежат требования, сформулированные на понятном обычном, привычном для Заказчика языке. При этом может и должна использоваться отраслевая терминология, понятная Заказчику. Никаких привязок к особенностям технической реализации быть не должно. Если речь идет о внедрении системы на основе уже существующего программного продукта, то такая привязка может иметь место, но только на уровне экранных форм, форм отчетов и пр. Выяснением и формулированием требований, а также разработкой Технического задания должен заниматься бизнес-аналитик. Технический проект — это документ, который предназначен для технической реализации требований, сформулированных в Техническом задании. Как раз в этом документе описываются структуры данных, триггеры и хранимые процедуры, алгоритмы и прочие штуки, которые потребуются техническим специалистам. Заказчику в это вникать вовсе не обязательно ему и термины такие могут быть непонятны. Технический проект делает Архитектор системы вот совмещение этой роли с программистом вполне нормально. А точнее группа специалистов АО главе с архитектором. Чем больше проект, тем и больше людей работает над Техническим заданием. Что мы имеем на практике? Забавно наблюдать, когда директору приносят на согласование Техническое задание, которое изобилует технической терминологией, описанием типов данных и их значений, структуры базы данных и пр. Он, конечно, пытается вникнуть, раз надо утверждать, пытаясь найти между строк знакомые слова и не потерять цепочку бизнес-требований. И чем это заканчивается? А потом начинается сериал про сдачу работ. Вот и мне знакомо, пришлось набить шишек в свое время. Так что мы имеем на практике-то? А на практике мы имеем размытую границу между Техническим заданием и Техническим проектом. А получается так потому, что культура разработки стала слабой. Есть и еще один важный фактор, влияющий на использование Технического проекта как отдельного документа: Но это отдельная история, чуть ниже несколько слов об этом скажу. Еще небольшой, но важный момент. Иногда Техническим заданием называют небольшой кусочек требований, простой и понятный. Например, доработать поиск объекта по каким-либо условиям, добавить колонку в отчет и пр. Такой подход вполне себе оправдан, зачем усложнять жизнь. Но применяется не на больших проектах, а на мелких доработках. Я бы сказал это ближе к сопровождению программного продукта. В этом случае в Техническом задании может быть описано и конкретное техническое решение реализации требования. Это тот случай, когда граница между Техническим заданием и Техническим проектам полностью стирается, так как нет никакой экономической целесообразности раздувать бумаготворчество там, где это не нужно, а полезный документ создается. Не перегрелся ли я? Разве такое возможно, вообще без Технического задания? Представьте себе возможно точнее, встречается , и у такого подхода есть много последователей, и их число увеличивается. Как правило, после того, как молодые специалисты начитаются книг про Scrum, Agile и прочие технологии быстрой разработки. Но фиксирование требований никто не отменял, и там это явно сказано. Как раз там требования и фиксируются исходя из трех замечательных свойств, о которых я говорил выше. Золотые ведь слова, ко всему подходят. Другой вопрос, как составлять и что туда включать. В принципе, я с этим согласен. А что же с Техническим проектом? Данный документ весьма полезный и не утратил свою актуальность. Более того, часто без него просто не обойтись. Особенно, если речь идет о передаче работ по разработке на сторону, то есть по принципу аутсорсинга. Если этого не сделать, есть риск узнать много нового о том, как должна выглядеть система, которую Вы задумалиJ. Спроектировать систему до мелочей практически невозможно. В этом случае придется непрерывно вносить изменения в Технический проект, что занимает немало времени. А если организация сильно забюрократизирована, то вообще все нервы там оставите. Как раз о сокращении такого рода проектирования и идет речь в современных методологиях быстрой разработки, о которых я упоминал выше. Кстати, все они базируются на классическом XP экстремальном программировании - подходе, которому уже порядка 20 лет. Интересная деталь по поводу технического проектирования: В простейшем случае, например создать справочник, документ, достаточно лишь правильно сформулированных бизнес-требований. Об этом говорит и стратегия бизнеса этой платформы в части подготовки специалистов. Таким образом, из двух специалистов, результат работы которых внешне выглядит одинаково, один может экзамен сдать, а второй нет, так как грубо нарушил стандарты разработки. И такой подход работает. Конечно, некоторые уточнения могут выполняться и на этом этапе, но именно уточнения. Сам проект автоматизации не решает проблем бизнеса — помните об этом. Но ведь аксиома на то и аксиома, что доказательств не требует. Как и любую деятельность, формулирование требований можно и нужно разделить на этапы. Это тяжелый интеллектуальный труд. И, если относится к нему с недостаточным вниманием, то результат будет соответствующий. Я придерживаюсь такого же мнения. Хотя 50 — пожалуй, перебор. Ведь Техническое задание — это еще не последний документ, который должен быть разработан. Ведь еще должно быть и техническое проектирование. Такой разброс обусловлен различными платформами автоматизации, подходами и технологиями, применяемыми проектными командами при разработке. Несмотря на то, что формулировка требований является основной частью Технического задания , а некоторых случая она становиться единственным разделом ТЗ, следует обратить внимание на то, что это важный документ, и оформлять его следует соответственно. В первую очередь начать надо с содержания. Составьте содержание, а затем начните его разворачивать. Лично я делаю так: Не знаю, мне так удобнее. Во-первых, это гораздо меньшая часть времени по сравнению с требованиями , во-вторых, пока описываешь всю вводную информацию, настраиваешься на главное. Ну это кому как нравится. Со временем у Вас выработается свой шаблон Технического задания. Для начала рекомендую в качестве содержания взять именно тот, что описан в ГОСТ. Для содержания он подходит отлично! Затем берем и начинаем описывать каждый раздел, не забывая про рекомендации следования трем свойствам: Почему я на этом так настаиваю? Об этом в следующем разделе. А сейчас предлагаю все-такт пройтись по тем пунктам ТЗ, которые рекомендуются в ГОСТе. Итого, 9 разделов, каждый из которых тоже делится на подразделы. Для удобства представлю все в виде таблицы по каждому пункту. А что будет, если не сформулировать цели? Что может оказаться важным и полезным:. Требования к видам обеспечения. Состав и содержание работ по созданию системы. Именно для этого и нужны тестируемые требования. Причины эти могут быть любые: Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие. Таких условий может быть очень много. Например, все сделано и все работает. И все, не хочет принимать у Вас работу. На этот крючок попадали уже многие команды. И так, мы рассмотрели все разделы, которые могут быть включены в Техническое задание. Поэтому, если для Вас очевидно, что какой-то отдельный раздел к результату не приблизит, значит он Вам не нужен и не надо тратить на него время. Но вот без главного: Есть деятели, которые сумеют развести воды по всем разделам, опишут общие требования общими словами, и документ получается весьма увесистый, и слов в нем умных много, и даже Заказчику может понравится то есть он его утвердит. Но вот работать по нему может не получиться, то есть практической пользы от него мало. А особенно, если известно, что дальше дело не пойдет, или его будут делать совсем другие люди. В общем, просто для освоения бюджета, особенно государственного. Почему требования должны быть понятными, конкретными и тестируемыми. Потому, что практика показывает: Тестируемое ли это требование? Как можно было бы это переформулировать: Как проверить тоже не составит труда. Хотя, безусловно, понятное субъективно. Как это видится в реализации? И рассматривать каждый такой случай индивидуально. Можно сформулировать примерно так: Если будут конкретные вопросы, пишите, попробую помочь. Чтобы в Техническом задании было больше конкретики, существует немало рекомендаций. Даже есть перечень слов, которые употреблять в Техническом задании не рекомендуется. Интересно об этом пишет К. Приведу самые интересные и простые, на мой взгляд, рекомендации:. Все, что написано выше, это информация важная, но не самая. А информацию о требованиях надо еще суметь собрать, структурировать и сформулировать. В этом, кстати, много общего между обследованием деятельности предприятий с последующим описанием бизнес-процессов. Но есть и важные различия. В следующей статье мы будем говорить только о методиках выявления требований, а также рассмотрим, что общего между работой по сбору требований к информационной системе и сбору информации для описания бизнес-процессов. Как разработать Техническое задание. Как попасть на страницы комментариев не отправляя комментарии. На вскидку я это не уведел на основной странице темы сообщения. Подскажите пожалуйста как формируется цена написания технического задания , а также сколько стоит тестирование созданного на основании этого технического задания программного продукта. Может быть Вы приведете примеры. Однозначного ответа на этот вопрос Вы не найдете. Обычно полагаются на опыт и экспертную оценку. Если говорить об объективной стоимости, можно следовать следующим рекомендациям: Конечно, тут у Вас возникнет вопрос, сколько будет стоить обследование предприятия? Для этого надо потратить пару дней, чтобы пообщаться с ключевыми управленцами. По результату обследования требуется понять как можно детальнее , что требуется Заказчику. Далее оценивается трудоемкость по времени. В зависимости от стоимости трудовых ресурсов в Вашем регионе формируется цена. По поводу стоимости тестирования: Заказчик хочет готовый продукт и рассматривает тестирование как часть услуг по разработке. Поэтому самое разумное, включать тестирование в стоимость разработки. Если можно, подскажите, пожалуйста речь идёт о СКС: По поводу обязательности ТЗ. С точки зрения ГОСТ, оно быть должно. Но это не имеет отношения к законам. Законодательными нормами не устанавливаются какие-либо требования. Все определяется требованиями конкретного Заказчика к конкретным проектам. Но хорошая практика — это когда соответствующая документация имеется. Это очень правильно, ссылаться на конкретные пункты ТЗ, только так и надо делать! Мне очень нужна Ваша помощь. Я пишу диплом о нематериальных активах и мне нужен образец Технического служебного задания на разработку программы для ЭВМ, заполненный , но можно без наименования предприятия. Небольшое, для наглядности примера. Добрый день, Очень нужная статья, восхищен простотой и доступностью изложения. Я занимаюсь производством пива, изготовлением. Часто приходиться составлять техзадания более краткие и не такие подробные, как Вы рекомендуете , но я вижу, что Вы предлагаете более профессиональный подход, за что я Вам очень благодарен. О чень буду рад профессиональному общению. С уважением Юрий Александрович. Приятно видеть, что есть спецы, говорящие профессионально, по делу. Ваш e-mail не будет опубликован. Диалоги об автоматизации Полезный журнал для ИТ-специалистов и их руководителей. Библиотека Программы 1С Доработки к 1С Контакты. О чем эта статья? Разработка технического задания вызывае вопросы практически у каждого, кто сталкивается в первый раз. В процессе работы над статьей я понял, что уложить все в одной статье не выйдет, так как получится под 50 страниц и решил разбить ее на 2 части: Что это такое, зачем оно нужно, с чего начать и как должно выглядеть? О каких вариантах я говорю: Коммерческая организация решила внедрить у себя автоматизированную систему. Заинтересованное лицо должно разработать Техническое задание и отдать его на разработку сторонней организации; Коммерческая организация решила внедрить у себя автоматизированную систему. Тут все настолько мутно, куча формальностей, откатов, распилов и пр. Я не буду рассматривать такой вариант в данной статье. Это наиболее сложный случай, ведь приходится работать в самых различных условиях: Клиент имеет своих специалистов со своими взглядами, и они предъявляют конкретные требования к Техническому заданию; Техническое задание разрабатывается для собственных разработчиков клиенту все равно ; Техническое задание разрабатывается для передачи подрядчику то есть группе программистов, находящихся за штатом компании, или отдельному специалисту ; Между компаний и клиентом возникает непонимание в вопросе полученного результата, и компания вновь и вновь задается вопросом: Возможно, последний случай кажется парадоксом, но это правда. Возможны и другие, реже встречающиеся варианты; Думаю, сейчас у читателя должны возникнуть вопросы: А почему нельзя разрабатывать Техническое задание всегда одинаково? Кто должен разрабатывать Техническое задание? Должен ли этот человек обладать какими-то специальными знаниями? Как понять, хорошо составлено Техническое задание или нет? За чей счет должно оно разрабатываться, да и нужно ли оно вообще? Если кому-то интересно, о каких ГОСТах я говорю, то вот они: Технические условия; ГОСТ Требования к содержанию и оформлению; ГОСТ Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы. Однако, я увлекся лирикой… И так, как следует из определения, основное назначение Технического задания — сформулировать требования к разрабатываемому объекту, в нашем случае к автоматизированной системе. Требования в функциональности; Требования к безопасности и правам доступа; Требования к квалификации персонала; …. Если виды требований могут быть различными зависит от целей проекта , то со свойствами все проще, их 3: Есть еще один крайне важный момент: Должны ли быть описаны в нем спецификации различных функций, алгоритмы, типы данных и прочие технические штуки? А нужно ли вообще техническое задание? Структура Технического задания Сразу определимся: И так, ГОСТ рекомендует следующие разделы: Можно указать и их роли. Но желательно формулировать конкретно. Лучше сразу написать примерно так: Поэтому, увлекаться не стоит. Требования к системе Рекомендации по ГОСТ Что с этим делать на практике Требования к системе в целом. ГОСТ расшифровывает перечень таких требований: Что может оказаться важным и полезным: Как правила, такие требования инициирует IT-служба Заказчика. Требования к видам обеспечения ГОСТ выделяет такие виды: Конкретное ли это требование? Приведу самые интересные и простые, на мой взгляд, рекомендации: Не следует использовать слов, имеющих множество синонимов. Следует стараться не использовать длинных предложений; Если какое-то требование Вам кажется слишком общим, его необходимо детализировать до более мелких, но конкретных требований; Используйте больше схем, графиков, таблиц, рисунков — так информацию воспринимается гораздо легче; Следует избегать таких слов: Перечень можно продолжать, но, мне кажется идея понятна попробуйте его продолжить самостоятельно. Добавить комментарий Отменить ответ Ваш e-mail не будет опубликован. Тема ColorMag от ThemeGrill.
Разработка технических и тактико-технических заданий и требований
Через сколько приходят деньги на вебмани
Весь этот мир расписание сеансов воронеж
ФОРМА ДОКУМЕНТА, УСТАНАВЛИВАЮЩЕГО ЭТАПЫ НИР
Расписание маршрутки рязань болошнево
ТАКТИКО-ТЕХНИЧЕСКОЕ ЗАДАНИЕ
Гуманизмкак понятиеи способ бытия человека
Расписание электропоезда адлер гагра
Какой гель лак лучше держится на мастеров