ноябрь    2024

Пн	Вт	Ср	Чт	Пт	Сб	Вс
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30

показать все 

14.11.2024

Обновление BI.ZONE Secure DNS: гибкая настройка фильтрации и максимальная скорость

Читать далее 

14.11.2024

RED Security: в октябре количество DDoS-атак на ТЭК выросло в 3 раза

Читать далее 

14.11.2024

Falcongaze представила новую версию DLP-системы — SecureTower 7 Helium

Читать далее 

14.11.2024

ИСП РАН покажет результаты 30-ти лет работы на Открытой конференции в Москве

Читать далее 

08.11.2024

Юбилейная конференция ЭОС: ЭОС: 30 лет лидерства на рынке автоматизации документооборота и обсуждение актуальных трендов

Читать далее 

показать все 

21.11.2024

ИИ: маршрут не построен, но уже проектируется

Читать далее 

18.11.2024

Глеб Шкрябин: «Надежные и масштабируемые системы — основа стабильной работы бизнеса в условиях больших нагрузок»

Читать далее 

14.10.2024

Елена Ситдикова: «На разработчиках программного обеспечения для транспорта лежит большая ответственность перед пассажирами»

Читать далее 

11.10.2024

Технологический ИИ-арсенал

Читать далее 

28.09.2024

Чем страшен ИИ, и с чем его едят

Читать далее 

13.06.2024

Взгляд в перспективу: что будет двигать отрасль информационной безопасности

Читать далее 

18.04.2024

5 способов повысить безопасность электронной подписи

Читать далее 

18.04.2024

Как искусственный интеллект изменит экономику

Читать далее 

18.04.2024

Неочевидный САПР: выход ПО за рамки конструкторской деятельности

Читать далее 

18.04.2024

Скоро некому будет делать сайты и заниматься версткой

Читать далее 

показать все 

Главная / Архив номеров / 2016 / Выпуск №08 (61) / Десять золотых правил разработки требований

Рубрика: ИТ-проекты

Александр Михайлов, к.т.н., заместитель начальника управления по развитию и контролю проектной деятельности ООО ИК «СИБИНТЕК»

Десять золотых правил
разработки требований

Как показано в известном исследовании Тома Кендрика (Tom Kendrick), треть всех рисков проектов связана с управлением объемом. Из анализа представленной базы данных проектных рисков (The Project Experience Risk Information Library, PERIL) следует, что наибольшая часть рисков связана с изменением объема в ходе реализации проекта, а также с невозможностью реализовать тот или иной объем проекта

Разработка требований

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

В упомянутом исследовании выделяются две основные причины реализации негативных рисков, связанных с объемом проекта, – неполнота объема (Scope Gap) и расползание объема (Scope Creep).

В первом случае можно сказать, что речь идет о незавершенном, неполном определении требований к продукту проекта. В большинстве случаев причина кроется в низком качестве результатов сбора, анализа и разработки требований.

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

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

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

Расползание объема нужно, конечно, отличать от действительно необходимых изменений, обусловленных объективными изменениями в окружении проекта, например изменениями бизнес-планов, конъюнктуры рынка или нормативных ограничений.

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

Разработка действительно качественных требований предполагает достаточно глубокое погружение в бизнес заказчика, в понимание бизнес-процессов и особенностей организации работы.

От тех, кто раньше этим профессионально не занимался, часто приходится слышать вопрос: с чего лучше начать разработку требований? Можно рекомендовать – с самого непонятного! Организуйте встречу и начните с обсуждения целей и ожиданий заказчика. Постепенно погрузитесь в бизнес-процессы, в организацию работы, поймите, как все устроено.

Инструменты сбора требований хорошо известны – это в первую очередь встречи, интервью и анкетирование клиентов, пользователей и других заинтересованных сторон, наблюдение за реальной работой людей, анализ документов, мозговые штурмы. Если есть возможность, то более полного и глубокого понимания требований можно добиться сиспользованием эскизного (концептуального) проектирования и создания прототипов будущего продукта.

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

Ключевые требования нужно соизмерять с ресурсами проекта, в первую очередь с техническими и финансовыми, с ожидаемыми сроками создания продукта.

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

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

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

Правильный подход для выравнивания бизнес-требований и возможностей реализации заключается в привлечении к разработке требований опытных инженеров и архитекторов.

При этом основная ценность привлекаемой технической экспертизы должна быть сосредоточена именно на генерации новых идей, предложений и технических решений дляреализации выявленных бизнес-требований. Желательно привлекать экспертов и потенциальных исполнителей как можно раньше, уже на самых ранних этапах разработки требований.

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

В результате бизнес-анализа нужно определить реальные потребности заказчика, перейти от формулировок «хотелось бы» к формулировкам «нужно». Выявленные потребности необходимо проверять на реализуемость, соотносить с техническими возможностями.

Основываясь на опыте разработки функционально-технических требований, можно определить следующие десять золотых правил разработки требований:

1. Начинайте с самого непонятного.
2. Поймите бизнес-цели, определите задачи проекта.
3. Погрузитесь в бизнес-процессы, в организацию работы, поймите, как все устроено.
4. Прорабатывайте требования, чтобы они были реализуемы.
5. Как можно раньше привлекайте техническую экспертизу.
6. Разделяйте сложное на части.
7. Осторожно – перфекционизм! Идеал недостижим – умейте вовремя остановиться.
8. Прорабатывайте весь спектр требований, не увлекайтесь одним в ущерб остальному.
9. Продумайте содержание документа требований, какие разделы действительно нужны.
10. При спецификации требований пишите понятно, по существу, не гонитесь за объемом.

Системы сертификации

Приведем краткий обзор получивших признание систем сертификации в области бизнес-анализа и разработки требований.

Многоуровневая сертификация аналитиков и разработчиков требований развивается под эгидой Международного совета по инженерии требований (International Requirements Engineering Board, IREB) (www.ireb.org).

В числе прочего сертификацию IREB можно пройти в тестовых центрах, работающих с системой тестирования Pearson VUE. Ближайшие к вашему городу центры можно найти поссылке www.pearsonvue.com/isqi/locate.

Также многоуровневую схему сертификации предлагают Международная ассоциация в области качества программного обеспечения (Global Association for Software Quality, GASQ) (http://en.gasq.org) и Коллегия по квалификации разработчиков требований (Requirements Engineering Qualifications Board, REQB). Записаться на экзамены REQB можно на сайтеwww.rstqb.org.

Международный институт бизнес-анализа (International Institute of Business Analysis, IIBA) (https://russia.iiba.org) поддерживает сертификаты CBAP (Certified Business Analysis Professional) и CCBA (Certification of Competency in Business Analysis). IIBA также получил широкую известность благодаря разработке Свода знаний в области бизнес-анализа (Business Analysis Body of Knowledge, BABoK), представляющего собой попытку систематизации соответствующих практик.

Институт управления проектами (Project Management Institute, PMI) продвигает сертификацию в области бизнес-анализа PMI-PBA (PMI Professional in Business Analysis) (http://www.pmi.ru/certificates/PMI-PBA). Институт издает руководство для практикующих бизнес-аналитиков Business Analysis for Practitioners и руководство для подготовки кпрохождению сертификации PMI PBA Handbook.

Получили распространение программы сертификации Международного института качества (Quality Assurance Institute Global Institute, QAI) (www.qaiglobalinstitute.com). В части бизнес-анализа QAI предлагает два типа сертификации: CABA (Certified Associate Business Analyst) и CSBA (Certified Software Business Analyst).

Системная инженерия

Определение требований является важной составляющей направления системной инженерии (Systems Engineering), в нашей стране также известного под названием системотехника.В современном мире системная инженерия представляет собой сложившийся междисциплинарный подход, направленный на создание успешных систем. В системной инженериипод успешными понимаются такие системы, которые отвечают потребностям заказчика, пользователей и других заинтересованных лиц.

Одним из глобальных лидеров направления является Международный совет по системной инженерии (International Council on Systems Engineering, INCOSE) (www.incose.org), разработавший многоуровневую программу сертификации:

• ASEP (Associate Systems Engineering Professional)
• ESEP (Expert Systems Engineering Professional)
• CSEP (Certified Systems Engineering Professional)

Недавно вышел один из ключевых международных стандартов в данной области – ISO/IEC 15288 – 2015 Systems and Software Engineering – System Life Cycle Processes (Системная ипрограммная инженерия. Процессы жизненного цикла систем).

В нашей стране ранее уже были введены связанные стандарты ГОСТ Р ИСО/МЭК 15288 – 2005 «Информационная технология. Системная инженерия. Процессы жизненного цикла систем» и ГОСТ Р ИСО/МЭК 12207 – 2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств».

Под эгидой INCOSE издается Руководство по системной инженерии (Systems Engineering Handbook). Международной группой экспертов реализован проект по созданию и развитию Руководства к своду знаний в области системной инженерии (Guide to the Systems Engineering Body of Knowledge, SEBoK), доступного на сайте www.sebokwiki.org.

Системный анализ и бизнес-информатика

В 2014 году утвержден национальный профессиональный стандарт «Системный аналитик», определяющий среди основных целей профессии разработку и сопровождение требований на протяжении всего жизненного цикла системы [6].

Последнее десятилетие активно развивается учебное направление «Бизнес-информатика». В 2015 году был утвержден соответствующий федеральный государственный образовательный стандарт [7]. Выпускники по данной специальности готовятся к аналитической, проектной и консалтинговой работе. В соответствии с духом стандарта бизнес-информатик должен обладать аналитическими способностями, способностью к абстрактному мышлению, владеть приемами системного мышления, способностью принимать решения в нестандартных ситуациях, умением выстраивать эффективные коммуникации. Основные сферы деятельности бизнес-информатика – это разработка и оптимизация бизнес-процессов, управление проектами, проектирование и внедрение корпоративных информационных систем и другие. Обучение по направлению бизнес-информатики уже включили в свою программу ведущие вузы страны, в том числе РАНХиГС при Президенте РФ (www.ranepa.ru), НИУ «ВШК» (https://bi.hse.ru), НИЯУ «МИФИ» (www.mephi.ru), РНУ (www.rosnou.ru) и другие.

Рекомендации для саморазвития

Для самостоятельного развития можно рекомендовать следующие книги:

• Артур Холл. Опыт методологии для системотехники
• Гради Буч. Объектно-ориентированный анализ и проектирование
• Карл Вигерс. Разработка требований к программному обеспечению

Выход каждой из этих книг стал значимым событием в развитии бизнес-анализа и разработки требований. Можно сказать, что труды А. Холла [5], Г. Буча [2] и К. Вигерса [3] взначительной степени сформировали парадигму, то есть общепринятые сегодня подходы к сбору, анализу и разработке требований. Осмысление содержания указанных книг способно создать у читателя надежный фундамент системного мышления, что является краеугольным камнем для успешной работы в области бизнес-анализа, проектирования систем, проектного управления и других смежных видов деятельности.

В отношении книги А. Холла (1975) разрешите отметить, что ее перевод с английского языка и издание были выполнены под редакцией выдающегося отечественного кибернетика Геллия Николаевича Поварова (1928-2004), автора философской системной теории научно-технического прогресса.

Модель прогресса рассматривается в ней как ряд стадий возрастающей системной сложности, а состояние науки и техники каждой эпохи измеряется средним уровнем сложности систем, создаваемых человеком [4].

Г.Н. Поварову также принадлежит авторство русских терминов «системотехника» и «системология» (общая наука о системах) [1]. Кроме того, перевод книги А. Холла обогатил русский язык термином «проект» в современном его понимании. Авторы перевода указывают в предисловии к изданию: «Весьма своеобразен термин «project», обозначающий итему разработки и саму разработку; мы переводим его как «проект», расширяя обычное русское значение этого слова…» [5].

За последние годы проектное управление прошло в нашей стране грандиозный путь, превратилось в самостоятельную профессиональную отрасль. Изданы национальные государственные стандарты в области проектного, программного и портфельного управления. Сформировался рынок профессиональных услуг проектного управления. В 2015 году отметила десятилетний юбилей ежегодная международная конференция «Управление проектами» (www.pm-conf.ru). В 2016-м ожидается выход профессионального стандарта «Руководитель проектов».

1. Алексеев П.В. Философы России XIX-XX столетий. Биографии, идеи, труды. – 4-е изд., перераб. и доп. – М.: Академический проект, 2002. – С. 763.
2. Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на C++. – 2-е изд./пер. с англ. – М.: Бином, СПб.: Невский диалект, 1998.
3. Вигерс К. Разработка требований к программному обеспечению/пер. с англ. – М.: Русская редакция, 2004.
4. Поваров Г.Н. To Daidálu pteró (К познанию научно-технического прогресса) / Ежегодник «Системные исследования, 1971». – М.: Наука, 1972.
5. Холл А.Д. Опыт методологии для системотехники /пер. с англ., под ред. Г.Н. Поварова. – М.: Советское радио, 1975.
6. Приказ Министерства труда и социальной защиты РФ от 28 октября 2014 г. №809н «Об утверждении профессионального стандарта «Системный аналитик» [Электронный ресурс] URL – http://base.garant.ru/70810684 (Дата обращения: 20.08.2016).
7. Приказ Министерства образования и науки РФ от 08.04.2015 №370 «Об утверждении федерального государственного образовательного стандарта высшего образования понаправлению подготовки 38.04.05 бизнес-информатика (уровень магистратуры)» [Электронный ресурс] URL – http://минобрнауки.рф/документы/5569 (Дата обращения: 20.08.2016).
8. Kendrick T. Identifying and managing project risk: essential tools for failure-proofing your project / 2nd ed. – AMACOM, New York, 2009.
9. Failure-Proof Projects [Электронный ресурс] URL – http://www.failureproofprojects.com (Дата обращения: 20.08.2016).

В начало⇑

Комментарии отсутствуют

Комментарии могут отставлять только зарегистрированные пользователи