Доброго времени суток!
Есть ли у кого-то опыт работы с KMS Lighthouse?
Если да, то расскажите, пожалуйста, вкратце, что и как на нём размещали)

Лекция интересная.
Но @factorized немного ошибается

А мне кажется, что все верно, но названия разные :)

SRS и спецификация не есть одно и тоже :)

Ну тут тонкий момент, конечно. Очень уж эти оба термина перегружены и многозначны

Но ТЗ в определениях ГОСТ34 и SRS в определениях IEEE 830 все-таки разные документы, с разным целеполаганием.

Не корректно сравнивать ГОСТ 34 и  IEEE 830. Один на систему, второй на ПО. аналогом  IEEE 830 является ГОСТ 19

А в ГОСТ 34, тот уровень который ты обозначил как ТЗ - это документ Концепция

Но все равно спасибо за лекцию.
Было полезно

> аналогом  IEEE 830 является ГОСТ 19

Я имел в виду IEEE 830 Recommended Practice for Software Requirements Specifications, он гораздо уже, чем ГОСТ 19

Про ТЗ по ГОСТ 34 давай поспорим:) ГОСТовское ТЗ, в моем понимании — это в первую очередь инструмент согласования ожиданий между высокоуровневыми стейкхолдерами, оно также применяется при «бизнесовой» приемке продукта.

Концепция тоже так может применяться?

>"Про ТЗ по ГОСТ 34 давай поспорим:) ГОСТовское ТЗ, в моем понимании — это в первую очередь инструмент согласования ожиданий между высокоуровневыми стейкхолдерами, оно применяется при «бизнесовой» приемке продукта."
ТЗ в любом случае инструмент согласования требований как и SRS, и как концепция.
У ТЗ и Концепции разный уровень детализации.
А вот что такое высокоуровневые и низкоуровневые стейкхолдеры, и чем бизнесовая приемка отличается  от небизнесовой - не понимаю.
Надо словари согласовать, прежде чем поспорить.

на самом деле ТЗ на создание АС по ГОСТ 34 это довольно подробный документ - подробнее обычного понимания ТЗ на практике

👍
И плюс несмотря на содержание самого ГОСТ и пояснений РД 50,
Есть немного разные трактовки, подхода к тому для как понимать некоторые аспекты ТЗ.
Например, понятие пользователя АС.

#вакансия #fulltime #wanted_tw

🔘Технический писатель в Ximi Lab
• вилка: 70 000-90 000 рублей, ТК РФ
• опыт работы: от года

🔘Необходимые навыки:
•опыт разработки проектной, технической и пользовательской документации;
•понимание идеи разработки документации по принципу единого источника.

🔘Задачи внутри команды:
•разработка, систематизация и поддержка в актуальном состоянии технической, эксплуатационной и пользовательской документации, а также регламентных документов;
•участие в разработке и внедрении шаблонов документов различного назначения;
•взаимодействие с командой.

🔘Мы предлагаем:
•соблюдение ТК РФ;
•возможность удаленного формата работы;
•офис м. Динамо.

🔘Контакты: @uskova_hr

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

Добавила. Не заметила сразу, что не полностью скопировала)

а есть спецы по Swagger2Markup API?

Всем привет. Кто-нибудь прикручивал публикацию документации из gitlab в confluence? markdown2confluence, Jenkins?

да, я прикручивала с помощью Sphinx sphinxcontribbuilder + Jenkins + docker,а в заметке на хабре описала этот и еще неск варианртов https://habr.com/ru/post/483898/

я так понимаю, что можно как с Cloud, так и с Server версией Confluence интегрироваться, верно?

да