WEBURSITET.RU

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

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

Почему сайт — это не автоматизированная система

Начал отвечать на вопрос, заданный на форуме Сообщества аналитиков, и понял, что получилась целая небольшая статья.

Вопрос был задан как комментарий к моему заявлению:

— Мне категорически не нравится идея подводить однопользовательские приложения в веб под определение АС.

— А почему? Чем чревато?

Краткий ответ такой: чревато тем, что вместо сайта у вас получится АС, а пользователей к этому жизнь не готовила. :)

Более подробный ответ ниже.

Терминологические ловушки ГОСТ 34

ГОСТ - это законодательно утвержденный феншуй!
(Народное творчество)

 

Тернист и сложен путь аналитика, впервые выбравшего ГОСТ 34 для описания требований к системе. Опасности подстерегают его на каждом шагу.

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

 

Ловушка первая. Пользователь.

Вот, например, смотрит аналитик на описание жизненного цикла процесса создания системы, и видит в нём первый этап:
1 Формирование требований к АС
1.1 Обследование объекта и обоснование необходимости создания АС
1.2 Формирование требований пользователя к АС

При виде этого текста аналитик радуется: такие знакомые слова — требования, пользователь. И делает вывод:

«На базе полученных данных необходимо выявить основные функциональные и пользовательские требования к АС.» (Цитата отсюда http://www.it-gost.ru/content/view/93/51/).

Всё прямо по Вигерсу — вот же они, эти требования, на картинке!

Ан нет. Здесь его подстерегает первая ловушка.

Зачем нужны диаграммы?

При обсуждении статьи о самых главных диаграммах в фейсбуке мне задали вопрос: «Зачем вообще описывать деятельность в виде диаграммы? Или более общим образом — зачем нужно моделировать? А то это как-то выпало из статьи, как типа очевидное (а на самом деле нет)».

Вопрос о том, зачем вообще нужно моделировать, мы пока оставим открытым. Очень уж он всеобъемлющ. По большому счёту, всю нашу разумную (и не только разумную) деятельность можно свести к моделированию.

А вопрос о диаграммах я позволю себе переформулировать так, как я его понял: зачем нужно визуальное моделирование при разработке ПО?

 

Самые главные диаграммы

Из всего многообразия диаграмм, которые используются при моделировании и разработке ПО, главными я считаю всего три.

Все они вам хорошо знакомы, хотя часто маскируются под разными названиями.

Это:

  • диаграмма последовательности действий;

  • диаграмма смены состояний;

  • диаграмма взаимодействия объектов.

Почему они главные?

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

Во-вторых (которое проистекает из «во-первых»), они представляют набор, достаточный для моделирования любых процессов, причём на любом уровне детализации.

Давайте посмотрим на них поближе.

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

Запись вебинара «Версионирование требований», прошедшего 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-адрес). Если вы не хотите, чтобы ваши данные обрабатывались, пожалуйста, покиньте сайт. Вы можете узнать, как используются эти данные, ознакомившись с Политикой конфиденциальности.
Ясно, больше не показывать это сообщение