Comments 21
Надо бы переслать статью или ссылку на неё в комитеты/комиссии (что там ещё?) по импортозамещению ;)
Это видимо юмор, т.к. это не продукт чтобы им замещать что-то, да и ГОСТы которые я упоминаю наши российские, да и они неплохие впрочем, качество технических заданий на госзаказе вполне приличное. Просто на малобюджетном коммерческом рынке мало кто их придерживается зачастую и технические задания очень абстрактные и сулят большие проблемы при приемке. А тот вариант который я описал может помочь грамотно структурировать ТЗ не вдаваясь в тонкости сложного описания по ГОСТу
Вникать в тонкости описания по ГОСТу требуется, только если у вас есть госзаказ. Если вы уже доросли до того, что имеете шанс получить госзаказ, то и с ГОСТами уже сможете разобраться.
На госзаказ могут выйти и небольшие компании, есть даже специальные категории тендеров, только для субъектов МСП. И действительно нет проблемы с ними разобраться. Речь не о том чтобы упразднить применение ГОСТов, там где они сейчас используются. Но в небольших коммерческих контрактах тоже не помешало бы чуть более серьезно относится к техническому описанию.
Так начиналось десятилетие науки и технологий
Ну извините, видимо мои скромные труды не помогут вам гордиться отчизной. Спасибо за политическую ноту
Это же был сарказм, или я вас неправильно понял ?
Да нет, не сарказм. Скорее сожаление внутреннее по поводу происходящего и грядущего, судеб отчизны и ее людей. Горько осознавать, что тем, кто не уедет, единственная область применения останется на госконтрактах. В любом случае, не имел намерения вас обидеть.
Да, и мне тяжело, но ты не волнуйся. У нас великая страна, мы были первые в космосе, Менделеев изобрел таблицу Менделеева, и хоть мы не научились делать красивые машины, но во многих областях нам нет равных. Мы бы не пропали даже если бы оказались на единственном континенте, окруженном мировым океаном. Нужно только верить друг в друга и поддерживать, не важно где ты, важно кто с тобой рядом.
Дмитрий, во первых РД 50-34.698-90 не является ГОСТом, во-вторых, он отменен в 2019 году, а в третьих, в этом году вступил в действие ГОСТ Р 59795-2021, вместо этой РД-шки.
Если у вас в одной строке столько неточностей, то и остальное читать, видимо, не стоит.
Спасибо обновил. Не сказать что я слежу за изменениями в ГОСТах, а то что указанная РД была отменена, еще не повод не требовать его соблюдать. И как вы понимаете разбираться во всех тонкостях ГОСТов не просто для обывателя, даже если ты имел опыт с ними работать.
Т.е. подчеркну что эта статья не для таких корифеев как вы, а скорее для тех кто в ГОСТы не погружался.
Но это для студентов. Что из этой заметки может почерпнуть чувак, которому надо писать техническое задание, мне неведомо. «Укажите в ТЗ цели, задачи и требования». Ну ок. А я-то там хотел написать пасхальное поздравление, автобиографию и считалочку. А вон оно как что надо было…
Все гениальное просто. Очень хорошо если вы понимаете как и зачем это писать, а также описываете требования к подсистемам и именно в такой последовательности, а не просто перечисляете список пожеланий за циферками. Это базис который необходим, но мало кто так делает. А также полезно описать сценарии применения, вот это обычно никто в техническом задание не пишет, даже по ГОСТу, там это появляется уже перед этапом приемки, и называется "программа и методика испытаний". А если включить это в требования, то это будет как "Бритва Оккама", для описания подсистем, и фактически исключит двусмысленность в формулировках. Возможно вы живете в мире где все друг друга понимают, но на практике зачастую, то что говорят, как это понимают и что имелось ввиду, обычно как выясняется разные вещи. И это не для студентов, как вы правильно заметили.
Для нестудентов есть универсальная формула: "Больше бумаги - чище ***а".
Очень хорошо если вы понимаете как и зачем это писать, а также описываете требования к подсистемам и именно в такой последовательности,
Ну а почему именно в такой последовательности? Я, например, предпочёл бы видеть «Описание объекта автоматизации» либо на первом месте, либо вообще отдельным документом. А сценарии применения вполне логично разместить после целей. Потому что описание объекта автоматизации — это «что мы имеем сейчас, цели — его хотим добиться, сценарии применения — то, как это должно выглядеть, и задачи — то, как это нужно сделать. Но опять же таки, у кого-то может быть иное видение и/или потребности в документировании. ГОСТы в данной сфере, это ведь даже не набор „best practices“, а всего лишь один, согласованный на государственном уровне, формат.
Цели, задачи и требования к подсистемам, это в некотором роде базис описания, в котором формулируется, что и как должно быть реализовано. А сценарии, они ближе к приемочным испытаниям которые по логике возникают позже, к тому же будет сложно описать как пользоваться системой которая еще не описана. Т.е. в требованиях к подсистемам мы, в том числе, например, описали интерфейс включая кнопки на нем и логику их работы, какие-то сервисы и т.д., и вот уже в сценариях мы пишем что нажали такую-то кнопку, произошло то-то, перешли в другой интерфейс под другим юзером и увидели там какие-то объекты, с опциями и т.д. Конечно нужно понимать что нужно сделать до того как описывать требования к подсистемам, но они все же должны формироваться исходя из задач. Например если у нас есть цель: "автоматизация выпуска эцп" и задачи: "реализовать возможность юзера сделать запрос на выпуск эцп", "интеграция с налоговой в части формирования запроса", "реализовать функционал активации выпущенной эцп юзером" и т.д.. Так вот на основание этого и формируется образ системы, а сценарии фактически уже, в некотором роде, демонстрируют как этим можно будет пользоваться, на сколько это юзабельно и удовлетворяет требованиям. И вот после формирования и анализа сценариев, уже могут быть скорректированы требования к подсистемам. А что касается описания объекта автоматизации, то возможно это уже не столь критично в начале он или в конце, просто я его разместил в конце, т.к. сначала мне хочется узнать что вообще нужно сделать, а потом понять как это интегрировать в существующую систему, и что уже там есть, а не слушать пролог не понимая к чему это все. Хотя возможно на этот счет вы правы. На счет формулировок: задачи, как я понимаю, это как раз то "что мы хотим сделать", описание подсистем уже "как мы хотим это сделать", а вот сценарии уже то "как мы этим планируем пользоваться".
Годная статья. Очень кратко и по делу. Можно давать студентам, чтобы сами писали ТЗ к лабораторным.
Спасибо.
Спасибо. Правда я не уверен в полезности для студентов данного подхода, мне казалось это больше для малой коммерции. Хотя я сам на айти не учился, поэтому не уверен чему там учат, просто как мне казалось преподаватели рады если студент в принципе справился с поставленным заданием, а не оценивают удовлетворенность гипотетических пользователей и эффективность оптимизации бизнес-процессов. Но первые три пункта конечно это де-факто стандарт
Автору было бы не плохо разобраться в концептуальной разнице между ПО, АС и ИС
С чего начинается разработка программного обеспечения?