Введение
Некоторое время назад обратил свое внимание на артефакт Концепция продукта (product vision) методологии разработки программного обеcпечения RUP (Rational Unified Process) и обнаружил, что отправной точкой разработки программного продукта является выявление проблемы, на решение которой нацелен продукт.
Аналогичный подход существует и в отечественной практике – так в ГОСТ 34.601-90 говорится, что на стадии Формирование требований к АС (автоматизированной системе) производится «выявление проблем, решение которых возможно средствами автоматизации».
В настоящей статье хочу поделиться с читателями своими выводами касательно природы проблемы, ее важности и отношении к разработке программного продукта.
Общая характеристика процесса принятия решений
Как и любой другой продукт, создаваемый в результате деятельности человека, программное обеспечение является средством (инструментом), предназначенным для решения некоторого набора задач. Откуда возникает необходимость что-то решать? Обратимся к теории…
Изучением закономерностей выбора людьми наиболее оптимального решения разного рода задач занимается такая наука как теория принятия решений.
С чего начинается родина решение?
Первопричиной любой деятельности теория принятия решений называет проблему — расхождение в представлениях какого-либо лица между тем, что оно имеет в настоящий момент (действительное состояние), и тем, что оно желало бы иметь или достигнуть в будущем (желательное состояние).
Так как теория принятия решений делает акцент на управленческую деятельность в рамках организации, то не будем отступать от этой парадигмы, но имеем в виду, что указанный подход применим к любой другой деятельности.
Лицо, которое не только осознает проблему или желает что-то изменить, а еще и готово принять решение о способе ее решения и произвести конкретные действия, направленные на изменение действительного состояния в сторону желательного – называют заинтересованным лицом или лицом, принимающим решение (ЛПР).
Цель
После осознания проблемы рождается понимание цели — воплощение желаемого результата, достижение которого, по мнению ЛПР, приведет к разрешению предпосылок проблемы, т.е. приведет в соответствие желательное и действительное состояния.
Задача
Подвергшись более детальному анализу цель разделяется на подцели. Подцели согласуются со стадиями процесса достижения основной цели – они соотносят со временем, местом, исполнителям и объектами приложения усилий. Таким образом, цель трансформирует в совокупность задач. От того, будет ли решена вся совокупность задач, а также будут ли по всем решенным задачам достигнуты требуемые результаты, зависит степень достижения поставленной цели, а, следовательно, и степень решения изначальной проблемы в целом.
Операция и решение
Когда перечень задач определился, ЛПР приступает к формированию целенаправленной деятельности организации по достижению цели. Целенаправленная деятельность комплекса мероприятий, осуществляемых ЛПР в интересах достижения намеченной цели носит название — операция.
Замысел операции постепенно дорабатывается ЛПР до решения на ее проведение, в ходе формализации которого оно трансформируется в систему частных целей и задач руководителей подразделений, программы развития, планы, задачи и критерии их выполнения. После этого начинается процесс практической реализации принятого и доведенного до исполнителей решения.
Рисунок 1. Типовой процесс управления организацией
Оценка эффективности управленческого решения
До самого конца операции ЛПР и все участвовавшие в разрешении проблемы лица остаются в неведении относительно успеха или неуспеха операции. Только когда деятельность участников завершится, ЛПР станет ясно, та ли предпосылка (первопричина) проблемы была выбрана для решения, правильно ли была сформулирована цель операции, верно ли эта цель была разделена на задачи, в то ли время и тем ли исполнителям было поручено эти задачи решить и т. д.
Когда решение исполнено, а операция по устранению проблемы завершена, ЛПР оценивает достигнутый результат. При оценке полезности и эффективности полученного решения во внимание принимается не только сам факт окончания операции, но и степень устранения изначальной проблемы.
В результате оценки можно прийти к следующим выводам:
- проблема устранена полностью и ее разрешение не вызвало каких-то видимых отрицательных последствий;
- проблема устранена частично, но также не наблюдается отрицательных последствий;
- проблема устранена частично и при ее разрешении возникли некоторые новые затруднения;
- проблема не устранена, а реализация решения по ее устранению породила возникновение новых, значительных проблем.
Природа требований к программному продукту
Какая задача – такое и решение
Известно, что для проблемы может существовать множество альтернатив решения. Например, самым простым способом оптимизации производства является изменение бизнес-процесса в организации. Однако, этого иногда не достаточно и требуется инструмент, который позволил бы решать новые задачи максимально эффективно.
Если в процессе размышлений о способе решения проблемы ЛПР придет к выводу, что достижению поставленной цели будет способствовать автоматизация деятельности организации, то одной из разрабатываемых им операций станет внедрение соответствующей информационной (автоматизированной) системы.
Представим себе, что руководитель некоторого предприятия решил оптимизировать работу с документами. Если его целью является только сокращение сроков согласования документов, то для этого вполне достаточно перейти на использование документов в электронном виде — установить всем ворд и научить пользоваться электронной почтой. Если же руководитель ставит целью упорядочить и контролировать процессы согласования и исполнения документов, то для этого потребуется инструмент, позволяющий осуществлять поддержку подобной деятельности — информационная система.
Этот банальный пример показывает, что для решения разных задач должны использоваться разного рода решения. Казалась бы, очевидно! Не будем спешить с выводами…
Что такое требование?
В соответствии с определением, под термином автоматизированная система подразумевается совокупность персонала организации и комплекс средств автоматизации, реализующего информационную технологию выполнения действий, направленную на достижение определенной цели (см. ГОСТ 34.003-90). То есть используемое программное обеспечение должно обладать набором свойств, позволяющим персоналу выполнять действия или решать задачи, направленные на достижение поставленной цели. Указанные свойства программного продукта называются требованиями.
Требование — свойство программного обеспечения, необходимое пользователю для решения задачи при достижении поставленной цели.
Уровни требований
Если рассмотреть процесс создания автоматизированной информационной системы с точки зрения теории управления, то можно проследить аналогию с описанным выше порядком принятия управленческого решения.
Рисунок 2. Процесс создания автоматизированной системы
Потребность
Аналогично процессу выработки управленческого решения, анализируя проблему ЛПР формулирует цель автоматизации деятельности организации. Чтобы достигнуть цели, разрабатываемая система должна решать некоторый набор технических или бизнес-задач. В контексте разработки программного обеспечения эти задачи именуются потребностями (needs).
Функция
В рамках выполнения действий по решению задач, направленных на достижение заявленной цели, персонал организации (пользователи и иные заинтересованные лица) вправе ожидать от используемого программного продукта определенного поведения. Поведение, сформулированное на языке пользователя и описывающие поведение программного продукта в рамках удовлетворения одной или нескольких потребностей, называется функцией системы (feature).
Программное требование
После определения набора функций их детализируют в конкретные и законченные описания поведения программы, которую требуется разработать. Такие описаниями составляют программные требования или требования к программному обеспечению (software requiremens).
Оценка эффективности программного решения
Построив систему, удовлетворяющую выявленным программным требованиям, можно утверждать, что система предоставляет требуемый набор функций. В свою очередь, поскольку функции предназначены для удовлетворения одной или нескольких потребностей персонала, эти потребности будут непосредственно удовлетворяться полученным решением в целом, а использование решения позволит достигнуть поставленной цели. И если цель была выбрана верно, то можно предположить, что ее достижение позволит разрешить имеющуюся проблему.
Часто заказчик при анализе результатов разработки и внедрения автоматизированной системы приходит к выводу, что решение оказалось неэффективным или породило новые проблемы, а порой еще более усугубило имевшееся положение вещей.
Почему так получается?
Кто виноват и что делать?
Очень часто в процессе сбора и анализа происходит искажение требований или же источник этих требований (проблема заинтересованного лица) не выявляется вовсе.
Рисунок 3. Искажение требований
На рисунке 3 показан пример процесса, в ходе которого возникают искажения. Когда ЛПР осознал проблему и сформулировал цель деятельности по ее устранению он доводит перечень задач (T0) до исполнителей — персонала организации. Допустим, что именно эти исполнители будут использовать разработанный позднее программный продукт, т.е. они будут являться его пользователями. Каждый из них по-своему понимает поставленную ему задачу и при формулировании требований к программному продукту исходит из своих предположений (T1).
Аналитик, на основании данных интервью потенциальных пользователей, сформулировал собственное представление о решаемых задачах (T2), которое донес до менеджера проекта и совместно с ним выработал решение, воплощенное в задачах для разработчика (T3).
В лучшем случае, в результате описанного процесса получится продукт, удовлетворяющий требованиям персонала, в худшем – только требованиям аналитика или менеджера проекта. Такой результат является следствием отсутствия понимания у группы проекта реальных потребностей будущих пользователей и заинтересованных лиц, на чью работу повлияет разработанное программное решение.
В особо тяжелых случаях получившийся продукт не имеет ничего общего с ожиданиями заказчика и отражает собственные представления разработчика о том, как должны работать пользователи.
Если же на начальном этапе проекта выявить проблему и все выявляемые требования пользователей, равно как и предлагаемые решения, соотносить именно с ней (см. рисунок 4), можно ожидать, что получившийся продукт будет максимально соответствовать как потребностям пользователей, так и ожиданиям заинтересованных лиц.
Рисунок 4. Соотнесение требований с проблемой
Более того, понимание решаемой проблемы позволит качественно управлять масштабом проекта – например, в первую очередь реализовать ту функциональность, которая решает 80% проблемы.
Как этого добиться?
Определение проблемы
Раз уж в ходе предыдущего изложения мы пришли к выводу, что прежде чем разрабатывать программный продукт нужно определиться с проблемой, которую он должен решать, то пора бы уже выяснить, как эту проблему зафиксировать.
Многие источники предлагают использовать нижеприведенную форму для формулировки определения проблемы (problem statement), которую требуется решить. Приведенная форма учитывает и цели, которые ожидается достигнуть будущим решением.
| Элемент | Описание |
|---|---|
| Проблема | [описание проблемы] |
| воздействует на | [перечень сторон, на которых оказывает влияние данная проблема] |
| результатом чего является | [описание воздействия данной проблемы на заинтересованных лиц иили бизнес-деятельность] |
| Выигрыш от | [описание предлагаемого решения] |
| Может состоять в следующем: | [перечень основных преимуществ, представляемых решением] |
| Элемент | Описание |
|---|---|
| Проблема | Отсутствие доступа к интегрированным данных о состоянии здоровья населения |
| воздействует на |
|
| результатом чего является |
|
| Выигрыш от | создания единого хранилища медицинских данных о состоянии здоровья населения и интерфейса к нему |
| Может состоять в следующем: |
|
Формулирование и достижение соглашения об одинаковом понимании всеми участниками проекта решаемой проблемы – один из первых и важных шагов любого программного проекта. Стоит отметить, что определение решаемой проблемы может производиться как для всего проекта в целом, так и при добавлении новой функциональности в уже существующий программный продукт.
Заключение
Если кому-то показались очевидными (или даже, банальными) положения, изложенные в настоящей статье, приведу данные статистики, которые показывают, что проблема неуспешности программных проектов до сих пор остается актуальной и требования – основная тому причина.
В настоящее время только 39% всех программных проектов можно считать успешными в полном смысле этого слова. Полностью проваливаются 18% проектов, а в ходе реализации оставшихся 43% возникают проблемы, связанные с превышением бюджета или реализацией не той функциональности.
В исследовании компании Standish Group International, результаты которого отражены в документе The CHAOS Chronicles 2013, ключевыми факторами успешности программного проекта названы:
- вовлечение в проект заинтересованных лиц (Executive management support) — 20%;
- привлечение конечного пользователя (User involvement) — 15%;
- управление масштабом проекта (Optimazation) — 15%.
Только после них следуют такие факторы как квалификация разработчиков, опыт управления проектами, применение гибких методологи и т.д.
***
Все вышесказанное подтверждает аксиому, что программные продукты создаются для пользователей. Ориентация на проблемы заинтересованных лиц и потребности реального (конечного) пользователя является залогом успешности проекта по разработке программного обеспечения. Уже на начальном этапе проекта пользователь должен быть привлечен к работе, как результат этого — определение проблемы (problem statement) и концепция продукта (product vision) должны показывать, что команда проекта ясно осознает решаемую проблему, понимает потребности пользователей и готова их удовлетворить.
Автор: algusen
