27.2. Анализ и моделирование производства

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

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

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

В анализе производственного процесса используется два метода.

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

2. Этнографические исследования. В главе 6 уже обсуждалось, как этнографические исследования применяются для изучения процесса разработки ПО в контексте человеческой деятельности. Благодаря этому типу анализа раскрываются все тонкости и сложности, недостижимые для понимания в случае применения других методик.

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

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

Результатом анализа можно считать модель производственного процесса любого уровня детализации.

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

Таблица 27.2. Элементы модели процесса создания ПО

Элемент модели	Описание
Действие (изображается прямоугольником с закругленными краями без тени)	Имеет четко поставленную цель, определены "вход" и "выход" действия. Примеры действий: подготовка тестовых данных для тестирования модулей, написание кода функции или модуля, редактирование документов и т.п. Обычно действие представляет собой элементарную часть этапа процесса, выполняется одним человеком или группой и не может быть разбито на более мелкие действия
Этап процесса (изображается прямоугольником с закругленными краями и с тенью)	Состоит из набора действий, связанных между собой и решающих общую задачу. Примеры этапов: анализ требований, проектирование системной архитектуры, планирование тестирования системы и т.д
Контрольный проектный элемент (изображается как прямоугольник с тенью	Это реальный результат действия или этапа, предусмотренный планом проекта
Условие (изображается параллелограммом)	Может быть либо предусловием и соблюдаться до начала выполнения этапа или действия, либо постусловием, которое должно выполняться после окончания действия или этапа
Роль (изображается в виде круга)	Очерчивает область ответственности лиц, работающих над проектом. Примеры ролей: менеджер по конфигурации, специалист по тестированию, проектировщик ПО и т.п. Несколько ролей могут выполняться одним и тем же специалистом, так же как и одна роль может быть разделена между несколькими лицами
Исключение (в приведенном ниже примере не присутствует, изображается в виде ромба)	Это описание способов изменения технологического процесса в случае возникновения ожидаемых либо непредвиденных обстоятельств. В основном учитываются непредвиденные обстоятельства, поэтому присутствие этого элемента в модели зависит от изобретательности и предвидения менеджеров и разработчиков
Связь (изображается направленной стрелкой)	Отображает обмен информацией между людьми либо между человеком и компьютерными системами поддержки. Связи разделяются на формальные и неформальные. К формальным относится утверждение менеджером контрольного проектного элемента, примером неформальных связей может быть общение разработчиков по электронной почте для выяснения непонятных мест в документации

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

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

Рис. 27.3. Процесс тестирования программного модуля

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

Рис. 27.4. Действия по тестированию модуля