Исправлена ошибка с обязательностью поля Результат, если при этом список значений пуст.

Исправлена ошибка, возникающая при применении ранее сохраненного шаблона проекта.

Исправлена ошибка отображения тэгов (например, XML-тэгов) в теле вопроса или при отображении списка вопросов.

Исправлена ошибка отображения текста в требованиях и тестовых сценариях в браузере Safari.

Исправлена ошибка отображения фильтра "Начало" на странице истории изменений требования.

Исправлена ошибка сортировки списка Мои задачи (в портфеле Мои проекты) по полю "Состояние".

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

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

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

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

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

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