Ларри Константин - Человеческий фактор в программировании

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

В течение четырех лет одна австралийская компания с большим успехом применяла вариант этого подхода. Она выпускала по три релиза программной системы в год. Часть «спокойного времени», которое неизбежно появляется в периоды между выпуском релизов, выделялась на обзор архитектуры и планирование. Таким образом, архитектура обновлялась почти непрерывно.

Архитектурное планирование может существенно сэкономить время даже при очень жестких графиках работ. У саги о доблестной команде Ernst amp; Young, которая во время однодневного соревнования нашла время на проектирование архитектуры своей системы (см. главу 30), есть продолжение. Эта команда в полной готовности появилась на следующем соревновании Software Challenge, проходившем на XTWorld в Брисбене (Австралия). На этот раз они применяли новый инструмент (Delphi от Borland) и пересмотренный план для «безумного проектирования приложений» (так этот процесс назвали их соперники). Кроме того, они использовали управление версиями и резервное копирование, а также быстрый, но тщательный анализ и планирование архитектуры. Они выиграли.

Из журнала Software Development, том 4, № 1, январь 1996 г.

«Тотальное управление качеством» (Total Quality Management), «Непрерывное улучшение рабочего процесса» (Continuous Process Improvement) или ISO — в большинстве современных терминов, касающихся качества процесса и продукта, акцент ставится на стремлении к качеству в масштабах всего предприятия и солидные инвестиции с долгосрочной перспективой. Продуманные схемы для оценки и повышения «зрелости процесса», такие как общеизвестная модель развития функциональных возможностей (Capability Maturity Model), разработанная Институтом разработки программного обеспечения (Software Engineering Institute), могут быть весьма полезны. Однако применение подобных моделей может потребовать много ресурсов (Humphrey, Snyder, Willis, 1991 [41]) и привести к непредусмотренным последствиям (Bollinger и McGowan, 1991 [5]). Для получения наибольшей, долговременной отдачи могут понадобиться программы для значительной реструктуризации и обеспечения всестороннего качества. Однако даже небольшие практические шаги будут способствовать быстрому и ощутимому улучшению качества программного обеспечения и эффективности самого проекта.

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

Первые шаги зачастую оказываются самыми важными, а первым шагом в улучшении качества является правильное определение приоритетов. Для улучшения качества продукта и процесса его создания само качество должно стать приоритетом. Если для вас и для организации в целом оно не важно, а стремление к нему не проявляется в действиях руководства, то качество не будет важным критерием и для разработчиков. Все это не означает плакаты с надписями «Качество — наша первая задача!» или напоминания работникам о необходимости стремиться к отсутствию ошибок, Здесь наиболее важно то, что вы делаете, а не то, что говорите.