Помните ли вы, что такое «распечатка в твердой копии»? Если вы писали программы для компьютера в 1980-е, вы можете помнить о распечатках – печатной копии программного кода или цифровых данных в человекочитаемом формате. Почитайте соответствующую статью из Википедии. Мы больше не пользуемся распечатками. Они в прошлом. Википедия объясняет это простыми словами:
Сегодня распечатки редко используются, так как на современных экранах отображается больше строк, чем раньше, программы становятся модульными, хранение в электронном виде предпочтительнее хранения в твердой копии, а электронные материалы проще передавать по сети, на дисках или на лентах. Более того, количество данных становится настолько большим, что их затруднительно распечатать, а поиск проще выполнять в электронном виде.
Мой давний приятель по блогу Эд Лопатегю (Ed Lopategui) обсуждает общие практики и сложности, с которыми сталкиваются производственные компании в области управления конструкторскими изменениями. Рекомендую обратить внимание на две из его статей в блоге GrabCAD: ECOs Aren’t Dead, But They Are Slow and Stupid (Управление конструкторскими изменениями не умерло, оно медленное и тупое) и ECOs are stupid II: The price of unincorporated change (Управление конструкторским изменениями тупое II. Цена невключенного изменения). Лучшие практики в области управления конструкторскими изменениями серьезно зависят от традиционного подхода к стандартам управления конфигурацией. Этот отрывок объясняет все очень хорошо:
Большинство процессов конструкторских изменений заключено в очень формальные традиционные рамки. Управление конструкторскими изменениями возникло из практик управления конфигурацией (CM), которые пришли из времен до появления CAD (не говоря уже о PDM/PLM), когда миром правили чертежи на бумаге. Конструкторские данные не были ни портативными ни широко доступными. Эти эффективные, но сложные практики были созданы в крупных старых производственных компаниях, которые стали первыми клиентами, использовавшими PDM/PLM. В результате, эти процессы продолжают жить и возводятся в абсолют. Они остаются практически без изменений, поддерживаются культурой ведения процессов в крупных компаниях, несмотря на существующие возможности эволюции.
Невключенные изменения – еще одна устаревшая практика, которая является отражением старых практик внесения изменений в чертежи. Сложность изменения документации привела к возникновению самого процесса внесения изменений. Так называемая практика «было – стало» была связана с тем, что сравнение между двумя этапами проектирования было очень сложным:
Концепция невключенного изменения была необходимым компромиссом в прошлом из-за ограничений в области изменения данных проектирования, особенно в эпоху чертежей от руки и в первых CAD, когда фигуру чертежа нельзя было обновить одним – двумя щелчками мыши. Понимание различий между версиями изделий главным образом заключалось в рассматривании чертежей в течение длительного времени, пока изменения не становились понятными и/или у смотрящего начинало рябить в глазах. Для снижения нагрузки на глаза, изменения часто специально обозначались, как БЫЛО/СТАЛО.
Вернемся теперь к современному миру программного обеспечения. Представим, что программист пишет бумажный документ с объяснениями об изменениях программного кода, которые он собирается внести завтра. Он печатает их и отмечает желтым цветом различия «было/стало». Затем направляет их на утверждение. После этого вносятся сами изменения. Это выглядит странно.
Традиционные парадигмы в области PLM очень похожи на старые программные распечатки. Они медленны и сложны. Я постоянно слышу, что инженеры не вносят формальные изменения и не отказываются от процесса жизненного цикла, так как выполнение этого процесса сложно и медленно. Никто не хочет работать со сложными процессами. Во многих ситуациях процесс слишком сложный для групп и людей, чтобы работать с ним. Я говорил о некоторых из этих проблем в своей более ранней статье – why PLM should revise NPI products (почему PLM следует пересмотреть свои процессы представления новых изделий).
Динамичная разработка программного обеспечения стала очень популярна за последнее десятилетие. Появилось множество концепций, которые могут быть использованы производственными компаниями. Одна из интересных возможностей – как сделать процесс внесения изменений простым и быстрым. Когда дело доходит до изменений, скорость очень важна.
Мои выводы
Старые привычки искореняются долго. Управление конструкторскими изменениями – одна из них, насчитывающая 20 – 30 лет истории лучших практик, разработанных до того как системы CAD могли сравнивать две версии моделей и визуализировать различия. Почитайте мое более раннее сообщение how to compare versions and changes (как сравнивать версии и изменения). Новые технологии и новые практики должны войти в жизнь и вытеснить старые подходы, динамичностью и безбумажностью. Всего лишь мое мнение…
С наилучшими пожеланиями, Олег
Все упоминаемые материалы – на английском языке.
Источник: http://beyondplm.com/2015/06/30/how-to-escape-listing-paradigm-and-reinvent-eco/
Перевод подготовлен компанией «Ирисофт».
