Практики жизненного цикла

We use cookies. Read the Privacy and Cookie Policy

Множество примеров практик, встречающихся на протяжении жизненного цикла системы (их часто так и называют – практики жизненного цикла, life cycle practices), можно встретить в различных инженерных стандартах и публичных документах, и наиболее типичны тут своды знаний (body of knowledge161, корпус знаний), описывающие различные варианты практик какой-то более-менее крупной дисциплины.

Все эти стандарты и публичные документы используют для практик разные названия – практика (practice), способности (abilities), процессы (следуя традиции «функционального описания процессов», заложенной серией стандартов ISO 9000, в которых путались модульный/конструктивный «процесс как последовательность шагов/операций/работ во времени» и компонентный/функциональный «процесс как описание принципов, каким способом нужно достичь результатов»), методы (наборы практик, достаточных для решения какой-то содержательной задачи «под ключ»), и даже методологии (ISO 24744 предложил считать метод/method и методологию/methodology синонимами), иногда «область знаний» (knowledge area), с которой связывают какую-то «деятельность» (activity). Иногда и вообще не используют каких-то терминов – просто говорят, «что нужно делать», приводя название практик, но не используя сам термин.

• свод знаний по организационному анализу (business analysis body of knowledge, BABoK)162. Тут в главе 10 кратко охарактеризован набор из 50 практик, называемых «метод», начиная с 10.1 Acceptance and Evaluation Criteria (Определение критериев приемки и оценки), 10.2 Backlog Management (Управление бэклогом), 10.3 Balanced Scorecard (Сбалансированная система показателей, ССП), 10.4 Benchmarking and Market Analysis (Бенчмаркинг и Анализ рынка), 10.5 Brainstorming (Метод мозгового штурма), 10.6 Business Capability Analysis (Анализ бизнес-возможностей), 10.7 Business Cases (Бизнес-кейсы), …, 10.47 Use Cases and Scenarios (Сценарий использования и Сценарии), 10.48 User Stories (Пользовательские истории), 10.49 Vendor Assessment (Оценка поставщика), 10.50 Workshops (Воркшопы или Семинары)

• свод знаний по проектному управлению института проектного управления (Project Management Institute, project management body of knowledge, PMI PMBoK)163. Там практики называют «процесс», например, группа процессов планирования определяет и уточняет цели и планирует действия, необходимые для достижения целей и содержания, ради которых был предпринят проект. В группу процессов планирования входят следующие процессы: Разработка плана управления проектом, Планирование содержания, Определение содержания, Создание иерархической структуры работ (ИСР), Определение состава операций, Определение взаимосвязей операций, Оценка ресурсов, и т. д. (всего 47 процессов в актуальной 6 версии PMI PMBoK).

• свод знаний по системной инженерии (systems engineering body of knowledge, SEBoK)164. Сами практики тут не выведены явно, а рассыпаны по всему тексту. Это, скорее, «краткое оглавление для большой литературы по предмету системной инженерии», поделенное на «области знаний».

• … множество других BoK, это сегодня стандартная форма выражения знаний по практикам какой-то инженерной или менеджерской дисциплины.

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

Не уделяют они внимания и вопросам выбора варианта функционально одинаковых практик, оставляя этот выбор за человеком-актёром, готовящимся к выполнению какой-то стейкхолдерской роли. Например, есть набор практик проектного управления PMI PMBoK, но есть и альтернативый вариант, APM BoK165 – и нужно выбирать, каким набором практик пользоваться для изучения дисциплины. Абсолютно не исключено, что разные группы компетентных в той или иной практике людей будут рекомендовать использование своего варианта, несовместимого с другими, и без дополнительных исследований при выборе будет не обойтись.

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

Но и дальше может быть деление: например, в инженерии требований можно выделить практики выявления потребностей и требований, анализа требований, специфицирования (документирования) требований, управления требованиями.

И даже на этом уровне могут быть самые разные варианты. Например, при развитии ТРИЗ за последние двадцать лет тамошние практики инженерии системной архитектуры были дополнены практиками инженерии требований. Так что для выявления требований можно или использовать методы/практики ТРИЗ166 (включая технологию: моделеры специфических для этого диаграмм ТРИЗ), или альтернативных других практик, например вариантов/сценариев использования (use cases, включая технологию: моделеры специфических диаграмм use cases).