0: Всем привет, коллеги, ещё раз. Сегодня я хотела бы с вами поделиться 1 темой. Разработка тз по гост 34 и о чем мы вообще сегодня поговорим. 1, что такое гост, 2 тема будет характерная особенность технического задания по гост. Далее
1: Смотрим принципы составления тз по гост, посмотрим все разделы, которые следовало бы осветить при составлении тз по гост их всего 9, но на самом деле это очень много информации, много, поэтому будем по максимуму сокращать и в конце приведу краткий план разработки тз пого.
2: И он такой более уже психологического плана, скажем так. Что ж, давайте начнём, что вообще такое гост и зачем он изобретён давно, когда изобретения ограничивались чем-то небольшим, потребности в стандартизации как таковых не было. И когда
3: Производство приобрело большие масштабы, сами изобретения стали сложнее, встала такая необходимость стандартизировать их, и нужно это было прежде всего государству, чтобы ограничить выпуск некачественной продукции. Отсюда мы получили гост это государств.
4: Стандарт и суть госта это стандартизировать техническую документацию таким образом, чтобы она была понятна абсолютно любому человеку для этого гостом следует пользоваться, и какой же goat можно выбрать при разработке документации на it продукты.
5: Может стоять между 2 гостами. Это 19 и 34. Как вы можете видеть на слайде 34 гост это гост по автоматизированным системам, в своё время как 19 это гост по программному обеспечению. И как понять, что у нас система
6: То есть, как понять, что нужно использовать 34 гост в системе? Помимо по будет ещё аппаратная часть, то есть та часть, где будет использовано какое-то оборудование, которое входит в состав системы. Теперь разберём основные вопросы, по какому стандарту составляется тз. Зачем?
7: Нужен на тз и какую роль тз занимает в проекте краткие ответы приведены на слайде сейчас немножко подробнее о них поговорим по какому стандарту составляется тз сам тз небольшой и занимает всего 15 страниц язык стандарта русский вообще там может использоваться много непонятных.
8: Терминов. И со всеми этими терминами можно ознакомиться в другом госте, тоже 34, но в другом подразделе 0 0 3 90 гост на техническое задание нужен для того, чтобы установить какой-то шаблон. То есть когда мы хотим составить документ, мы ищем шаблон такого доку,
9: Документа и пытаемся его найти. Просим у коллег. Так вот, любой стандарт на документы или процессы это шаблон и шаблон очень сильно упрощает разработку документа. Для тебя уже придумали и структуру, и содержание. Какую же роль техническое задание занимает в проекте?
10: Тз. Наливает общий облик системы, объём работ и все тз начинается всем и заканчивается, и тз составляется как для исполнителя, так и для заказчика, чтобы заказчик понимал, о чем вообще идёт речь, и в конце не было вопросов, почему у нас такой продукт?
11: А не иной и тз не стоит составлять формально если мы не знаем о чем писать в тз это значит, что тз разрабатывать банально ещё рано следующий вопрос насколько гост устарел и есть ли более новые стандарты, пока точно он не устарел и дело в том, что
12: Ghost описывает общий подход к проекту автоматизации, там речь идёт не о программировании от слова совсем, и если говорить о сравнении с другими стандартами, то сравнивать его тоже особо не с чем, потому что ghost даёт супер широкий взгляд.
13: Проект автоматизации, но если вы хотите использовать другие стандарты, то с ними можно ознакомиться отдельно их 4. И, думаю, можно найти другие аналоги, общие принципы составления, пост, который должен готовить и составлять техническое задание по техническим задания.
14: Занимается бизнес аналитик или технический писатель. И, как я уже говорила ранее, программисты никак не причастны к этому процессу программисты могут быть причастны к составлению документа, технического проекта, но тз и тп. Это разные вещи, потому что
15: Технический проект отвечает, как должны быть выполнены требования, а тз техническое задание объясняет нам то, что должна сделать система и как она должна создаваться, какая сторона должна составлять техническое задание, как я тоже говорила выше, о составлении тз.
16: Должны участвовать обе стороны и заказчик, и исполнитель, согласование тз не должно быть формальным, и каждый пункт должен подробно разбираться и основная цель это вовлечь заказчика максимально в составление этого тз. Иначе требования от системы будут.
17: Сформулирован некорректно результатом вообще всей работы заказчик может быть недоволен насколько далеко можно отходить от ghost любой стандарт даёт только общие показания о том, как нужно делать документ и он создан для того, чтобы помочь не забыть что-то важное, разделы какие-то
18: Сущности. И, кстати, любые сущности, любые разделы можно исключать или дополнять. Разберём такой вопрос. Зачем тз погост описывается так много требований, которые напрямую не относятся к функциям системы. Ну, во первых, в 1 половине тз.
19: Не просто так приводятся общие сведения о системе и общие требования. Надо понять, зачем система создаётся, какие процессы будут автоматизироваться, что нужно сделать, чтобы сама система заработала и вроде бы банальные вещи, но без этих вещей команда в принципе может
20: Не понять сути проекта и для чего этот проект делается. Во вторых, организационные меры. То есть в этом документе должны прописаться все меры и все описание команды, то есть информационная система, например, это обученный персонал, программное обеспечение.
21: И аппаратный комплекс все вместе. И если привести пример без команды, например, у нас ничего не может быть. То есть, если в пример привести бухгалтерию, бухгалтеры смогут работать без компьютера на бумажке, делая свою работу, то есть составлять документы только при помощи
22: Листика и ручки, но программа 1 эс без них уже справиться не сможет, то есть тз это документ, в котором прописывается все необходимое для внедрения системы как персонал, так и сама система и все её комплектующие, а в третьих тз не на систему, а на создание системы.
23: То есть установи не только требования к самой системе. В документе прописываются все меры, которые должны выполняться для достижения результата. В четвёртых, как мы уже говорили, некоторые пункты могут быть исключены, ну или добавлены. Теперь мы перейдём к разделам.
24: Всего 9. И начнём мы с 1. 1 раздел это общие требования. Здесь приводятся общие сведения о приёмке работ. Например, то, что мы передаём документации, проводим ряд испытаний системы. Здесь мы только упоминаем о передаче
25: Результатов работ, а ниже эта тема раскрывается подробнее в других разделах и сразу перейдём на следующий раздел. Это назначение и цели создания системы. И кстати, на каждом слайде приведён пункт госта. То есть при желании можно будет открыть
26: Презентацию и ознакомиться с каждым пунктом подробнее вбить просто в гугле номер госта 2 раздел, назначение цели создания системы. Здесь надо понять разницу между назначением и целью создания системы с назначением. Вроде все понятно.
27: Мы приводим вид автоматизированной деятельности, например, если мы создаём какую-то систему для производственного учёта, то нужно приводить в эту систему объекты, автоматизация которых предполагается, ну вот с целью
28: Все немножко иначе. Цель это то, ради чего проект был начат. Можно назвать это как бизнес цель и выделить можно следующие цели проекта автоматизации это выполнение внешних требований, обеспечение работы нового технологического процесса.
29: Снижение операционных расходов, повышение качества работы и снижение рисков, повышение надёжности. И это касается не только технической стороны, но и также, например, если ваш сотрудник или коллега заболел, эти риски тоже должны предприниматься гости.
30: Также написано, что нужно приводить необходимые показатели. То есть если у нас за день 3 человека продают 20 каких-то наименований, то цель нашего проекта это чтобы 1 человек продавал тоже 20 наименований.
31: 1 день. То есть мы хотим показатель увеличить в 3 раза. Если эти цели есть, их тоже стоит прописать. В этом разделе перейдём в следующий раздел. 3 характеристики объекта автоматизации. Что такое вообще объект автоматизации под объектом подразумевается не сам объект, а процесс.
32: В этом объекте. То есть если опять же возьмём в пример склад, то автоматизировать нам нужно не сам склад, то есть то как стоят коробки в этом складе, а процессы кто, когда и как будет хранить или убирать эти коробки, в этом различие.
33: И в данном разделе стоит приводить описание заказчиков, то есть виды деятельности заказчиков, количество филиалов сотрудников, всю информацию о нём, сведения о пользователях системы, описание автоматизируемых объектов. Например, если мы автоматизируем
34: Я уже говорила, склад то нужно описать, какой он будет площади, сколько у него проходов. То есть все данные, даже вплоть до физических данных. И тогда мы поймём. И вообще люди, читающие дз, поймут, что мы конкретно зируем и как должен выглядеть.
35: Процесс для автоматизации того, что мы описали, описание автоматизированных процессов и также стоит перечень документов, в которых приводится подробное описание объекта автоматизации. Далее мы перейдём к 4 разделу. Это самый большой раздел, его можно поделить на 3
36: Дела это требования к системе в целом, требования к функциям системы и требования к видам обеспечения требования к системе в целом состоит ещё из 14 подпунктов. Мы с вами обсуждать каждый, конечно же, не будем, но я вкратце расскажу
37: О чем он в принципе, в подразделе требования к системе в целом приводятся нефункциональные общие требования, которые описывают создаваемую систему с разных сторон. И на слайде можно увидеть схемку. В принципе, если в этом разделе, в этом подпункте
38: Нарисовать схему, которая описывает всю систему, структуру и функционирование, то этот раздел полностью покроется, то есть 1 рисунком и 1 схемой. То есть нужно описать требования безопасности, надёжности численности, квалификации персонала, если такая информация
39: Есть, ну и описать саму систему. И, как я сказала, разделы можно или добавлять, или опускать, если они не нужны. Далее требования функции выполняемой системы на слайде представлен пример описания функции регистрации транспортного средства.
40: Системе. То есть это уже конкретный пример, который можно использовать для описания данного подраздела, и он должен дать общее представление о том, какая есть система. Данный раздел очень важен часто тз, который составляется на основе зарубежных стандартов или
41: Вообще, в принципе, без стандартов содержит только этот раздел, то есть требования к функциям, выполняемым системой. И если научиться его грамотно писать, то, в принципе, можно сказать, что стандартами вы пользоваться умеете. На слайде представлен пример, если
42: Обобщить и вынести какие-то рекомендации по тому, как это можно написать, то я бы вынесла 3. Это то, что документ должен органично делиться на нефункциональные и функциональные части. Лучше всего, если требования разбиты по пунктам. Так
43: Легче воспринимать и контролировать их выполнение и для функций, назначение которых неочевидно лучше прописывать комментарии, указывать цель и решаемую задачу, чтобы далее через какой-то промежуток времени посмотреть и самому не запутаться в том,
44: Что мы сделали или не сделали, перейдём к следующему подразделу. Это требования к видам обеспечения. Их 8. Это матобеспечение, информационное, лингвистическое, программное, техническое, метрологическое, организационное, методическое обеспечение.
45: Обеспечение это какие-либо функции сложные функции логические, которые есть у вас в системе. Это, например, расчет маршрута, расчет каких-то весов, информационное обеспечение это то какие данные у вас есть и какие данные
46: От компонента к компоненту. Лингвистическое обеспечение это все о языках, начиная от языка программирования, который вы используете при разработке системы, заканчивая языком, которым пользуется ваша команда для обмена данными. Следующий пункт программное обеспечении.
47: Это то, что следует купить для по какие-нибудь программы и так далее. Техническое обеспечение это то, что следует купить из железа и метрологическое обеспечение, это если у вас в системе какие-то датчики, то тоже следует их описать, как они
48: Функционирует, какие параметры на вход и на выход принимает организационно методическое обеспечение. Можно, в принципе, пропустить. Это то, какие документы должны подписать люди, которые работают у вас на проекте, чтобы работать с данным оборудованием, техническим обеспече.
49: И так далее. Раздел 5 это состав, содержание работ по созданию системы. Данный раздел это по сути, краткий план разработки и внедрения. И при его составлении можно привести большую таблицу, каждый пункт.
50: Этого списка, это колонка таблицы, то есть наименование этапа это 1 колонка, содержание работ для этапа это 2 колонка, результат ожидаемых работ, 3 колонка и так далее. То есть в такой таблице очень удобно могут описываться все этапы и очень наглядно
51: В виде таблицы. Далее 6 раздел это порядок контроля и приёмки системы. В данном разделе подробно описывается процесс приёмки системы заказчиком. То есть, что должен сделать заказчик для того, чтобы принять систему и чтобы она у него корректно работала, какие должны быть проведены
52: Испытания. Для этого, какие вообще есть испытания, испытания есть предварительные опытной эксплуатации и приёмочные. Предварительные испытания бывают автономные и комплексные. Автономные. Это без использования каких-то сторонних систем при тестах комплексные это
53: Тест в комплексе смежными системами. И если описать процесс испытаний простыми словами, то его можно поделить на 5 пунктов. Это предварительное автономные испытания, то есть тестирование проводится автономно, без интеграции, со смежными системами сторонними.
54: Предварительные автономные испытания испытывается вся система в целом предварительные комплексные испытания. Система испытывается в комплексном режиме, то есть есть взаимодействие с другими системами опытной эксплуатации. Это эксплуатация с реальными юзерами, которые могут тестировать
55: Систему и приёмочные испытания это последний вид проверки. То есть когда мы отдаём систему на тест заказчику и как же это все описать и в принципе, в каких документах для опытной эксплуатации нужно написать документ по программе опытной эксплуатации.
56: И указания для составления документа можно посмотреть 8 34 0 0 3 90. И для предварительных и приёмочных испытаний нужно написать документ, программа и методика предварительных испытаний и указания. Также для этого документа можно посмотреть
57: 34 63 92. И даже указаны пункты. Если что, можно будет к ним обратиться позже и в рабочем документе 50 34 698 90. Так что проблем с шаблонами, я думаю, точно не должно возникнуть. Ну что, переходим к следующему?
58: Раздела требования к составу и содержанию работ по подготовке объекта, автоматизации, к вводу системы в действие, какие документы вообще для всего этого нужны и каким госсом ссылаться, это мы уже изучили. В этой главе описывается процесс.
59: Называется внедрением системы туда, куда мы её поставляем. Это набор персонала, его обучение, заполнение учётных данных, создание учеток, развёртывание системы, развёртывание интеграций. И все эти процессы также должны быть хоть кратко, но описаны 8 раз.
60: Это требования к документам и документирование документы, это вообще управление проектом и проектный документооборот, документирование проекта автоматизации по гост может регламентироваться 3 стандартами, которые вы можете видеть на экране и в 1 стандарте.
61: Приводится перечень структурно документации, а во 2 указывается содержание следующих документов. Это документы технических проектов, документы, которые разрабатываются на предпроектных стадиях, и организационные документы, и последний, но
62: Не менее важный раздел это источники разработки, когда мы пишем какие-то документы, мы можем использовать, ну не литературу, но ссылаться к чему-то, например, на законы, на регламенты тоже на другие стандарты. И все это нужно размещать в источниках.
63: Разработки и источники разработки также можно поделить на несколько секций, если вы их использовали много, то есть материалы с описанием аналогов, материалы, описывающие общую систему и так далее, и последний
64: Ладно, не менее важный это план при разработке документации по гост. Какие же вообще действия нужно совершить, чтобы написать гост, если мы только начинаем свою работу с ними, с этими гостами? И 1 пункт это вообще выбор.
65: Нужный гост. Если у нас нет указаний от заказчика, если указания есть, то берём то, что есть и отдельно может понадобиться гост по оформлению. Далее нужно найти, обязательно проверить актуальность используемого госта. Ссылочка приведена тоже в комментарии внимательно нужн.
66: Прочитать весь стандарт, делать заметки о наиболее важных пунктах и желательно их сохранить. Чтобы потом не перечитывать при разработке, нужно обращаться к этим заметкам. И когда документ готов перечитать ещё раз и понять, все ли вы делали в соответствии со стандартом или
67: Нет, и, конечно, составление технического задания по гост нельзя назвать лёгким и простым заданием, это не потому, что ghost плохой, а просто host заставляет задуматься и подумать про весь проект, целиком расписать все мелочи этого проекта ну?
68: Зато хорошо составлены з, это половина успеха проекта. И сделав хорошее дз, можно смело начинать разработку. Всем большое спасибо за внимание. Спасибо. Так. Спасибо большое за классную презентацию. Интересно много всего. Да, безусловно так.
69: Есть над чем подумать. У меня такой вопрос практического характера. Я вижу запрос от клиента, который просит составить там тз, да, вот по этому госту 34. Ну, скажем так, максимально подробно и так далее, да, по твоим ощущениям, сколько времени?
70: А на это нужно и можно закладывать сколько на это нужно и можно закладывать по моим ощущениям, недели 2 на это точно можно заложить, но без учёта того, что каждый пункт должен отдельно согласовываться с заказчиком.
71: Не знаю, возможно, день на инвестигейт самого процесса и остальное время на проработку каждого пункта, потому что, как я уже сказала, документ большой документ подробный, и он описывает проект от и до. Но это с таким
72: Ну, в принципе, что мы знаем, что мы будем разрабатывать и какие цели у нашего проекта. То есть мой ответ это 2 недели, ну, грубо говоря, 80 часов рабочего, а там бизнес аналитика, либо технического писателя, да, без. То есть, мы сейчас говорим про неё.
73: Да, хорошо, спасибо. Так, коллеги, есть ещё у кого-нибудь вопросы? Я извиняюсь, может, пропустила, пока общалась с коллегами. Если на протяжении проекта именно уже самой технической разработки что-то изменяется, нужно ли эти изменения вносить в тз? Как
74: Говорила, каждый пункт тз должен согласовываться с заказчиком и каким-то образом документироваться. Я думаю, что если документ составлен таким образом, что правки могут вноситься, то да, без проблем, если же нет, если таких откатов нет.
75: И с заказчиком нет договорённости на то, что будут изменения. То, что написали, то написали без изменений. Но, в принципе, мне кажется, процесс договорный. И вообще, в принципе, вопрос. И такие моменты нужно обговаривать с заказчиками заранее, на
76: Этапе начала написания тз и правки вносить нужно будет. Поняла. Спасибо большое. Ну, у меня на самом деле есть вопрос, он такой простой, достаточно. Вот тз, да, вот Дима спросил, но написание качественного тз, оно реально может занять там как-то 2 недели и достаточно
77: Процесс, если нет у заказчика запроса на это, стоит ли его писать либо опустить, сделать что-то хай левел, такое какое-то описание и все. Я бы даже привела примеры наших проектов. То есть если нет какого-то запроса на тз, то мне кажется, документ может быть сотавлен.
78: Более формально, то есть тоже с хорошей детализацией, с хорошими там источниками, с подпунктами, с детальным описанием. Но шаблона придерживаться, наверное, уже не стоит, если нет такого запроса, потому что, опять же, вникнуть во все это разобра.
79: Дело непростое, и, как я сказала, что некоторые пункты там могут быть лишними, их, конечно же, можно выбрасывать, но легче, наверное, написать техническое задание, не придерживаясь какой-то чёткой структуры, не подстраиваясь под кого.
80: Дело более гибкое. Да, спасибо, кристин. Да. Ма, да, саш, я хотела тоже дополнить ответ на твой вопрос. На самом деле это стоит писать. Если это оплачивается. Если если это не оплачивается, то это писать не стоит, даже если это очень тут все просто.
81: Я согласна с Машей. Да, ещё раз, Кристина, спасибо большое.