Все части Часть 1. Вводная Часть 2. Цели и потребности Часть 3. Функции системы и границы проекта Часть 4. Бизнес-процессы, автоматизированные системой Часть 5. Сущности предметной области и немного о стратегиях Часть 6. Поведение системы.
Улучшение требований Часть 7. Передача требований в производство.
Заключение
Пролог
Читая статьи об управлении проектами на этом сайте, часто чувствуешь разрывающуюся боль менеджеров, вызванную неэффективным использованием ресурсов в проекте.И одна из главных причин этих проблем — отсутствие качественных задач по разработке продукта.
Эта проблема может проявляться в разных симптомах: в виде трудностей с делегированием абстрактных, расплывчатых задач или взаимного непонимания на собраниях относительно решений, которые только у всех в голове, а преподносятся они совершенно по-разному.
В своей статье «О качестве требований в ИТ-проектах, честно говоря (с позиции команды разработки)» Я постарался подойти к решению этих задач более конкретно и рассказал из своего опыта, как можно трансформировать собранные требования по автоматизации в ИТ-проекте таким образом, чтобы максимизировать эффективность команды по их воплощению в целевой продукт. Повышение именно за счет четко сформулированных задач по разработке продукта, охватывающих весь процесс.
Теперь я хочу рассказать вам, как можно качественно сформулировать сами требования, ведущие Заказчика от его «хотелок» к его счастливому и плодотворному сосуществованию с программным продуктом, его мечтами.
Подробнее об авторских тренингах по теме: «Обучение проектированию программного обеспечения» вы можете узнать на сайте мой канал на YouTube
Введение
.Для кого и для чего предназначена данная публикация: В начале своей карьеры я работал программистом, руководил командой разработчиков и занимался кодированием, кодированием, кодированием.чтобы понять, какой метод формулирования требований подходит именно вам, следует опираться на здравый смысл и собственный опыт. Карл Вигерс
Но спустя 18 лет я решил сменить род деятельности, погрузившись в сферу системного анализа и управления проектами.
Поскольку так получилось, что предприятия, где мне посчастливилось работать, не предоставляли должностей: аналитика, менеджера проектов, менеджера по продукту и других экзотичных для меня на тот момент специальностей, программистам приходилось самим управлять проектной деятельностью перечисленных специализаций.
, так или иначе.
Естественно, эти же действия выполнялись не очень профессионально; на все не хватало ни времени, ни фундаментальных знаний.
Чтобы восполнить эти пробелы, я покорно прошел курсы по разработке функциональных требований, методологиям RUP, SADT, UML и т. д. И через некоторое время мне посчастливилось устроиться на работу в одну из ведущих компаний-разработчиков программного обеспечения на должность с претенциозным названием.
: «ведущий специалист по работе с клиентами».
Работодатель, зная, что у меня нет опыта профессионального аналитика, а есть только желание, богатство теоретических знаний и большой практический опыт разработчика, дал мне две книги [1], [3] и «приказал» быть готовым написать качественные за пару месяцев технические требования к разработке ПО.
Из моего опыта работы программистом диаграммы классов были для меня самым близким и родным.
И естественно это первое, за что я пытался зацепиться.
При этом я пробовал писать Use Cases по Коберну [3], он очень «миленько» излагает свои мысли, просто хочу попробовать подготовить что-то подобное.
Варианты оказались громоздкими и заумными; сначала нужно было понять форму этих опций, а уж потом содержание.
Было неудобно с ними работать.
Более удачными, на мой взгляд, оказались спецификации требований, созданные по шаблонам, найденным в RUP. В результате адаптации я понял, что, изучив некоторые базовые методологии и приемы из области управления требованиями, имею смутное представление о том, с чего начать, какую последовательность шагов предпринять, какой должен быть оптимальный объем контент на каждом этапе проектирования.
Люди, которым были уготованы плоды моего труда, получили лишь совокупность разрозненных артефактов проекта, использование которых не могло быть эффективно применено.
И хотя в теории все было прозрачно и понятно, в моем конкретном проекте все было как-то не так.
Теорию системного анализа я воспринимал как искусство: изящные и гармоничные диаграммы, новые и креативные идеи, а практика требовала конечного результата для конкретного проекта.
Мораль: набор ингредиентов, даже самых лучших, и книга рецептов приготовления блюда из них не всегда позволяют изготовить качественный продукт. Помимо знаний нужны практические навыки, опыт, творческие способности и, в конечном итоге, приобретенная интуиция.Практический опыт участия в проектах чрезвычайно важен для аналитика.
Только оно позволит трансформировать полученные знания в навыки и умения, необходимые для формирования качественных требований.
Со временем специалист приобретает определенную «ловкость» в выявлении потребностей заказчика, способность быстро и точно определять сущности и явления, которые заказчик зачастую не в состоянии сформулировать даже для себя.
А также вырабатывается умение определять окружение основных объектов и участников предметной области, так или иначе влияющих на нее, но остающихся в тени для неопытного глаза.
Еще одним важным аспектом обучения управлению требованиями является подготовка аналитика в области управления персоналом.
Тема личной эффективности специалиста практически не освещается в работах, посвященных работе с требованиями.
А отсутствие навыков такого рода существенно затрудняет успешную самореализацию аналитика как профессионала.
Функции проекта в разных командах не всегда строго регламентированы, а часто размыты между ролями проекта.
Следовательно, чем шире навыки аналитика в смежных проектных дисциплинах, тем выше его шансы добиться успеха на практике.
Все эти мысли заставили меня сесть за написание книги, которую мне хотелось бы прочитать в начале моей карьеры системного аналитика.
Основные цели этой книги: Показать на примерах возможные варианты «технологических линий» процесса проектирования программного продукта.
Определить и структурировать приемы и приемы для каждого этапа разработки Требований.
Выберите варианты использования этих методов применительно к различным областям принятия решений.
Описать методы управления, которые позволяют аналитику общаться с заинтересованными сторонами и эффективно продвигать результаты его работы в проекте.
Определить ключевые моменты в процессе разработки Требований к созданию программного обеспечения, на которых следует сделать акцент. Итак, начнем.
II Введение
В настоящее время имеется большое количество литературы по управлению требованиями.Большинство работ можно разделить на четыре группы: Предоставление теоретической информации, описывающей ту или иную фундаментальную «тяжелую» методологию, например: RUP или SADT. Эти методологии чрезвычайно эффективны и полезны при применении к крупным проектам.
Но их использование требует длительного процесса обучения, включая обучение или практику в компаниях, в которых они уже успешно используются.
Классической работой для аналитиков этой группы можно считать [1], [2].
Представление академической точки зрения на процессы в области управления требованиями.
Лично мне очень помогли книги [4], [5].
«экскурс в различные технологии в форме сравнительных обзоров.
На мой взгляд, книга [6] является наиболее удачной работой аналитиков этой группы, хотя ее также можно отнести к группе академических работ. Выбор методологии для использования в различных проектах компактно и наглядно описан в статье [9].
Практические идеи представлены в виде «облегченных» методологий, чаще всего предназначенных для небольших проектов, например: ICONIX, eXtreme Programmingprocess [7], [10] и т. д. Такие методологии можно относительно быстро использовать в небольших командах.
Данная публикация не претендует на звание академической работы или методологии проектирования.
Скорее всего, его можно позиционировать как семинар, обучающий некоторым вариантам процесса разработки и управления функциональными требованиями.
В своей работе я представляю различные техники и методики, проверенные на практике.
Публикация представлена в форме повествования.
В нем не приводятся определения и пояснения принципов и основ процесса разработки требований, а используются ссылки на публикации, где соответствующая тема раскрыта полностью.
Чтобы понять представленный материал, читатель должен иметь представление о дисциплине системного анализа.
Все разделы издания снабжены картинками, имитирующими изображения тех или иных событий, процессов, сущностей (вернее их важнейших для нас аспектов), происходящих в реальном мире.
По мере раскрытия материала от раздела к разделу модели дополняются и детализируются, показывая динамику процесса проектирования.
Также на протяжении всей презентации мы будем вместе с вами рассматривать вполне реальный проект: «Автоматизация процесса управления требованиями».
III Подготовка ландшафта для работы команды
«Любой пейзаж — идеальное тело для выражения определенной системы мысли».Новалис
Разработка требований и документирование проекта для сложных продуктов — длительный процесс, к тому же очень кропотливый и требующий слаженной командной работы.
Поэтому с самого начала необходимо продумать и подготовить ландшафт (среду обитания), в котором будет происходить этот процесс.
На мой взгляд, обеспечение комфортной среды для работы с артефактами проекта, а также общения участников друг с другом является одним из ключевых аспектов его (проекта) успешного завершения.
Цель данной группы работ: подготовить условия для качественного и эффективного взаимодействия команды проекта в рамках разработки и реализации требований к целевому продукту.
Проект автоматизации предприятия чаще всего связан с многочисленными изменениями в самой организации.
Эксперты в области управления изменениями советуют перед началом работы пройти этапы «мотивации» и «обучения» сотрудников, поскольку управление изменениями, прежде всего, — это управление взаимоотношениями и эмоциональными состояниями людей.
Поэтому для успешного продвижения проекта необходимо мотивировать не только команду разработчиков, но и участников, представляющих сторону заказчика.
Не пренебрегайте этим, так как это один из важнейших факторов успеха, как для разработки требований к качеству, так и для всего проекта.
Стоит обратить особое внимание на необходимость при работе с заказчиками создавать у своих сотрудников постоянную эмоциональную мотивацию, которая будет стимулировать их проявлять интерес ко всему, что происходит в проекте.
А еще лучше — заставить их конкурировать друг с другом с точки зрения полезности для проекта.
Для этого существует множество методов и техник, в том числе: презентации, дискуссии, тренинги и т.д. Практически любой ИТ-проект начинается со сбора информации о бизнес-процессах, подлежащих автоматизации, их операционной среде и т. д. Цель этого процесса — достижение согласия всех заинтересованных сторон в единой интерпретации конечного результата проекта.
Поскольку участники проекта имеют разный уровень подготовки в области работы с информацией, материалы должны быть представлены в разнообразных (но заранее определенных) формах, понятных разным группам.
Другими словами, с разной степенью детализации, уровнем абстракции, использованием обозначений и другими характеристиками.
Поэтому давайте сразу разделим контент проекта как минимум на два домена: Информация об первоначальном видении с точки зрения потребителей будущего продукта, называемого «проблемной зоной».
Основано на знании реального мира, в котором существует проблема.
Информация о реализации — взгляд разработчика, называемый «объемом решения».
На основе знания технологической области, в которой решение может быть реализовано.
Требования, хоть и в разных пропорциях, собираются на протяжении всего проекта и соответственно все это время влияют на ход его реализации и конечный результат. Чтобы конечный продукт максимально удовлетворял потребности заказчика, которые, как мы выяснили, могут меняться в ходе их реализации, необходимо поддерживать тесный и продуктивный диалог с потребителем конечного продукта на протяжении всего проекта.
К этому тезису мы будем постоянно возвращаться в процессе изложения материала, поскольку он является ключевым.
Исходя из вышеизложенного, очень важно, чтобы обе области проекта: «проблемная область» и «область решения» изменялись синхронно и зависели друг от друга.
Поэтому с самого начала проекта неплохо иметь «дискуссионную площадку» с информацией, понятной всем участникам.
Сайт должен выступать в роли «витрины» проекта и может быть как виртуальным (например: WEB-портал), так и реальным (например: помещение со стендом), размещая ключевую информацию о контенте, текущем состоянии и ближайших планах проекта.
проект. Постоянное взаимное общение между представителями каждой точки зрения помогает эффективно бороться с проблемами неверных предположений сторон: Проблема, описанная заказчиком, может быть не той, которую ему действительно нужно решить.
Решение, описанное разработчиками, может отличаться от того, что они создают на самом деле.
На рисунке 3.1 показана модель взаимодействия команды проекта в процессе создания и использования контента проекта («проблемные области» и «области решения»).
Рисунок 3.1 – Модель процесса взаимодействия проектной команды
На этапе подготовки ландшафта проекта начинают формироваться списки заинтересованных сторон.
Важно не упустить никого, на кого так или иначе влияет процесс и/или результат создания нового продукта.
Заинтересованными сторонами проекта могут быть не только будущие пользователи системы и команда проекта, но и различные должностные лица заказчика, инвесторы, эксперты по эргономике, должностные лица органов стандартизации и регулирования и т.д. Этот список может пополняться и уточняться на протяжении всего проекта, по мере Требования формируются и уточняются.
Список удобно составить в виде таблиц, в которых помимо имени заинтересованного лица необходимо уточнить его цели, классифицировать его компетентность и роль в проекте.
Ниже приведен пример использования таблиц для создания списка заинтересованных сторон проекта: 
Еще одним целесообразным шагом для формирования ландшафта проекта является публикация на его «витрине» словаря (глоссария), который послужит для вашей команды инструментом достижения консенсуса в интерпретации объектов и явлений предметной области.
Это позволит клиентам и разработчикам общаться в спорах «на одном языке».
Опыт показывает, что использование глоссария экономит массу времени, а главное, нервов, поскольку зачастую заказчики и исполнители тратят его на споры «каждый о своем», возникающие только из-за разницы в понимании одного и того же термина.
Например, слово «Пейзаж», использованное в названии, может трактоваться очень по-разному в зависимости от области применения.
Но в контексте нашего проекта добавим в глоссарий следующее определение: 
Глоссарий может обновляться на протяжении всего жизненного цикла проекта, поэтому по мере развития нашего проекта в публикации мы будем определять термины, которые могут вызывать разные интерпретации.
Как видно из этой главы, в ней особое внимание уделяется активному взаимодействию аналитика со всеми заинтересованными сторонами проекта, а точнее, их постоянной эмоциональной вовлеченности в разработку требований.
Китайская народная мудрость: «Скажи мне, и я забуду».Постоянно напоминайте себе, что аналитик создает требования «не ради искусства», а как промежуточный продукт, используемый в цепочке разработки ПО.Покажи мне, и я запомню.
Привлеките меня, и я научусь».
Привлечь к его формированию как можно больше заинтересованных сторон.
Дайте команде чувство собственности на продукт. Даже если вы знаете ответы, задавайте вопросы.
Задавайте вопросы так, чтобы они могли дать нужный вам ответ, и люди воспримут это решение как свое собственное.
Как видно из рисунка 3.1, с одной стороны требований имеем Заказчик, в другой команде для реализации целевого продукта.
Поэтому, когда я говорю о вовлечении стейкхолдеров, я имею в виду не только Заказчика, но и архитекторов, менеджеров проектов, тимлидов, ведь именно для них в конечном итоге и предназначена ваша работа.
Советуйтесь с ними, учитесь у них, будьте одним из них.
Это не просто звонки; тогда я поделюсь с вами своими наблюдениями о том, как это на самом деле можно сделать.
В следующей части мы сформулируем цели проекта, определим участников и заинтересованных лиц, их выгоды и потребности и перейдем к выявлению общих потребностей заказчика.
связь .
Подробнее об авторских тренингах по теме: «Практика формирования требований в ИТ-проектах» можно узнать на сайте компании.
ООО СК «Таврида» Библиография 1. Джейкобсон А.
, Бух Г.
, Рамбо Дж.
- «Унифицированный процесс разработки программного обеспечения» (2004 г.
) 2. Дэвид А.
Марк и Клемент Макгоуэн – «Методология структурного анализа и проектирования SADT» 3. Коберн - «Современные методы описания функциональных требований» (2002).
4. Леффингвелл Дин, Видрих Дон - «Принципы работы с требованиями к программному обеспечению» (2002 г.
) 5. Карл И.
Вигерс – «Разработка требований к программному обеспечению» (2002 г.
) 6. Лизабет Халл, Кен Джексон, Джереми Дик – «Разработка требований и управление.
Практическое руководство пользователя» (2005).
7. Скотт Эмблер – «Гибкие технологии: экстремальное программирование и унифицированный процесс разработки» (2005 г.
) 8. Гринфилд Джек, Кейн Шорт — «Фабрики разработки программного обеспечения» (2007) 9. Алистер Коуберн – «У каждого проекта своя методология» 10. Вольфсон Борис - «Методологии гибкой разработки» 11. Лешек А.
- «Анализ требований и проектирование систем» 12. Фримэнрик, Фримэнелизабет - «Шаблоны проектирования» (2011) 13. Ванс Рик – «Доменно-ориентированный дизайн» (2011) 14. ГОСТ 34.602-89 «Информационные технологии.
Набор стандартов для автоматизированных систем.
Техническое задание на создание автоматизированной системы» Теги: #формирование требований #проектирование #требования #Управление проектами #управление проектами #программирование #Анализ и проектирование систем #проектирование и рефакторинг #Визуализация данных #Промышленное программирование
-
Почему Ты Не Уходишь Из World Of Warcraft?
19 Oct, 24 -
Лесная Промышленность
19 Oct, 24 -
Немного О 35-Мм Пленке И Цифровом Звуке
19 Oct, 24 -
Был Введен Scrum, А Agile Забыли
19 Oct, 24
