Вопрос коллегам: С какими трудностями вы сталкиваетесь при работе с требованиями?
У нас есть большущее желание собрать перечень проблем, сложностей, препятствий, реалий и всего-всего, что может мешать и затруднять сбор, анализ, оформление, согласование и реализацию требований. Интересны любые сложности:
- организационные внешние, между заказчиком и исполнителем;
- организационные внутренние, в рамках команды разработки;
- методологические, сложности в выборе подходов, методов, артефактов;
- любые другие.
Важно, чтобы эти трудности были реальными и конкретными, а не общими. Примеры некорректных сложностей: «Как грамотно выявлять требования?», «Как оформлять требования?», «С помощью чего контролировать изменения требований?». На такие вопросы ответы отличаются лишь названиями книг.
У вас есть конкретные проблемы, с которыми столкнулись в своей работе Вы или Ваши коллеги? Оставьте описание проблемы в комментарии к этой записи, и мы постараемся вместе с ней разобраться и выработать решение!
Провести курс по ООАП
На прошлой неделе один из консультантов команды по управлению требованиями BeamTeam.ru провёл в учебном центре компании Luxoft курс «Объектно-ориентированный анализ и проектирование с использованием UML«. Курс длился 5 дней по 4 часа (20 часов). Участники состояли из специалистов, выполняющих в проектных командах роли системных аналитиков и разработчиков. В ходе курса были затронуты такие темы объектно-ориентированной разработки read more…
Ляпы в документах
Сижу и вычитываю документацию по проекту, медленно сползаю под стол. То, что мне встречается по тексту и как не нужно писать, привожу ниже.
- Глоссарий и перечень сокращений и аббревиатур – это важно и хорошо. Но первое упоминание в тексте должно быть полным. Не нужно при первом удобном случае писать «ТЗ», напишите сначала «Техническое задание (далее – ТЗ)».
- Какие бы сокращения и короткие названия вы ни использовали (Система, Заказчик, Исполнитель, прочие), пишите их однообразно по всем документам проекта: либо все со строчной, либо все с прописной буквы. read more…
Семинар по визуальному моделирования и UML
На днях один из консультантов команды по управлению требованиями BeamTeam провёл в учебном центре компании Luxoft семинар «Введение в основы визуального моделирования и UML«. Семинар длился 2 астрономических часа и был бесплатным для всех слушателей. Вопреки ожиданиям и обычной вместимости аудитории в 24 человека семинар посетили более 30 человек. Слушатели состояли из специалистов, выполняющих в проектных командах роли системных аналитиков, архитекторов, разработчиков, руководителей проектов. На семинаре были затронуты такие фундаментальные для объектно-ориентированного мира темы read more…
CRUD: Create, read, update, delete
Создать, просмотреть, изменить и удалить — стандартные операции, которые пользователь системы может произвести над некоторым информационныем объектом. А английском эти оперции create, read, update, delete сокращают как CRUD. Мы же по аналогии назовем эту группу операций СПИУ. Вопрос, волнующий многих: нужно ли для каждой или части этих операций создавать отдельный вариант использования? read more…
На одной из международных площадок по обсуждению инструмента вариантов использования разгорелась дискуссия о том, каким образом можно отображить последовательность вызова вариантов использования (сокращенно — ВИ).
Варианты использования предназначены для описания целей пользователей и способов достижения этих целей, формируя границы системы. Обычно последовательности взаимодействий в рамках одного ВИ фиксируются 2 способами: текстовая спецификация взаимодействий актёр-система или диаграмма последовательности и деятельности (sequence diagram, activity diagram). Диаграммы ВИ являются структурными и не несут в себе информацию о времени и последовательности вызова ВИ. К тому же изначально они и не создавались для отражения взаимодействия между процессами.
Далее приведены 5 вариантов фиксации последовательности вызова вариантов использования, предложенные 20 коллегами из разных стран. read more…
- Выработайте ясные цели и задачи по их достижению.
- Определите важные задачи и НЕважные задачи.
- Решайте задачи по-отдельности.
- По утрам съедайте «лягушку».
- Наведите порядок на рабочем столе.
- Найдите и постоянно совершенствуйте главный навык.
- Откажитесь от того, что тяготит.
- Поддерживайте гармонию в жизни и высокий уровень энергии.
- Действуйте быстро!
Эти и другие советы от гуру личной эффективности Брайна Трейси вы найдете в конспекте книги «Управляй своим временем и удвой результаты» ниже. read more…
Вы применяете инструмент вариантов использования (ВИ) для сбора и формализации требований к системе. Актёр — это некто или нечто внешнее по отношению к разрабатываемой системе. Каких типов могут быть актёры?
Типизация по отношению к системе в целом
По отношению к системе в целом можно выделить 4 группы актёров:
- Пользователи;
- Программные системы (отличные от разрабатываемой);
- Аппаратные/технические средства, приборы;
- Время.
Типизация по отношению к конкретному варианту использования
1. по характеру взаимодействия
Актёр, инициирующий ВИ — приводит ВИ в действие, запускает выполнение ВИ. Все другие актёры, принимающие участие во взаимодействии, зовутся участвующими акётрами. На диаграмме вариантов использования эта разница отражается направлением ассоциации read more…
Verification - постоянно выполняемый аналитический процесс проверки того, что разработка находится на правильном пути: каждый этап разработки является корректным, необходимым (не лишним) и удовлетворяет потребности следующего этапа. Проводится на всех этапах разработки. На каждом этапе следует убеждаться, что сделали именно то, что планировали, и это соответствует общей логике разработке. «Мы создаем систему правильно».
Validation (проверка правильности) — процесс проверки того, что реализованная система удовлетворяет предъявленным требованиям и работает так, как предполагалось. «Мы создаем правильную систему».
А теперь давайте рассмотрим эти 2 процесса подробнее. read more…
Текст ниже является кратким конспектом главы книги «Принципы работы с требованиями к программному обеспечению. Унифицированный подход» двух гуру: Дина Леффингуэлла и Дона Уидрига.
Анализ проблемы проводится на самом ранней стадии процесса выявления требований.
Проблема – это разница между желаемым и воспринимаемым.
Анализ проблемы – это процесс осознания реальных проблем и потребностей пользователей для предложения решений, позволяющих удовлетворить эти потребности.
Шаги анализа проблемы
1. Цель анализа проблемы
Целью проведения анализа проблемы является:
- добиться лучшего понимания решаемой проблемы до начала разработки;
- понять их проблему в их предметной области на их языке, чтобы построить систему, удовлетворяющую их потребностям. read more…
