Лекция 5. Основные рабочие процессы: Реинжиниринг бизнес-процессов

Согласно стратегии декомпозиции, основанной на производственных функциях, выделяются три больших класса функций предприятия: функции организации, функции управления и производительных функции, или бизнес – функции. Так, функции организации включают в себя четыре вида функций: проектирование полезного результата, проектирование элементов систем, проектирование технологических процессов системы, планирование деятельности. К функциям управления относят функции учета, контроля и анализа, прогноза и принятия решений. Каждой из этих функций дается точное реальное наполнение и показывается, как они модифицируются в зависимости от временного горизонта (стратегического, тактического, оперативного). Так, например, для стратегического уровня, функция полезного результата представляет собой деятельность руководства по формулированию миссии предприятия и построения дерева целей. При проектировании элементов системы решаются задачи по организации (реорганизации) структуры предприятия, разработки стратегии, определения стиля управления, формулирования требований к навыкам и умениям персонала и т.д. Следует подчеркнуть, что функция планирования отнесена к организационным, так как она является внешней по отношению к процессу управления, и задает конкретные целевые установки для управления. Функции управления на стратегическом уровне связаны с исполнением выработанной стратегии: контролем ее исполнения, анализом причин отклонения от выбранного пути, анализом изменений, как во внешнем окружении, так и внутренней обстановки, принятием решений по корректировке стратегии.

Данная методика помогает проводить анализ моделей.

На этапе обследования предприятия с помощью Bpwin строятся диаграммы AS-IS, то есть описывается реальное состояние дел на предприятии. На этапе анализа строится уже «идеальная» функциональная модель с применением описанной методики (модель TO-BE). Построенные модели сравниваются между собой, и принимается решение по изменению функций предприятия и автоматизации некоторых из них. Как правило, автоматизации подлежат функции учета, контроля и анализа (функции управления), а также функции планирования, и отчасти функции проектирования технологических процессов (функции организации). Опыт разработки информационных систем позволяет утверждать, что уже на первых этапах проектирования, можно говорить об эффекте от проделанной работы, так эти этапы позволяют упорядочить выполняемые функции и избежать их дублирования.

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

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

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

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

Реинжиниринг бизнес-процесса (BPR— Business process reengineering) появился в зарубежной практике в начале 1990-х годов и рассматривался как дальнейшее развитие инжиниринга и, в частности, системно-технического подхода к развитию проектирования бизнес-процессов.

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

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

Реинжиниринг бизнес-процессов проектируется и реализуется на информационно-технологической базе интегрированных корпоративных ИС, которые обеспечивают информационную поддержку управлению деловыми процессами на всех уровнях. Создаются телекоммуникационно взаимосвязанные АРМ специалистов, которые реализуют концепцию автоматизации управления сквозными бизнес-процессами. Важным условием эффективного функционирования СППР является создание такой структуры корпоративной ИС, которая будет относительно легко адаптироваться к изменениям потребностей пользователей — менеджеров, руководителей подразделений организации.

Основателями теории реинжиниринга являются Майкл Хаммер и Джеймс Чампи, которые выпустили книгу «Реинжиниринг корпорации: манифест для революции в бизнесе». Авторы определили реинжиниринг как фундаментальное переосмысление и радикальное перепроектирование бизнес-процессов для достижения существенных улучшений в таких ключевых для современного бизнеса показателях результативности, как затраты, качество, уровень обслуживания и оперативность». Предпосылками к тому стали увеличение масштабов деятельности предприятий, укрупнение предприятий, глобализация экономики, а также бурный прогресс в области информационных технологий. За это время было разработано множество концепций и теоретических моделей управления предприятием. На их основе разрабатываются и внедряются в деятельность предприятия различные информационные системы.

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

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

Базовыми понятиями BPR являются бизнес-система, бизнес-процесс, деловая процедура:

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

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

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

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

Реинжиниринг бизнес-процессов базируется на нескольких основных принципах:

• несколько рабочих процедур объединяются в одну, т.е. происходит горизонтальное сжатие процесса (по имеющимся оценкам, горизонтальное сжатие ускоряет выполнение процесса примерно в 10 раз);

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

• шаги процесса выполняются в естественном порядке;

• процессы имеют различные варианты исполнения (тот или иной вариант выбирается в зависимости от конкретной ситуации, состояния и т.д.);

• работа выполняется в том месте (подразделении, отделе), где это целесообразно (устраняется излишняя интеграция, что приводит к повышению эффективности процесса в целом);

• уменьшается количество проверок и управляющих воздействий;

• минимизируется количество согласований путем сокращения внешних точек контакта;

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

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

Свойства реинжиниринга:

1) отказ от устаревших правил и подходов и начало делового процесса с нуля, что позволяет преодолеть негативное воздействие сложившихся хозяйственных догм;

2) пренебрежение действующими системами, структурами и процедурами компании и радикальное изменение способов хозяйственной деятельности — если невозможно модифицировать свою деловую среду, то можно переделать свой бизнес;

3) приведение к значительным изменениям показателей деятельности (на порядок отличающихся от предыдущих).

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

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

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

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

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

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

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

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

Пути перепроектирования

1. Несколько работ объединяются в одну (уплотнение по горизонтали)

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

1. этапы процесса выполняются в естественном порядке – отказ от линейности, создание параллельных процессов

1. Должны быть варианты процессов для различных заказчиков, ситуаций и входных данных

1. Работа выполняется там, где ее целесообразно делать (закупка расходных материалов их потребителями)

1. снижение доли работ по проверке и контролю (групповой или отложенный контроль)

1. минимизация согласований

1. ответственный менеджер является единственной точкой контакта

1. сочетание централизованных и децентрализованных операций (преимущества автоматизации)

Ошибки при BPR

От 50 до 70% BPR не достигают результата. Происходит это не от рисков, а от незнания. Сравнение рулетки и шахмат: рулетка – игра с высоким риском, так как исход в ней зависит от случая. В шахматах все зависит от умения, знаний и способностей.

Типичные ошибки:

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

1. внимание не фокусируется на бизнес –процессах

1. не принимаются во внимание ценности и убеждения людей

1. жесткие ограничения при постановке задачи– если руководство еще до начала жестко ограничивает круг решаемых задач или масштабы проведения BPR

1. попытки начать BPRснизу. Инициировать BPR может только руководитель высшего ранга – в силу полномочий, видения

1. недостаток ресурсов на проведение BPR (и главные из них– время и внимание лучших сотрудников, включая личное участие руководства верхнего звена.) Недостаток ресурсов демонстрирует подчиненным отношение руководства к этому процессу.

1. попытка провести BPR, чтобы никого не обидеть

Реинжиниринг АС – процесс перепроектирования системы, начиная со стадий реализации, логической модели, стадии технического проекта. То есть процесс происходит в обратном направлении по отношению к процессам прямого проектирования.

Указанные виды реинжиниринга тесно связаны друг с другом, зависят один от другого.

Лекция 6. Основные рабочие процессы: Разработка требований

Программные требования – Software Requirements – свойства программного обеспечения, которые должны быть надлежащим образом представлены в нём для решения конкретных практических задач. Данная область знаний касается вопросов извлечения (сбора), анализа, специфицирования и утверждения требований.

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

На практике часто применяется подход, используемый в различных методологиях разработки ПО и базирующийся на определении групп требований к продукту. Такой подход обычно включает группы (типы, категории) требований, например: системные, программные, функциональные, нефункциональные (в частности, атрибуты качества) и т.п.

Функциональные и нефункциональные требования (Functional and Non-functional Requirements) – функциональные требования задают “что” система должна делать; нефункциональные – с соблюдением “каких условий” (например, скорость отклика при выполнении заданной операции); часто функциональные требования представляют в виде сценариев (вариантов использования) Use Сase.

Потребности (needs) – отражают проблемы бизнеса, персоналии или процесса, которые должны быть соотнесены с использованием или приобретением системы.

Группа функциональных требований

Бизнес-требования (Business Requirements) – определяют высокоуровневые цели организации или клиента (потребителя) – заказчика разрабатываемого программного обеспечения.

Пользовательские требования (User Requirements) – описывают цели/задачи пользователей системы, которые должны достигаться/выполняться пользователями при помощи создаваемой программной системы. Эти требования часто представляют в виде вариантов использования (Use Cases).

Функциональные требования (Functional Requirements) – определяют функциональность (поведение) программной системы, которая должна быть создана разработчиками для предоставления возможности выполнения пользователями своих обязанностей в рамках бизнес-требований и в контексте пользовательских требований.

Группа нефункциональных требований (Non-Functional Requirements)

Бизнес-правила (Business Rules) – включают или связаны с корпоративными регламентами, политиками, стандартами, законодательными актами, внутрикорпоративными инициативами (например, стремление достичь зрелости процессов по CMMI 4-го уровня), учетными практиками, алгоритмами вычислений и т.д. На самом деле, достаточно часто можно видеть недостаточное внимание такого рода требованиям со стороны сотрудников ИТ-департаментов и, в частности, технических специалистов, вовлеченных в проект. Business Rules Group дает понимание бизнес-правила, как “положения, которые определяют или ограничивают некоторые аспекты бизнеса. Они подразумевают организацию структуры бизнеса, контролируют или влияют на поведение бизнеса”. Бизнес-правила часто определяют распределение ответственности в системе, отвечая на вопрос “кто будет осуществлять конкретный вариант, сценарий использования” или диктуют появление некоторых функциональных требований. В контексте дисциплины управления проектами (уже вне проекта разработки программного обеспечения, но выполнения бизнес-проектов и бизнес-процессов) такие правила обладают высокой значимостью и, именно они, часто определяют ограничения бизнес-проектов, для автоматизации которых создается соответствующее программное обеспечение.

Внешние интерфейсы (External Interfaces) – часто подменяются “пользовательским интерфейсом”. На самом деле вопросы организации пользовательского интерфейса безусловно важны в данной категории требований, однако, конкретизация аспектов взаимодействия с другими системами, операционной средой (например, запись в журнал событий операционной системы), возможностями мониторинга при эксплуатации – все это не столько функциональные требования (к которым ошибочно приписывают иногда такие характеристики), сколько вопросы интерфейсов, так как функциональные требования связаны непосредственно с функциональностью системы, направленной на решение бизнес-потребностей.

Атрибуты качества (Quality Attributes) – описывают дополнительные характеристики продукта в различных “измерениях”, важных для пользователей и/или разработчиков. Атрибуты касаются вопросов портируемости, интероперабельности (прозрачности взаимодействия с другими системами), целостности, устойчивости и т.п.

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

Системные требования (System Requirements) – иногда классифицируются как составная часть группы функциональных требований. Описывают высокоуровневые требования к программному обеспечению, содержащему несколько или много взаимосвязанных подсистем и приложений. При этом, система может быть как целиком программной, так и состоять из программной и аппаратной частей. В общем случае, частью системы может быть персонал, выполняющий определенные функции системы, например, авторизация выполнения определенных операций с использованием программно-аппаратных подсистем.

Рассматривая бизнес-правила, как артефакты, относящиеся к области программных требований, можно отметить, почему БП относят к нефункциональным требованиям: Например, при написании определенного шага в сценарии use case, используется ссылка на бизнес правило: «… система производит расчет стоимости в соответствии с бизнес-правилом BP41 …». В свою очередь данное бизнес-правило может определять алгоритм расчета стоимости. Т.е. налицо «с соблюдением каких условий система делает расчет».

Системные требования и программные требования (System Requirements and Software Requirements) – данное разделение базируется на определении “системы”, данном INCOSE (International Council on Systems Engineering) “комбинация взаимодействующих элементов <созданная> для достижения определенных целей; может включать аппаратные средства, программное обеспечение, встроенное ПО, другие средства, людей, информацию, техники (подходы), службы и другие поддерживающие элементы”; таким образом, подразумевается, что система является более ёмким понятием, чем программное обеспечения и включает окружение, в котором функционирует ПО, как таковое; отсюда, естественным образом, вытекают требования к системе в целом и программному обеспечению (или программной системе), в частности. Часто в литературе по управлению требованиями встречается описание системных требований как “пользовательских требований” (user requirements), SWEBOK ограничивает применение понятия “пользовательское требование” требованиями к системе конечных пользователей/заказчиков. Системные требования по SWEBOK, в свою очередь, окружают пользовательские требования (или требования других заинтересованных лиц – stakeholders, например, регулирование полномочий) без указания идентифицируемого источника-человека.

Процесс работы с требованиями (Requirements Process)

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

Требует адаптации к проектному и/или организационному контексту, в рамках которого ведется соответствующий программный проект.

В частности, тема процесса определения требований касается тех вопросов, которые охватываются в рамках сбора, анализа, специфицирования и утверждения требований ч точки зрения организации этих видов деятельности для различных типов проектов и значимости тех или иных ограничений по отношению к процессу. В большинстве случаев, процесс определения, работы с требованиями выделен в самостоятельный набор и описан как последовательность (сценарии) действий, связанных с ними ролей и непосредственных результатов (их часто называют “артефактами”, например, в RUP – Rational Unified Process), в рамках конкретных методологий разработки программного обеспечения, наиболее популярные из которых мы рассмотрим позднее.

Участники процессов (Process Actors). Вводится понятие “роли” и дается понимание “ролей” для людей, которые участвуют в процессе работы с требованиями. Таких людей также называют “заинтересованными лицами” (в данном контексте - software stakeholders). Заинтересованное лицо – некто, имеющий возможность (в том числе, материальную) повлиять на реализацию проекта/продукта.

Типичные примеры ролей:

Пользователи (Users): группа, охватывающая тех людей, кто будет непосредственно использовать программное обеспечение; пользователи могут описать задачи, которые они решают (планируют решать) с использованием программной системы, а также ожидания по отношению к атрибутам качества, отображаемые в пользовательских требованиях.

Заказчики (Customers): те, кто отвечают за заказ программного обеспечения или, в общем случае, являются целевой аудиторией на рынке программного обеспечения (образуют целевой рынок ПО).

Аналитики (Market analysts): продукты массового рынка программного обеспечения (как и других массовых рынков, например, бытовой техники) не обладают “заказчиками” в понимании персонификации тех, кто “заказывает разработку. В то же самое время, лица, отвечающие за маркетинг, нуждаются в идентификации потребностей и обращению к тем, кто может играть роль <квалифицированных> “представителей” потребителей;

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

Извлечение требований)

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

Один из ключевых принципов программной инженерии заключается в обеспечении взаимодействия между пользователями и инженерами. Прежде, чем начинается разработка программного обеспечения, именно специалисты “по требованиям” – аналитики перекидывают тот самый “мостик” между заказчиками и исполнителями, который задает тот уровень коммуникаций и взаимопонимания между ними, который необходим для решения задач проекта.

Источники требований (Requirement Sources). Необходимо идентифицировать все возможные источники требований, значимые для решения задач проекта. Только после этого можно определить их влияние на проект.

Техники извлечения требований (Elicitation Techniques). Даже обладая пониманием того, кто владеет необходимой информацией, мы далеко не застрахованы от проблем, связанных с получением требований, необходимых для дальнейшей работы. Осуществление своей профессиональной деятельности пользователями далеко не гарантирует, к сожалению, способность ясно, четко и однозначно сформулировать то, что они делают и что именно им необходимо для решения их задач сегодня и завтра. Во многом, поэтому, сбор требований, зачастую, превращается в столь тяжелый и часто порождающий конфликты процесс действительно извлечения, “вытаскивания” информации, без которой невозможно переходить к дальнейшим проектным работам. Недопонимание между аналитиком и пользователем, упущение тех или иных аспектов, на первый взгляд кажущихся второстепенными, неоднозначность или тем более некорректность интерпретации информации, полученных от пользователей – все это наиболее типичные причины “сверх-затрат” (времени, денег и т.п.), а иногда, и полного провала проектов.

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

Интервьюирование – традиционный подход извлечения требований; не стоит забывать, что получение информации от пользователя “не равно” получению требований; информация должна быть проанализирована и трансформирована в требования, таким образом, информация от пользователя является “входом” в процессы сбора требований, а сами требования – “выходом” этих процессов;

Сценарии – контекст для сбора пользовательских требований, определяющий ответы на вопросы “что если” и “как это делается” в отношении бизнес-процессов, реализуемых пользователями;

Прототипы – отличный инструмент для уточнения и/или детализации требований; существуют разные подходы к прототипированию – от “бумажных” моделей до пилотных подсистем, реализуемых как самостоятельные (в терминах управления ресурсами) проекты или бета-версии продуктов; часто прототипы постепенно трансформируются в результаты проекта и используются для проверки и утверждения требований;

“ Разъясняющие встречи” - в оригинале звучит как “facilitated meetings”; достаточно емкий по смыслу термин, пришедший из общей практики менеджмента и базирующийся на идеях сотрудничества заинтересованных лиц для совместного анализа путей решения проблем, определения и предупреждения рисков и т.п. В отличие от “обычного”“мозгового штурма”, как исключительной формы обсуждения тех или иных задач (часто в критические моменты работ над проектом), “запланированный мозговой штурм” – особая форма встреч участников проекта и заинтересованных лиц со стороны заказчика, посвященная обсуждению тех вопросов, ответы на которые не могут быть определены в результате обычных интервью и которые требуют вовлечения большего количества лиц, чем просто пары “пользователь-аналитик.

Наблюдение (observation) – подразумевает непосредственное присутствие аналитиков и инженеров рядом с пользователем в процессе выполнения последним его работ по обеспечению функционирования бизнес-процессов: в определенной степени можно провести аналогию с практикой присутствия представителя заказчика в проектной группе исполнителя (типовая практика в eXtreme Programming “on-site customer” – “присутствующий заказчик”); данная техника является достаточно затратной, но, в то же время, очень эффективной, а иногда – просто незаменимой, особенно, если речь идет о достаточно сложных и взаимосвязанных бизнес-процессах;

Анализ требований

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

Анализ требований включает:

- Обнаружение и разрешение конфликтов между требованиями;

- Определение границ задачи, решаемой создаваемым программным обеспечением; в общем случае - определение “scope” (или “bounds”), границ и содержания программного проекта;

- Детализация системных требований для установления программных требований;

Спецификация требований

На инженерном жаргоне, да и в терминологии ряда методологий, устоялся термин “software requirements specification” (SRS) – спецификация программных требований. Для сложных систем, на самом деле, существует целый комплекс спецификаций, документов, которые являются результатом сбора и анализа требований, их моделирования и архитектурного проектирования. Эти документы систематически анализируются, в них вносятся изменения, они пересматриваются и утверждаются. Чаще всего, для описания комплексных проектов (в части требований) используется три основных документа (спецификации):

Определение системы (system definition)

Системные требования (system requirements)

Программные требования (software requirements)

Определение системы (System Definition Document). Данный документ, часто называемый как “спецификация пользовательских требований” (user requirements specification) или “концепция” (concept <of operations>), описывает системные требования. Содержание документа определяет высокоуровневые требования, часто – стратегические цели, для достижения которых создается программная система. Принципиальным моментом является то, что такой документ описывает требования к системе с точки зрения области применения - “домена”. Соответственно, изложение требований в нем ведется в терминах прикладной области. Документ описывает системные требования вместе с необходимой информацией о бизнес-процессах, операционном окружении с точки зрения бизнес-процедур и организационных и других регламентов. Примером стандарта для создания и структурирования такого документа является IEEE 1362 “Concept of Operations Document”.

Спецификация системных требований (System Requirements Specification). В сложных проектах принято разделять спецификацию системных требований (system requirements) и спецификацию программных требований (software requirements). При таком подходе программные требования порождаются системными требованиями и детализируют требования к компонентам и подсистемам программного обеспечения. Понятие система, в общем случае, охватывает программное обеспечение, аппаратную часть и людей.

Спецификация программных требований (Software Requirements Specification - SRS). Часто эту спецификацию называют “требованиями к программному обеспечению”. Все же, учитывая существование дисциплин системной и программной инженерии, мы используем термин “программные требования”, как более точно подходящий по смыслу по моему мнению.

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