0: Коллеги, добрый день. Мы начинаем очередную лекцию курса техническая документация в it проектах, и сегодня у нас лекция о гост, применении гост в технической документации. И вот как Костя, наш сегодняшний докладчик.

1: Заранее предупредил, что изначально было желание рассказать про гос 19 и ghosts 34, но материала оказалось настолько много, что начнём мы с ghost 19 и затем, если на то будет необходимость, мы сделаем ещё отдельную лекцию по гост 34, и пока мы начинаем, я хотел.

2: Бы попросить всех участников отметиться в telegram, чате или в чате под видео на YouTube работали ли вы с гос. 19.

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

4: Да, привет, сегодня мы поговорим про ghost более конкретно про гост 19 давайте сначала снова я представлюсь меня зовут Костя Валеев, я руковожу отделом аналитиков техписателей ростелеком айти это дочк?

5: Ростелекома, которые разрабатывают для ростелекома различные цифровые продукты. И я столкнулся с гостами, когда только начинал работать с аналитиком, когда ещё даже работал техническим писателем. Поначалу они показались странными, неудобными, в основном, потому, чт

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

7: Но если разобраться, в общем то, в них есть смысл, особенно смысл с учётом того времени, когда они были разработаны, понятно, что они достаточно сильно устарели, но тем не менее идея в них была в своё время, в общем то, весьма современная.

8: Поэтому я предлагаю сегодня поговорить про 19 гост, как Семён сказал, мы думали сначала сделать некую общую лекцию про 34, 19 гост вместе, но они достаточно большие и уложить все. Вот.

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

10: Может быть реально использовано, а что прям совсем устарело и стоит вообще не трогать. И, соответственно, если будет какой-то интерес, то мы можем потом сделать отдельно 2 часть про 34 гост. Семён может

11: Там у нас уже есть обратная связь по поводу того, кто пользуется 19 гост, да, тут больше 10 людей сказали, что да, это, это их реалии. И тут ещё несколько комментариев. По моему, 2 комментария, что очень многие, ну, двое человек написали, что

12: Пишут и по гост 19, и по гост 34 no 34 год все-таки чаще. Угу. Ну понятно, а сколько всего людей нас слушает? 71 71 человек, в трансляции из них отметились около 15 из них сказали да, вот чуть чуть больше.

13: Понятно. Ну, я думаю, в целом, тогда, смотря, несмотря на то, что мы гост, точнее, 19 год, сегодня пробежимся прям очень по верхам, но обзорно. При этом, я думаю, тем людям, которые с ним не знакомы, тоже будет интересно, потому что

14: Ну хотя можно посмотреть, что там внутри написано. И сначала давайте все-таки пару слов про 34, 19 гост по факту это вот 2 таких айтишных советских госта, которые были вот придуманы. Плюс минус для тогда ещё

15: Области в те времена, и они их часто путают, но при этом разница между ними весьма значительная, потому что по факту гост 19 это единая система программной документации, это гост на софт, именно на программное обеспечение.

16: Ghost 34 это гост на автоматизированную систему вот в автоматизированную систему включается не только софт, в автоматизированную систему включается софт, железо, то есть технические средства, на котором софт работает, включаются люди, в том числе персонал и вклю.

17: Там вся информация, которая нужна для того, чтобы вот этим всем пользоваться. Собственно, есть такая замечательная аналогия, что фактически автоматизированная система это некая атс, в которой раньше сидели барышни и руками втыкали.

18: Коммутаторы для того, чтобы соединить людей, телефон между собой, а мы это все хотим автоматизировать, внедряем автоматизированную систему, заменяем, соответственно, все это на какую-то железку с обору, железку оборудования и со внутри него. И теперь это у нас автоматизированная систем.

19: В современных реалиях, собственно, в чем принципиальная разница, если у вас контракт на разработку софта, то есть, если вы итогом вашей работы должны поставить по, грубо говоря, отдать кому-то там компакт диски либо с исходными кодами, либо собра,

20: Софтом, но все-таки исключительно софтом, то это 19 гост. А если какая-то система, которая, ну либо, во первых, кроме софта, имеет ещё какую-то железную составляющую, или если вы софт, который вы разработали, ещё и внедряете, то есть

21: Автоматизировать какой-нибудь бизнес процесс либо какое-то предприятие, то это ghost там 34, поэтому часто их путают и просят например по контракту на разработку чисто какого-то софта типа сделать, отдать.

22: Заказчику, он его сам будет уже в дальнейшем внедрять и эксплуатировать, то это чисто 19 год. Поэтому, если подготовить комплект документов по 34, у вас появляется куча абсолютно бессмысленных документов, которые к вам никакого отношения не имеют, а остальные тоже весьма с большими.

23: Получается кусками и пробелами, которые, в общем то, нечего и вписывать, поэтому тут стоит так быть немножко внимательным и как бы понимать какую-то разницу между ними. Сегодня мы, как я говорил, сфокусируемся именно на 34 госте там

24: На самом деле, ой, в смысле, прошу прощения, на 19 госте, на самом деле гост достаточно обширный, там про много всего написано, и это такая именно отличительная черта, скорее советских стандартов, потому что тогда стандартизировались

25: Стандартизировать пытались прямо комплекс стандартов, поэтому есть там.

26: Системы стандартов на программную документацию, на конструкторскую, на технологическую, то есть пытались как-то всеобъемлющее покрыть всю предметную область набором стандартов. Скорее, это, наверное, не так распространено.

27: Зарубежных стандартов. Хотя и у того же trip её есть сборники, в которых стандарты собраны тематически, но вот здесь пытались именно как-то комплексное. Это, с 1 стороны, хорошо. То есть вы открываете, например, год 19. И, собственно, видите, что там в принципе,

28: Мы можно, какие документы можно писать про это все. Но, с другой стороны, на самом деле все эти предметные области, которые покрыты внутри этого этой группы стандартов, они очень разнообразны, и по факту на каждый из них можно написать свои

29: Стандарт и в общем то сейчас уже много таких стандартов написано, поэтому это с 1 стороны плюс, а с другой стороны как бы не очень

30: И 2 момент, что нет такого стандарта гост 19 гост 34 это серия стандартов, внутри них полным полно отдельных небольших стандартов, которые, в общем то, про документы в основном в 19 госте их больше в 30.

31: 4 их чуть поменьше, но при этом в 34 они более такие, скажем так, глубокие. То есть там стандарты сами по себе более обширные.

32: Но тут главный нюанс в том, что когда вас просят подготовить какой-то комплект документов по госту, то нужно всегда уточнять, а какой конкретно стандарт мы хотим использовать, потому что состав документ

33: Которые вы должны разрабатывать в соответствии с этими стандартами. Вы должны выбрать сами. Это прям чётко в них написано, поэтому разработать комплект документации по 19 госту невозможно. Можно выбрать те документы, которые вы будете

34: Готовить в соответствии с определёнными стандартами внутри серии 19. Это такой тонкий нюанс, который часто зачастую опускают и, в общем то, из за этого

35: Фактически какая-то внятная польза от использования стандартов тоже сильно теряется.

36: И на практике на самом деле используется только часть стандартов, точнее, часть документов по вот серии стандартов гос 19, даже при работе с самым жёстким госконтрактом. И давайте немножко, совсем так обзорно посмотрим, про что эти станда

37: И, в общем, про что они, в принципе, можно, исходя из их номера сразу плюс минус понять, потому что в самом 1 стандарте этой группы

38: Который 19:00 1. Там написано, как вообще читать эту нумерацию этих стандартов. 1 цифра, это, соответственно, просто серия 19. Дальше как некая классификация. Первые 2 цифры 0 0 них называется

39: Классификационная группа это фактически эта попытка все эти стандарты как-то по темам группировать. Сейчас мы на это посмотрим. Ну а дальше просто номер стандарта в этой группе, он достаточно произвольны и собственно,

40: Эти группы, которые там есть, вот их несколько штук, они вот разбиты именно на какие-то тематические блоки. Причём на самом деле там, по моему, только с 1, с 1, по 6 используется 7, 8, 9, в принципе.

41: Они, видимо, какой-то такой будущий задел оставили, но по факту стандарт сами по себе разбиты только на 6 групп. И при этом на самом деле это деление, оно вызывает некоторые вопросы. Ну, по крайней мере, у меня, и оно мне

42: Не очень нравится, потому что, ну, не совсем понятно.

43: Давайте ещё раз, соответственно, взглянем на этот список стандартов. Самый 1, тот, который 0, это просто какие-то общие положения.

44: Потом идёт у нас некоторый глоссарий, он вот в, в 90, примерно год, ну, в 90, исходя из из, собственно, самого номера стандарта, мы сейчас немножко посмотрим. Он неполный, местами странный и не раскрывает, собственно, термины.

45: Остальных стандартов этой группы. Потом идут какие-то основополагающие стандарты. Здесь, причём есть отдельный замечательный стандарт про стадии разработки, который сильно отличается от всех остальных. Дальше у нас группа 2.

46: Какие-то на самом деле, по идее разработческие документы, потом некоторые правила.

47: Выполнение документации, изготовления. Вот замечательная группа, в которой есть только получается 1 стандарт, который про программу, методику испытаний. Дальше документация сопровождения, эксплуатационная документация, правила обращения программной документации. Ну, в общем, группировка весьма странная. И

48: И я предлагаю посмотреть на стандарты чуть с другого ракурса, скорее такого, более привычного нам в современной разработке. Давайте немножко прям пробежимся. Собственно, самый 1 стандарт. Давайте прям откроем.

49: Стандарты, в общем то, доступны общедоступные, их можно найти в интернете. Вот есть замечательный сайт, честно говоря, даже не знаю, кто его ведёт. По моему, давно уже его не ведут, но тут собраны собственно тексты всех этих стандартов. Можно

50: Вот как раз та самая классификация, те самые группы. Ну и в целом рассказано, что есть такой, есть такая группа стандартов, называется еспд, она вся про там программную документацию.

51: И она, в принципе, вам к вам никакого отношения не имеет, потому что она не про ваш комплект документов, то вы должны писать, она сама, это стандарт про сами остальные стандарты, поэтому его вам, скажем так, особо то и

52: Буду применять дальше замечательный документ, который, точнее, замечательный стандарт, который называется термины определения. И тут есть классный нюанс, потому что, во первых, если посмотреть, он сильно отличается даже по номеру.

53: Всех остальных какая-то странная 181. Ещё и без точки. Нюанс в том, что этот стандарт заменил предыдущий стандарт, который был до этого, соответственно на него чуть дальше посмотрим, да.

54: Раньше здесь был стандарт 19:00 4 80 года, а в 90 его заменили на 19 781 это не помогло. 1 стандарт был совсем короткий. Там буквально 10 терминов. Такие обще, определяющие, что такое программа.

55: Что такое программный продукт, точнее, программное изделие. Фактически это была такая переводная калька с иноязычных терминов, с английских, на основе которых, в общем то, эти термины дальше использовались в остальных стандарт.

56: Хоть их было немного, но тем не менее, они использовались, потом его заменили на вот этот стандарт 90 года. При этом не включили те термины, которые были в предыдущем стандарте. Поэтому сейчас вот какие-то основополагающие термины, которые используются в остальных стандартах, вы даже

57: Смотреть не сможете. Это 1 нюанс. 2 нюанс. Если посмотреть на этот стандарт, те термины, которые здесь используются, они прям сугубо программистские. То есть это такое, это такая попытка переводить всякие разные

58: Там низкоуровневые вещи, типа интерпретированное по там языки программирования, алгоритмические языки, макроязыки, макрокоманды, функциональные трансляторы. Это вот такая вот штука. Сугубо сугубо. Прям вообще программистка.

59: И это 1 нюанс, потому что, ну, вы их, скорее всего, особо не будете использовать в тексте вашего документа. Во вторых, они местами прям сильно устарели. В третьих, это переводы и весьма плохие переводы, как мне сейчас кажется, уже

60: Названий, которых ни 1 нормальный человек сейчас не использует. И если вы будете их писать, ни 1 разработчик вас не поймёт, что вы имеете ввиду. Ну там, кроме таких вот общих вещей, типа объектно ориентированный язык. Ну ладно, наверное, понятно. Процедурный язык, ну тоже оно не сильно поменялось, но если вы где-нибудь напишите что-нибудь.

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

62: Речит друг другу в разных стандартах серии, в том числе, наверное, из за того, что этот стандарт заменил предыдущий. Но при этом, собственно, термины во всех остальных стандартах никто не поменял. Поэтому на самом деле вот этот вот стандарт не рекомендуется использовать

63: И даже если вот начать с самого начала, он скорее вызывает больше вопросов, чем ответов. Вот программа, что это у нас, это данные, предназначенные для управления конкретными компонентами. Система, что такое компоненты? Почему программа это данные, что такое данные?

64: Как данные могут чем-то управлять и причём это определение не бьётся с определением следующего стандарта, если его прям следующий открыть по нему.

65: Следующий по списку открыть, то здесь будет по словом программа. Уже другие вещи будут написаны, например, компонент. Здесь это тоже программа, а здесь у нас программа управляет компонентами.

66: Написано система обработки информации, что это такое, тоже никто не знает, потому что об этом нет никакого определения, в общем.

67: Единственный плюс, наверное, этого стандарта про термины, то что если вам что-то в остальных х непонятно какие-то слова, есть небольшой шанс, что может быть вы посмотрите сюда и как-то вам это поможет разобраться, но

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

69: Как бы практический способ его использования. В остальном же штука абсолютно, к сожалению, не абельная. Давайте пробежимся дальше, дальше. На самом деле, если так посмотреть на все эти стандарты, то

70: Сгруппировать чуть по другому, потому что фактически там есть стандарты про написание документов, в принципе, документов любого типа, какие они должны быть по внешнему виду, что в них стоит. Так вот глобально на какие разделы стоит их делить.

71: Как их стоит писать, хранить, вносить изменения, в общем, как с ними работать. Поэтому это не какие-то специфичные стандарты про вот конкретные типы документов, это про документацию в целом. И вот давайте тоже немножко пробежимся.

72: Следующий как раз документ, который у нас по списку, там есть, это виды программы. Здесь, кстати, деление на типы документов уже другое, потому что в общих положениях, в самом 1 стандарте, если на него посмотреть

73: Были документы, разработки, сопровождения, эксплуатации. Вот прям вот здесь они, собственно, даже и по группам разбиты. В стандарте написаны виды программной документации. Говорится о том, что на самом то деле

74: Программные документы, точнее, виды программ у нас бывают либо комп, либо компоненты, либо комплексы. И, наверное, про эти термины ещё раз попозже чуть поговорим, когда дальше поедем. Но в общем то,

75: Специфичная терминология многословия про типы документов, про типы программ, как они между собой все связаны в реальности, наверное, тоже не сильно полезны. Но если вы хотите термины использовать, надо тоже быть осторожным, чтобы они были

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

77: Обычно в современном русском языке под каким-то программным документом нечто другое имеется ввиду. А здесь это именно какой-то вот документ про программу, а программа это фактически там софт.

78: И вообще, в целом вот этот вот этот стандарт тоже стоит использовать, как я говорил, уже с аккуратностью, потому что даже в нём написано, что вот

79: Точнее, в нём есть замечательная табличка вот эта, в которой написано, какие документы вам обязательно нужно иметь на разных этапах разработки и по факту обязательных документов всего 2. Это спецификация и текст программы. Все остальное вы определяете.

80: Какие документы и стандартов вам нужно включать в комплект? Некоторые вообще, в принципе, там не составляете на разных этапах, а все остальные документы вы определяете, и вы определяете, собственно, какие документы вам нужны в техническом задании. Поэтому нельзя просто написать.

81: За что документация определяется по гост 19 101 77, потому что в этом же госте написано, что это вы должны сначала определить, какие документы вам из этого всего большого списка нужны. Поэтому это не имеет никакого смысла. А изнача

82: Что автор тз не читал самого этого?

83: Дальше у нас идёт стандарт про обозначение.

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

85: Эта штука абсолютно напрочь устарела, это прямое наследие такой единой библиотечной отраслевой системы Советского союза и вот бумажных документов, которые нужно искать в каких-то огромных архивах, в общем то, пытаться внедрить

86: Какую-то такую схему нумерации документов, ну абсолютно нерационально, поэтому стоит его избегать. Ну единственное, что тут полезного можно из него взять, ну, то, что в названии документа стоит

87: Указывать и версию самого документа, и версию собственно, самого софта, для которой он написан. Ну то есть есть у нас какая-то версия программы 1 точка 4, а потом мы говорим, что это документ, там версии 2 к софту 1 точка 4 есть у нас потом

88: Выходит новая версия софта 1 точка 5. Это там документ, там 1 версия к этому софту. В общем то идея очень здравая и неплохо её тоже переиспользовать. Но ещё вот 1 такой нюанс я лично рекомендую с некой осторожностью.

89: В целом относиться к цифра шифрам в названии, потому что вот в соответствии с гостом ваш документ, точнее название вашего документа это набор каких-то цифр, которые каждый что-то должны означать, что они должны означать.

90: Вот это есть справочники, в которых все это написано в современных реалиях. Это означает, что у вас будут какие-нибудь, там, не знаю, файлы или статьи в конфликте, которые будут называться 2 точка 8 точка 24 точка 5 точка 12. И там, не знаю, 2020, что

91: Должно означать, вот новый человек совершенно не разберётся. Поэтому, как мне кажется, идея вот именно с такими шифрами в названиях, она понятна и осмысленна, если у вас реально бумажные архивы, в которых нужно в определённом порядке раскладывать ваши доку,

92: Сейчас все-таки лучше какие-то вменяемые названия давать договориться конечно о каком-то

93: Какой-то политики наименований, но в целом вот не использовать вот так придирчиво все эти шифры

94: Дальше, соответственно, следующий документ это основные надписи, это прям любимая тема. Любимая тема нормы контроля. Тут про титульный лист и про все остальные по факту.

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

96: Еспд не заставляет вас их делать, поэтому, в принципе, если вам явно об этом кто-то не говорит, что делайте документы с рамками, то и не надо, потому что это какая-то прям очень реликтовая история на самом деле.

97: Ну тут какие-то общие правила в целом в целом, понятно, у документа должно быть содержание, какая-то аннотация, лист изменений.

98: В общем, не сильно полезная история, но и опять-таки для какого-то единообразия. Вот все документы по госту как-то вот так должны выглядеть. Ну понятно, я думаю там, если вас опять же заставляют, если у вас прописано где-то в контракте, что нужно вот использовать этот там

99: То сделайте просто так, как здесь написано. Если нет, то я бы не стал. А на эту штуку ориентироваться дальше. Замечательная вещь. Общие требования к по документам это, в принципе, в целом про типографику.

100: И про, а, нет, ну да, да, да, это в целом про типографику он несколько неоднозначный, потому что, с 1 стороны, хорошо, что он создаёт какие-то

101: Оформление, да, особенно людям, которые в этом не разбираются. И не позво, если следовать этому.

102: Этому документу. Так, сейчас требования к документу выполнены печатным способом. Если в принципе следовать этому документу, то у вас документы хотя бы получатся одинаковые. Это хорошо, это даёт.

103: Некие правила оформления, но при этом документ с точки зрения современных, даже не современных, а в принципе любых норм какой-то хорошей типографики, правила здесь достаточно

104: Не совсем корректные, скажем так, их сейчас такое форматирование считается неудобным для чтения, неэстетичным, ну и вообще плохо читаемым. Эти вот замечательные большие буквы, точнее,

105: Полуторный интервал между собственно строками такие поля тоже весьма странные обязательный номер страницы почему-то сверху здесь строчка изменений.

106: Здесь, ну, в общем, любой дизайнер вам скажет, что так верстать не надо. Поэтому если опять-таки вас не заставляют именно этот стандарт использовать, лучше выработать какие-то внутренние правила оформления, докумен.

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

108: Которые здесь, кстати говоря, гост не определяет шрифты, в нём нигде не написано слово times new roman, поэтому необязательно его пихать во все документы, которые вы пишите по госту возьмите.

109: Хотя бы н отличный, специально придуманный для кириллицы, современный и, в общем то, распространённый сейчас в стандартном комплекте любой операционной системы он идёт.

110: Дальше у нас замечательный документ. Ведомость держателей, замечательный стандарт, ведомость держателей подлинников. Он вообще не нужен. Это чисто для бумажных архивов, причём советских, опять-таки отраслевых. Про то, как вам

111: Убирать документы из архивов, кто у кого там главная копия, у кого остальные копии, как вносить изменения в них. В общем, это абсолютно не современная история. Можно вообще не использовать аналогично правила учёта и

112: Общие правила дублирования, учёта и хранения тоже абсолютно ненужная сейчас история тоже для советских архивов. Как вам вот эти все документы хранить в больших бумажных собственно, хранилищах?

113: И их там находить абсолютно неактуально аналогично для про документов, выполненных печатным способом, тоже можно выкидывать и там никогда дальше даже не открывать штампы, как ставить, как подписываться на них. Ну, вы понимаете.

114: Но при этом следующий стандарт про правила внесения изменений, он уже поинтересней, там, понятно, тоже много всего устаревшего про бумаги, про то, как там в них вносить копии. Но если так присмотреться, там есть здравые мысли, которые

115: И сейчас, в общем то, неплохо было бы использовать, что там так в принципе написано, что название уже созданным документом менять нельзя. Если вы какой-то документ написали, вы можете вносить изменения, но вот что.

116: Потом его найти там не переименовывайте. И если вы что-то уже поменяли в 1 документе, это прям очень хорошая мысль. Если что-то в 1 документе изменили, и это эта мысль где-то ещё проскальзывает в нескольких других.

117: То меняйте во всех связанных тоже. Это очень важный пункт, который даже и сейчас тяжело реализуемый, потому что очень дорогой. Ну, вам нужно отслеживать все изменения во всех документах. Если что-то изменили, нужно пойти консистентно там

118: Зная, где это ещё используется. Везде все поправить, везде внести редакцию и выпустить новые версии. Но идея очень здравая. И, кстати, если вы так не делаете, то вы нарушаете гост конкретно вот этот при и

119: Следующая хорошая мысль, что об изменениях документации нужно оповещать в гости. Предполагались специальные виды документов, которые называются там бюллетени, и предложение об изменении, по моему, это называется, да, извещение об изменении. Поэтому, когда вы

120: Какой-то документ изменили, вы должны всем об этом сообщить. Тогда это предполагалось, что вы прям специальные бумаги по этому поводу отправляете, но по факту сейчас это означает, что вы должны в чат об этом написать, в рассылку отправить как-то ещё.

121: Людям сказать, что вот вышла новая версия и ещё 1 хорошая мысль это то, что есть только 1 источник изменений, как раз хранитель оригинала вашего документа, и только он вносит изменения, а все остальные могут вносить

122: Свои приложения об изменениях и тут как бы привет истории про о с мастер веткой и п. В неё вот это, в общем то, прямое отражение тех мыслей, которые в гости были заложены. И ещё 1 хорошая идея здесь.

123: То, что нужны логи. Тут это называется бюллетени об изменении. Когда у вас что-то поменялось в документе. За какое-то время вы отправляете ещё 1 тип извещений. Бюллетень фактически лог того, что поменялось в нашем документе.

124: И там люди могут посмотреть и понять, что у вас изменилось в целом, в вашем комплекте документации. Это очень полезные мысли, мы на самом деле и сейчас их можем переиспользовать. Есть такая штука, например,

125: Мы у себя используем для ведения, для описания изменений в документации такой подход, типа, очень такая понятная, простая история. Пишется. Соответственно, версия документа, пишется дата.

126: А дальше что добавилось в документе, что удалилось в документе, что изменилось, что просто было там немножко исправлено. И вот, соответственно, по каждой версии у вас сохранится такой небольшой числок, он, в принципе,

127: Такой формат подходит и для написания оо по софту, ну и для документации тоже отлично заходит идея ещё с 78 года.

128: Вот поэтому полезные мысли можно составить, оставить и развить, попытаться применить к современным реалиям, а все остальное там про бумажное хранение стоит выкинуть.

129: И последний документ это

130: Тоже достаточно интересная штука правила внесения изменений в документы, выполненные печатным способом. Фактически это такое руководство про то, как вам отмечать диффы внутри ваших документов. Тогда они велись все вручную и

131: Соответственно, вы либо в самом документе аккуратно, там специальным образом что-то зачёркивали или писали сверху. И в конце документа вы должны ввести лист регистрации, изменения, где написать, в какой странице, че вы изменили и на что вы это заменили.

132: Слава Богу, сейчас это можно делать автоматически. Есть диффы между версиями почти во всех либо система контроля версии, либо во всех Вики движках н даже.

133: Может показывать разницу между документами, поэтому по факту вот эта штука немножко устарелая, она специфична именно для бумаги. Но сама идея то, что регистрировать изменения, что у вас поменялось между версиями, тоже очень здравая.

134: В общем то по факту вот из всех этих документов вам прям критично важного, в них вряд ли что-то можно будет прям прямую переиспользовать. Есть хорошие идеи, которые стоит просто внедрить в любом случае.

135: Документы по госту или нет, но в целом это все весьма весьма устарело и там к реальности относится слабо, потому что заточено под именно бумажные версии и такие большие архивы для того, чтобы хранить

136: Отдельно совершенно. Прям вот особняком стоит стандарт 102 77. Это про стадии разработки, потому что он по факту, в отличие от всех остальных, не про документы и даже про неё саму

137: Программу, а про то, как её писать, то есть разрабатывать, это фактически руководство по тому, как процесс разработки строить

138: В общем то, если так посмотреть, такой классический водопад по проектному, ну с точки зрения проектных методологий.

139: Внизу которого, кстати, есть классная приписка, вот эта вот она почти есть у каждого госта о том, что вы, в общем то, можете делать че хотите. Вы вот можете на это посмотреть и объединить какие-то этапы, схлопнуть их вместе, добавить свои

140: Делайте, что хотите. Гост вас в этом не ограничивает, поэтому вы на самом то деле можете по госту 19, 102, 77 делать абсолютно что угодно, написав только об этом в самом начале, что вот мы взяли гост 19, 2, 77 и его изменить таким-то образо.

141: Тем самым вы все ещё этому госту соответствуете. Это вот немножко, опять-таки, про ценность стандартов и про вообще вот 19, 34 гост в частности, потому что, ну, по хорошему современ.

142: Хороший стандарт, он должен давать вам рекомендации, то есть он должен вам давать какие-то лучшие практики, по которым вы

143: Можете что-то сделать хорошо а не, ну вот вам ребята в целом какая-то базовая вещь. Ну а дальше вы там как-нибудь сами разберитесь. Поэтому вот просто так опять-таки ссылаться на стандарт тз бессмысленно, он никакой информации о том, как вам реально что-то разрабатывать не das

144: Ну и по факту, на самом деле, про подходы к разработке по есть отдельные прямо своды знаний. Тот же бок, много есть своё блок, который инженерия, инженерии.

145: И вот это не про 1 страничку, да, что давайте делать? Вот так есть куча разных методик, поэтому ценность этой всей штуки, которая здесь написана, весьма такая уже, скажем так, сомнительная.

146: Но, в принципе, если вас от вас просят там что-то сделать по вот этому госту, то вы можете его там под себя очень сильно заточить. Ну и, например, если вам нужна какая-то интерактивность, хотя, в общем то здесь такое, как я говорил,

147: Классический плюс минус водопадный подход, то вы можете просто разбить вообще весь процесс вашей разработки на отдельные стадии и каждую стадию, точнее, ну, отдельные этапы, и каждый этап делать по этим стадиям, потому что по факту, ну у вас

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

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

150: Краткая выжимка и весьма так, уже подустарела. Тут есть очень интересные мысли. Например, замечательный этап исследования, вот этот вот, который предваряет всю дальнейшую процедуру разработки софта.

151: И он сейчас тоже такой несколько опасный, потому что современный вот процесс разработки, точнее, даже процесс контрактования по разработке софта особенно

152: Для госзаказчика он весьма отклоняется от тех идей, которые здесь заложены, потому что мы про это, наверное, можем подробнее поговорить, если будем говорить, когда будем говорить про гос.

153: 34 серии, но по факту в 34, 19 госте тз должен делать исполнитель, потому что в тз, если смотреть на то, что здесь, по идее, на этом этапе нужно делать очень много именно проектировочных решений.

154: То есть, если вы пишите тз, вы должны быть компетентны, как разработчик по, а не просто быть заказчиком, который, ну, я хочу, чтобы вы мне какой-то софт запилили и

155: Тут некое отличие от таких классических документов, точнее, классических стандартов на на требования тот же самый софт спе мы чуть чуть позже на него взглянем.

156: По требования, потому что здесь в тз не просто требования, которые мы хотим, чтобы наш софт реализовывал, а тут ещё много именно уже принятых решений, какие, на какой у нас будет, какие у нас будут языки программирования, какие у нас будут алгоритмы.

157: Мы какой софт внешний мы будем использовать, поэтому заказчик, по идее про это, про все особо то и не должен знать и тз. Пишется исполнителю.

158: 2 интересное замечание. Это, наверное, ещё более вот такая

159: Полезная была бы история с точки зрения госконтрактов всего остального, то, то есть технико экономическое обоснование. Фактически сумма разработки, она формируется на этапе эскизного проекта есть, когда у нас есть только тз.

160: Мы, в общем то достаточно слабо понимаем, сколько нам потребуется времени и сил, чтобы его реализовать, потому что очень много неопределённости, нужно сначала хотя бы базово как-то спроектировать решение, и тогда мы уже сможем более менее точно понять, сколько оно будет стоить. То есть по факту

161: По идее, вот если реализовывать процесс разработки по 19 госту, то сначала заказчик, например, на гос. Конкурс выдаёт просто техническое задание, которое, по идее, ему должны были написать какие-то специальные

162: Обученные люди, которые в этом разбираются, а дальше к нему прибегают уже исполнители, приносят свои эскизные проекты и приносят то, которым описывают, сколько вот, с их точки зрения, такой эскизный проект можно было бы реализовать, ну как бы уже

163: Целиком софт. И уже на основе этого заказчик принимает взвешенное решение, выбирает лучший эскизный проект за, соответственно, минимальную цену. Ну это, конечно, утопия, да, мы все понимаем. Ещё важный нюанс, который

164: В принципе, поможет потом посмотреть на остальные документы рабочего проекта. Это то, что разработка программы, то есть непосредственно написание самого кода, это написание рабочего проекта.

165: То есть, с точки зрения госта, сам софт, то есть сам исходный код, это и есть документация, то есть исходный текст, они не просто документируют программу, она и есть, они и есть, собственно, сама эта программа. Поэтому, с точки зрения гост 19, написать код, это написать рабочий проект.

166: И ещё 1 интересная сноска внизу, на которую стоит обратить внимание, вот это вот.

167: По факту гост разрешает такой подход фигак фигак и в продакшн если очень хочется, то есть мы можем пропускать стадию эскизного проектирования, стадию технического проектирования, а вот из тз сразу сразу пойти и начать разрабатывать.

168: Отлаживать программу, то есть тоже такой. Фактически некоторые аджайл можно по этому стандарту вполне себе реализовать. Так, ну и давайте пойдём дальше. У нас уже не так много времени остаётся.

169: Дальше у нас есть набор то, что фактически можно так назвать.

170: Проектировочными документами. То есть это документы, которые полезны вот при разработке полезны самой команде, чтобы сделать какой-то софт.

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

172: Оно, конечно, сильно меньше, чем тз по 34 госту, но все равно такое большое, большое.

173: При этом, несмотря на то, что тут многие вещи раскрыты, оно все равно сильно меньше и сильно сильно менее продуманное, чем тот же самый софт specification, стандарт it.

174: 730, но в целом вот требования

175: Ну.

176: Группы требований по софту здесь каким-то образом раскрыты, но вообще по факту наверное основной минус и вот этого стандарта на техническое задание и стандарта 34 на тз, что они

177: Про документы, но нету госта, про требования сами по себе на самом деле есть такой стандарт ieee 29 148, который называется

178: Который называется софтвер каменно реквайрмент инжиниринг. И это такой вот большой большой сейчас основополагающий стандарт про то, какие вообще бывают требования.

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

180: Отталкиваемся не от документа, как вот некого шаблона, да, мы отталкиваемся от отдельных требований, которыми мы управляем и с которыми мы работаем, а потом их собираем в разные документы для разных точек зрения. То, что называется new point та.

181: Это прям сильно рекомендую этот, да, посмотреть, почитать. Вот он большой. И, соответственно, поэтому очень как бы хорошо покрывает предметную область. Вот здесь на самом деле 2 странички, и они, ну, совсем

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

183: Можно в той же википедии посмотреть или в этом стандарте 29 148.

184: Но по факту мы, наверное, сейчас не будем уже углубляться в то, что здесь по каждому разделу написано, тут местами, они очень обширные, эти разделы, в которых перемешано куча всего, что сейчас разделяются на отдельны.

185: Вот типы требований очень много про всякие физические штуки, что весьма странно. То есть требования, например, к транспортировке. Ну это ладно. Так, на 1 поговорим. Требования к

186: Условиям эксплуатации, температура окружающего воздуха, относительная влажность и так далее. Все, что относится именно к физическим носителям в госте тоже про это много упоминается, потому что, ну, с точки зрения 19 госта итого

187: Программу вы сдаёте на каких-то физических штуках. Это перфокарты бабины с этими, с магнитными лентами, что-то ещё и они все требуют особых условий транспортировки и хранения. Поэтому во многих гостах про это много чего сказано. Сейчас это уже опять-таки не так актуальн

188: Поэтому тоже такой анахронизм часто просказывает здесь проскальзывает ну в общем, в целом можно посмотреть на это на все 1 глазом, если вас не заставляет использовать вот именно жёстко эту структуру документов, а ghost опять же есть у ghost опять же есть приписка.

189: Вы можете состав этих документов и структуру в них менять под ваши задачи, то стоит посмотреть это 1 глазом, переделать и взять за основу тот же самый специфике современный нормальный стандарт.

190: И вот внутрь этого этого состава разделов как раз уже засунуть то, что предлагается там.

191: Так, давайте дальше. Спецификация, спецификация это такой, такое краткое описание вашего по такой техпаспорт в целом полезная штука.

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

193: 19 год. Тут есть специфичные слова, которые как будто бы все про одно и то же, но имеют прям отдельный свой смысл в рамках вот этих всех стандартов.

194: Программа это как раз вот ваш код с точки зрения госта, он какой-то алгоритм должен реализовывать по идее, но это, собственно как раз программные коды и ваша программа, она может быть либо компонентом, то есть самостоятельным каким-то софтом, либо входить в комплекс.

195: Да, это несколько программ, которые вместе что-то должны делать при этом на вашу программу, то есть на компоненты или на комплекс у вас должен быть, должна быть программная документация, то есть набор документов как раз по 19 стандарту. И вот

196: Грамма плюс документация к ней это программное обеспечение. Вот такой вот термин, как бы для контейнера, из софта и документации к нему. При этом, собственно, программа у нас

197: Хранится на неком физическом носителе данных. Это, как я говорил, там карты мобильны, кассеты, что там ещё было. И вот как раз программа, документ

198: К этой программе плюс носитель данных, на котором программа написана, это программное изделие. То есть это по факту Бабина с уже там, не знаю, с собранным кодом, который можно куда-то вставить и запустить это.

199: Документов к нему вот это все вместе программное изделие. Вот вы его бы кому-то можете передать собственно этот документ спецификация он про вот все вот эти замечательные составляющие вашего программного

200: Что они должны быть пронумерованы, собраны в табличку. Это такой фактически техпаспорт, чтоб вы знали, что у вас вообще в принципе есть

201: Так.

202: Пми, пми. В общем то особо не устарело. Это такой в общем то полезный хороший документ. Фактически это тест план к вашему софту. Мы вот в него напрямую выгружаем тест кейсы прям вот те, что пишут тестировщики, методы.

203: Испытаний прям вот отлично подходит. Ни капли не устарел текст программы. Вот это как раз то, что я говорил, это и есть исходные коды. В общем, сейчас на самом деле может

204: Пригодится, если заказчик совсем вот такой упёртый и в этом случае ему нужно сделать какой-то, каким-то скриптом, просто экспорт исходников в какой-то документ отдать, но так это абсолютно бесполезная штука.

205: По факту вот у вас исходные коды, они лежат просто текстовыми файлами, где-то там в системе контроля версии и выгружать их в документы. Это такое несколько противоестественное сейчас занятие, но при этом тут есть такая интересная мысль.

206: Что вообще по 1 из стандартов самых первых про комплектность самого документа.

207: У каждого вот документа, то есть по факту, с точки зрения вот этого стандарта, у каждого файла с кодом должна быть некоторая аннотация, в которой написано назначение вот этого конкретного файла с кодом, для чего он используется, кто его

208: Писала и так далее. В целом это интересная идея, чтобы там у каждого файлика было написано там, для чего он нужен. Но, наверное, разработчики не очень её эту идею поддержат. Дальше давайте сначала посмотрим.

209: Пояснительная записка. Пояснительная записка тоже такой документ, который фактически зеркалит техническое задание, это

210: Документ, который пишется перед разработкой после каждой из стадий проектирования, либо эскизного, либо технического. Фактически. Вот мы смотрим на тз и раскрываем, как мы то, что там написано, хотим в нашем софте

211: Реализовать по факту тоже такая несколько избыточная штука, потому что есть ещё 1 документ описание программы. А вот описание программы уже пишется в конце. То есть мы пояснительную записку пишем во время разработки, когда мы уже разработал

212: У нас появляется описание программы, где мы все тоже самое, но более детально и подробно уже фиксируем. В целом опять-таки хорошая штука, но куча непонятных терминов, которые опять-таки не

213: Скрываются, как их сейчас трактовать? Ну, не очень понятно. Тоже самое, тоже самое логическая структура, что такое логическая структура, кто ж его знает, нигде этот термин не раскрыт. Это структура классов объектно ориентированном, программировани.

214: Или это структура каких-то модулей подключаемых, или это какая-то алгоритмическая схема, которая у вас работает, не очень понятно. Плюс алгоритмы, которые, ну сейчас несколько такая кривая абстракция, потому что по факту современный софт, он

215: Сильно сложнее, чем выполнение каких-то простых алгоритмов. Алгоритмов может быть много, они там между собой зависимы. А если мы говорим ещё про какое-то реактивное программирование, там в принципе алгоритмов нет, поэтому как его сейчас использовать, не очень понятно. Плюс тут слишком

216: Мало разделов для какого-то полноценного описания и в них тоже много намешано, много разного намешано, нет вложенности. Опять-таки, если у вас программа разделена на отдельные компоненты, то вам нужно по факту для каждого

217: Из них делать отдельный документ с описанием это все повторять.

218: В общем, тут, наверное, такое общее замечание, что если вас опять-таки не заставляют вот этой жёсткой структуре следовать, то возьмите современный стандарт, тот же самый i, 3 е 830 этот стандарт на.

219: Описание программного обеспе 10 10, 16.

220: Это документ, точнее, стандарт на документ, описание программного обеспечения обеспечения. Собственно говоря, дизайн дискрипшен очень такой, очень понятный и простой, собственно, с хорошими рекомендациями на то,

221: С каких сторон на ваш что посмотреть то, как он используется, из чего он состоит, какие там есть структуры данных, какие есть зависимости, какие есть сценарии его использования, какие есть программные интерфейсы и пользователь.

222: Какие используются ресурсы? В общем, прям, прям хороший документ, точнее хороший стандарт. Мы стараемся примерно его придерживаться, когда описываем какой-то наш софт, если нужна какая-то прям большая.

223: Поэтому хорошо работает. Взять вот, типа 19 год, 19. Это вот прям стандартное описание программы. И внутрь него засунуть то, что предлагает. 3 200.

224: Либо впрямую прям вот заимствовать оттуда структуру разделов и вот сюда её воткнуть, либо же вот смотреть то, что предлагает этот самый гост по структуре. И вот внутрь уже отдельных вот этих

225: По смыслу попытаться запихнуть то, что есть в 10 16, но лучше, конечно, прямо заменить и выкинуть.

226: Так, и ещё 1 замечание, что по факту иметь 2 разных документа описания программы, пояснительная записка не очень рационально. Лучше иметь какой-то 1 документ, который вот описывает текущее состояние вашего, вашего, вашего софта.

227: Сначала он описывает там принятые проектировочные решения, а потом, соответственно, как он, как они были реализованы. Это фактически некое описание, которое развивается вместе с развитием вашего, вашей программы, поэтому дублировать их, иметь там.

228: Несколько документов не так рационально, как иметь 1, который будет просто развиваться по мере развития вашего софта и

229: Ещё 1 такой нюанс, что в в госте в 19 нет ничего по поводу какие вам использовать схемы, нотации и все остальное. Поэтому по факту тоже самое описание программы никто вам не мешает использовать

230: Вменяемые стандарт, вменяемые современные нотации эмэль ипиэн ер диаграммы нас сюда вполне нормально ложится.

231: И давайте ещё посмотрим на интересный документ, вот на вот этот вот описание языка, это про то, как документировать какой-то язык программирования в реальности вам такая штука редко пригодится. Ну только если какой-нибудь д.

232: Разрабатывали и его нужно теперь задокументировать, да ещё и по госту. Но я думаю, это достаточно редкий кейс. И опять-таки в целом от жизни документ оторван совершенно. Вот если посмотреть на какой-нибудь документа,

233: Язык программирования, она выглядит несколько иначе.

234: Структура этой документации выглядит несколько иначе, чем предлагает, собственно кратенько записать нам гост. Это не поможет разработчику начать пользоваться вашим языком программирования. Ему нужно что-то

235: Такое различные референсы, Туралы по использованию и там нюансов сильно больше, чем способов структурирования и средств обмена встроенных элементов, поэтому тоже весьма такая, скорее Неживая.

236: Дальше документы по эксплуатации.

237: Тут, собственно, это последний, это такая последняя группа документов, на которую, собственно, можно уже разделить гост. Это такие более классические руководства. И что интересно, он

238: Давайте начнём с самого 1. Здесь стандарта есть такая штука, которая называется формуляр. Такая несколько. Сейчас тоже устаревшая идея. Это скорее как раз про те самые программные изделии.

239: То есть про бабину с кодом. При этом это такой вот документ, скорее эксплуатации. Вы пишите формуляр все, что происходит во время жизни вашего программного продукта, то есть

240: Какие-то изменения, которые вы в него внесли, баги, которые к вам принесли, пользователи, какие-то рекламации, это периодически замеряете характеристики работы вашего софта и видите, что он там со временем, например, не деградирует.

241: Вот это такой вот фактически журнал ведомость программы на период все жизненного цикла. Сейчас, конечно, абсолютно бессмысленно использовать, потому что фактически для вот этого всего у вас есть jira или там любой другой инструмент управления там, проектами.

242: Поэтому, ну тоже такая весьма Неживая штука описание применения это такая тоже классическая вещь, за что не любит гост, в том числе это потому, что вы 1 и ту же информацию

243: Начинаете разносить по куче разных документов с точки зрения гост гост. Наверное, это оправданно, потому что вот у разных документов должна быть, наверное, разная аудитория, но по факту вы одно и то же пишите в нескольких документов. Вот, в частности, в описании программы, вы это

244: Описание применения это фактически выдежка из описания программы. Такая верхнеуровневая штука, которую вы отдали другому программисту. И вот тут, кстати, есть такой классный нюанс с точки зрения

245: Ghost фактически вашим софтом вашей программой пользуются программисты, вы отдаёте её, вы как разработчик отдаёте другим программистам и они соответственно её как-то пытаются запустить, использовать и так далее и вот эта штука как раз

246: Выдержка из описания программы, которая помогает другому программисту пользоваться вашей программой. То есть это скорее такое руководство по интеграции. В целом штука такая несколько бесполезная. Но если так присмотреться, её можно исполь.

247: Для того, чтобы описывать внешний апиай, внешний программный интерфейс для вашей системы. То есть вы можете в описании применения написать, как с ней интегрироваться, что вот у нашей программы есть, не знаю, команда интерфейс с таким т.

248: Параметрами и им каким-то образом можно воспользоваться. Либо есть cpi, которым тоже можно всегда воспользоваться. В принципе, в этот документ можно выгрузить справочник игра, и он по смыслу как раз сюда и ложится.

249: Дальше руководство программистов, операторов и

250: Тут, наверное, стоит ещё 1 маленькую ремарку сделать, что по факту, с точки зрения госта пользователь это не человек пользователь по вот термину, который используется, это предприятие, которое у вас то программу купило и внедрило. А человек это оператор.

251: Поэтому вот если опять-таки писать документацию по госту, вам нужно везде говорить слово оператор, в том числе и когда мы говорим про людей, которые пользуются нашим интерфейсом,

252: В целом руководство программистов здесь их 2 системного и простого, они дублируются почти на 90%, разве что у системного есть ещё почему-то раздел про то, как проверять.

253: Что ваша программа работает как она, как она и должна по факту.

254: Системный программист просто устанавливает ваш софт, а обычный программист просто им пользуется. Но, в общем, иметь 2 таких документа точно бессмысленно. И вообще они там очень сильно пересекаются для какой-то основы. Может быть, их и можно взять.

255: Не забыть написать, как запускать вашу программу, какие есть параметры на вход, на выход, какие сообщения может выдавать. Но в целом штука такая достаточно тоже устаревшая, но как опять же говорил некоторую основу, чтобы написа

256: Какие-то базовые вещи, потом как разворачивать ваш софт, как его настраивать ну всегда их можете записать и да ещё такая интересная мысль что с точки зрения опять же ghost программист это то что сейчас называется админ это человек который вот вашу программу может

257: Там где-то в каком-то окружении запустить, настроить и смотреть что нормально работает. А по факту, по факту руководство системного программиста это руководство администратора, системного администратора в современных реалиях. Ну руководство оператора это понятная 100

258: Это пользовательское руководство, то, что мы сейчас называем user guide.

259: Для того, чтобы писать хорошие гайды, стандарт не пригоден, потому что здесь про это ничего не написано. Он не помогает писать пользовательскую документацию. Стоит взять нормальные стандарты и рекомендации, если я правильно помню про них.

260: На каком-то вебинаре рассказывал взять какие-нибудь хорошие стайлы и так далее, и по ним уже написать нормальное пользовательское руководство, благо гост на это на все не накладывает никаких особых ограничений.

261: Ну, наверное, все мы с вами уже и так очень, так плотно пробежались по

262: Стандартный 3 гос. 19, хоть и совсем обзорно. Здесь можно, конечно, углубиться в каждую из них очень глубоко, но общая идея вот сегодняшнего рассказа скорее такая, что гость, да, есть хорошие идеи, туда можно подсматривать как

263: Целостную структуру, потому что здесь достаточно с разных сторон попытались охватить всю предметную область по разработке, по, но вот уже сами документы лучше писать, конечно, ориентируясь на какие-то современные

264: Актуальные стандарты.

265: Plus вообще от документоориентированное подхода у нас сейчас индустрия активно уходит и скорее лучше иметь какие-то небольшие отдельные маленькие артефакты, статьи и так далее, топики из которых уже собирать те или иные документы, если же вам все-таки

266: Нужно работать по госту, например у вас контракт с госзаказчиком, то во первых, если вы пишите сами тз, то внимательно пропишите в тз какие документы и желательно даже какая структура у них должна быть.

267: Вы ожидайте в результате, если у вас есть такая возможность. Если же к вам уже пришли просто с каким-то общим требованием документацию по госту, то подведите максимально содержание документов по

268: Самому госту под современные стандарты ну желательно это с заказчиком согласовать, но обычно тут нет особых проблем, благо сам гост позволяет, как я говорил, менять структуру редко кто пишет тз. Собственно, какую ожидают.

269: И ещё опять-таки стоит продраться сквозь эту несколько странную устаревшую терминологию и писать осмысленные вещи в разделы собственно, самих документов по госту.

270: Даже если вы сами эти разделы по структуре изменить не можете, благо это почти везде можно сделать. Ну и, как я говорил, гост не накладывает на вас ограничения по тому, какие использовать нотации и, например,

271: Какие-то схемы и так далее. Вы можете рисовать тех же мы и в чем угодно. Не обязательно все это делать, как будто вы пишите все ещё документ в 88 году. Вот, наверное

272: Все, что я успел рассказать, так уже выбился из тайминга. Спасибо, что послушали. Если будет интересно, можем как-нибудь пробежаться ещё по 34 госту, либо, наоборот, углубиться в какие-то нюансы из 19.

273: Спасибо большое, кость. Смотри, я думаю, я предлагаю сейчас с вопросами и с дальнейшим обсуждением сделать следующим образом. Я добавил тебя в чат, в телеграммный курса. И коллеги, если у вас есть какие-то вопросы, можете писать в телеграммный чат, ссылка на нег.

274: Чуть ниже видео я 1 из вопросов зачитаю, потому что он важный и на него нужно ответить письменно. Несколько раз в чате спрашивали, можно ли получить список известных тебе или рекомендуемых тобой зарубежных стандартов. Ты

275: Озвучивал некоторые из них, наверное, было бы здорово, если, да, конечно, просто в чатик написал. Вот набор стандартов, которые тебе кажутся достойными ознакомления. Да, да, да. На самом деле. Угу. Их не так много основных. Я их в чат напишу. Это вот как раз реквайрмент инжиниринг.

276: Дизайн дискрипшн и специфике. Ну там ещё есть несколько интересных, я в чат скину.

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

278: Наверное, тогда поделиться впечатлениями о рассказе Кости, то есть услышали вы то, что вы ожидали от этой темы. Может быть, вам кажется, что чем-то эту тему стоило бы дополнить. И интересно ли вам послушать в таком же формате рассказ о гос?

279: И базируясь на ваших отзывах, мы, соответственно сформируем или не сформируем следующую лекцию, на которой можно будет обсудить и ghosts 34, и, например, сравнение гост 19 и ghosts 34.

280: Или можно углубиться в какие-то нюансы, да, или если есть какие-то точные вопросы, да, то тоже не стесняйтесь задавать их в чате, и мы, соответственно, сформируем там какую-то план следующей лекции в этом смысле.

281: Вот, все, давайте переезжать в чат. Спасибо огромное. Спасибо, что уделил время. Очень классно. Мне все прям очень здорово разложил по полочкам. Очень, очень многого из того, что рассказал, мне не хватало последний год. Вот, да.

282: Что понравилось? Вот. Все. Спасибо всем. До встречи в чате. До встречи через неделю на следующей лекции. Все. Всем счастливо. Всего доброго.