WEBURSITET.RU

Онлайн-курсы профессиональной разработки ПО

Блог экспертов Вебурситета

Версионирование требований — запись вебинара

Запись вебинара «Версионирование требований», прошедшего 5 марта 2014 года в рамках серии дискуссионных вебинаров Сообщества аналитиков.

Ведущая: Ирина Сурова

О классификации требований – фрагмент вебинара

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

Вебинар проходил в рамках курса «Эффективная разработка требований».

 

О классификации требований from Grigoriy Pechenkin on Vimeo.

Использование системы управления требованиями Devprom в проектах заказной разработки по ГОСТ

Введение

Некоторое время назад мы с Алексеем Киселевым анонсировали старт работ по исследованию возможностей внедрения СУТ Devprom в проектах заказной разработки по ГОСТ.

Макет экрана работы с системой представлен ниже

Точное название системы — Devprom ALM, но нас интересовал этот продукт только с точки зрения управления требованиями, по крайней мере, на начальном этапе.

Мы не хотели, да и не могли кардинально менять существующие процессы разработки, основная суть которых заключалась в требованиях ГОСТ 19, 34 и 2.105.

Нашей задачей было предложить систему управления требованиями для аналитиков нашего отдела, которая позволила бы по-прежнему работать с отчуждаемыми документами (ТЗ и ЧТЗ, или, как мы их называем, постановками на разработку).

СУТ должна была позволить:

— экспортировать/импортировать документы MS Word, содержащие форматирование стилями с использованием фильтров;

— работать с атрибутами требований;

— работать с запросами на изменение;

— работать с версиями требований;

— делать трассировки требований между собой и на задачи в Jira (в перспективе).

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

Предпосылки к внедрению Devprom ALM как средства управления требованиями

Пока среди аналитиков ведутся обсуждения, как оценить эффект от внедрения Средства Управления Требованиями (СУТ) — мы просто взяли систему и сделали на ней некое подобие пилотного проекта (как и все пионеры внедрения СУТ).

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

В процессе аналитической работы на наших проектах наблюдаются следующие проблемы:

  • Требования с незначительной периодичностью теряются;
  • В требованиях тяжело найти нужную версию;
  • Влияние новых требований на проект оценивается аналитиком, опираясь исключительно на его опыт и незатуманенную память;
  • Надо делать Excel-таблицы для выявления степени покрытия требований заказчика постановками;
  • Так как людей запрещено приковывать к батареям и/или отбирать у них паспорта, а аналитики относятся к категории людей, то необходимо хранить полную историю изменений требований, их взаимосвязи (особенно, если речь идёт о связанных нескольких проектах) источники. А ещё их надо уметь быстро и правильно находить. Это трудоемкая задача, которую тяжеловато делать исключительно в вышеупомянутом Excel и Word: сразу хочется как-то автоматизировать поддержание актуальности ссылок, дабы не пребывать в глубочайшей депрессии в момент их актуализации.

Как программисты SQL от юзеров спасли

Все знают, что SQL — это сакральный язык манипулирования данными. Знание SQL отделяет избранных от простых смертных. Знание SQL даёт власть и славу. Власть над компьютерами. Славу среди прекрасных жриц HR, готовых на всё ради знакомства с гуру SQL. Наличие заветных трёх букв в резюме сразу даёт понять: перед вами реальный айтишник, а не презираемый всеми гуманитарий.

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

Пользовательские истории — требования или нет?

В своей книге «Agile Software Requirements» Дин Леффингуэл сделал заявление, которое сбивает с толку не только приверженцев «лёгких методологий», но и опытных аналитиков.

Заявление выглядит так:

User Stories Are Not Requirements

Пользовательские истории — это не требования

Конечно, кажется странным, зачем детально описывать что то, что не является требованиями, в книге с названием «Гибкие требования». Но давайте попробуем разобраться, что же автор на самом деле имел в виду.

У понятия «требование к ПО» много определений. Пожалуй, общепризнанным является определение IEEE:

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

Пользовательские истории идеально подходят под это определение. Общепринятый формат пользовательской истории — это описание возможности, в котором обозначен и пользователь, и его цель или задача. В чём же дело?

Как мы проводим онлайн-курсы

Онлайн-курсы проводятся в формате вебинаров. Вебинар — это обычный учебный семинар, на котором преподаватель выступает и демонстрирует слайды презентации. Только проводится он дистанционно.

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

 

Введение в профессию аналитика - запись вебинара и ответы на вопросы

Запись вводного вебинара курса «Разработка и управления требованиями к ПО» от 14 марта 2013 года.

 

Вопросы: “Аналитик. Введение в профессию”

Q: Отчего отдельно вынесены навыки организации именно совещаний?[Сергей]

Я вынес это в отдельный навык, т.к. организация и проведение совещания - это отдельная процедура, которую Аналитик использует наиболее часто для взаимодействия с заказчиками и членами команды.

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

1. Подготовка и организация встречи

2. Проведение встречи, фасилитация участников, быстрый анализ на встрече

3. Обработка и согласование результатов встречи

Навыку организации совещаний уделено отдельное внимание в модуле “Сбор требований”.

Партнёры и друзья



Продолжая использовать этот сайт, вы даете согласие на обработку файлов cookie, пользовательских данных (включая сведения о местоположении, тип и версия ОС, тип и версия браузера, тип устройства и разрешение его экрана, источник откуда пришел на сайт пользователь, с какого сайта или по какой рекламе, язык ОС и Браузера, какие страницы открывает и на какие кнопки нажимает пользователь, IP-адрес). Если вы не хотите, чтобы ваши данные обрабатывались, пожалуйста, покиньте сайт. Вы можете узнать, как используются эти данные, ознакомившись с Политикой конфиденциальности.
Ясно, больше не показывать это сообщение