Рубрика «документация» - 7

Зачем, кому это нужно, чем это сделать

Не раз задавалась вопросом: как бы так комфортно организовать входящие требования к системе — на этапе, когда требования только собираются, когда формируются вопросы и озвучиваются ответы, а ещё всё постоянно меняется и пересматривается, а ещё когда в реализации задействовано несколько систем, а ещё, а ещё…
При этом очень бы хотелось:

  • видеть связь: требование➝вопрос➝изменение в требовании➝новое требование;
  • избежать дублирования требований/вопросов;
  • отследить задействованные в реализации системы (от обратного: чтобы представитель каждой системы видел требования, реализация которых хоть как-то касается его системы);
  • получать подтверждение по каждому требованию — что да, требование понято и зафиксировано верно, что реализация возможна;
  • проследить связь с требованиями другого, очень похожего на наш проект проекта — чтобы иметь знание, что вот это уже там реализовано, и мы будем просто использовать сделанные наработки;

Да и вообще.
Читать полностью »

Введение

В данной статье рассматривается вопрос о том, как реализовать обмен типизированными сообщениями между Back-End на основе ASP.NET Web API и Front-End, созданного с использованием TypeScript. Это приобретает особенное значение при работе над объёмными проектами, и тем-более важно, если команда является распределенной. Например, когда Back-End и Front-End разработчики работают из разных мест, в разных часовых поясах, и не всегда имеют возможность проконтактировать и обсудить что-либо. В этом случае отслеживание изменений представляет кропотливую работу, которая может быть чревата множеством трудноуловимых ошибок.

Для автора статьи, как для человека, который пришел к разработке Front-End со стороны WPF и Silverlight, большой проблемой, стало отсутствие статической типизации. Сколько раз вместо того чтобы сложить “2” и “2” складывал “2” и “Функцию возвращающую 2”, или передавал DOM объект вместо его jQuery обертки. Появление статических анализаторов кода, таких как JSLint, несколько облегчило проблему, но настоящим прорывом, особенно в командной разработке, для нас стал TypeScript.

На пути к полной типизации с TypeScript, Swashbuckle и AutoRest - 1
Читать полностью »

Это статья о том, как организовать требования на крупном проекте с кучей подпроектов, которые постоянно изменяются; организовать требования так, чтобы читателям было счастливо и уютно их читать (насколько это возможно для технической документации), а писателям — писать.

Речь идёт об организации готовых требований (требования уже получены и сформулированы, и теперь с ними ведётся работа). И в данном контексте требование — это описание некой функциональности (в моём случае — к сайту), на языке, понятном разработчику, заказчику, простому смертному, дающее представление о том, «как это должно работать».

То, что написано ниже, — не есть истина в последней инстанции, это лишь описание проблем, с которыми команда разработки сталкивается в работе с требованиями ежедневно, и инструменты, с помощью которых можно их решить.
Читать полностью »

Работая над проектами связанными с авионикой мне потребовалось оформить несколько комплектов документации с полным описанием проекта. Также следовало учитывать требования многих ГОСТов на оформление и на содержание документации, таких как ЕСПД, КТ-178B и других.

Описание должно было в себя включать:

  • Планы разработки ПО
  • Требования к ПО
  • Описание реализации требований к ПО
  • Таблицы трассируемости(соответствия) требований к ПО и реализации
  • Описание тестов на ПО (Примеры и процедуры верификации ПО)
  • Таблицы трассируемости(соответствия) требований к ПО и тестов
  • Отчет об обнаруженных проблемах
  • Указатель конфигурации(описание версии ПО и совместимости со сторонним ПО и оборудованием)

Объем документирования очень большой. Данные во всех документах связаны друг с другом, поэтому при изменении проекта (например добавления нового требования), приходится редактировать практически все документы. Плюс к этому можно где-то ошибиться или забыть поправить, что приводит к ошибкам в документации.

Автоматизация оформления документации - 1

Далее в статье я расскажу как я решил эту проблему.

Читать полностью »

SFML и Xcode (Mac OS X) - 1

От переводчика: данная статья является четвертой в цикле переводов официального руководства по библиотеке SFML. Прошлую статью можно найти тут. Данный цикл статей ставит своей целью предоставить людям, не знающим язык оригинала, возможность ознакомится с этой библиотекой. SFML — это простая и кроссплатформенная мультимедиа библиотека. SFML обеспечивает простой интерфейс для разработки игр и прочих мультимедийных приложений. Оригинал статьи можно найти тут. Начнем.
Читать полностью »

SFML и Linux - 1

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

SFML и Code::Blocks (MinGW) - 1

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

SFML и Visual Studio - 1

От переводчика: данная статья является первой в цикле переводов официального руководства по библиотеке SFML. Данный цикл статей ставит своей целью предоставить людям, не знающим язык оригинала, возможность ознакомится с этой библиотекой. Оригинал можно найти тут. Начнем.
Читать полностью »

image
В этой статье я привожу примеры основных принципов или концепций, которыми руководствуюсь при проектировании десктопных интерфейсов. Не планирую выступать новатором или поучителем, но с радостью поделюсь набором установок, который помогает мне в работе.Читать полностью »

Sinon.js — это mock-библиотека для JavaScript, которую можно использовать с любым тестовым фреймворком. Она предоставляет функции для эмуляции и проверки требуемого поведения в JavaScript. В библиотеке представлено три вида тестирования с spy, stub и mock. В данном посте мы рассмотрим документацию по API Sinon.js вместе с кратким введением в концепцию методов данной библиотеки.

Sinon.js — mock-библиотека для JavaScript - 1
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js